Atributos no estándar en etiquetas HTML. ¿Buena cosa? ¿Cosa mala? ¿Tus pensamientos?

HTML (¿o tal vez solo XHTML?) Es relativamente estricto cuando se trata de atributos no estándar en las etiquetas. Si no forman parte de la especificación, su código se considera no conforme.

Sin embargo, los atributos no estándar pueden ser bastante útiles para pasar metadatos a Javascript. Por ejemplo, si se supone que un enlace muestra una ventana emergente, puede establecer el nombre de la ventana emergente en un atributo:

<a href="#null" class="popup" title="See the Popup!" 
   popup_title="Title for My Popup">click me</a>

Alternativamente, puede almacenar el título de la ventana emergente en un elemento oculto, como un intervalo:

<style>
    .popup .title { display: none; }
</style>
<a href="#null" title="See the Popup!" class="popup">
    click me
    <span class="title">Title for My Popup</span>
</a>

Sin embargo, no sé cuál debería ser el método preferido. El primer método es más conciso y, supongo, no se mete tanto con los motores de búsqueda y los lectores de pantalla. Por el contrario, la segunda opción facilita el almacenamiento de grandes cantidades de datos y, por lo tanto, es más versátil. También cumple con los estándares.

Tengo curiosidad por saber cuáles son los pensamientos de esta comunidad. ¿Cómo maneja una situación como esta? ¿La simplicidad del primer método supera las posibles desventajas (si las hay)?

Soy un gran admirador de la solución HTML 5 propuesta ( data-atributos con prefijo). Editar: agregaría que probablemente haya mejores ejemplos para el uso de atributos personalizados. Por ejemplo, datos que utilizará una aplicación personalizada que no tienen un análogo en los atributos estándar (por ejemplo, personalización para controladores de eventos basada en algo que no necesariamente se puede expresar en un className o id).

Los atributos personalizados proporcionan una forma conveniente de llevar datos adicionales al lado del cliente. Dojo Toolkit está haciendo esto con regularidad y se ha señalado ( Desenmascarando los mitos de Dojo Toolkit ) que:

Los atributos personalizados siempre han sido HTML válidos, simplemente no se validan cuando se prueban con una DTD. [...] La especificación HTML establece que cualquier atributo no reconocido debe ser ignorado por el motor de renderizado HTML en los agentes de usuario, y Dojo opcionalmente se aprovecha de esto para mejorar la facilidad de desarrollo.

Otra opción sería definir algo como esto en Javascript:

<script type="text/javascript">
var link_titles = {link1: "Title 1", link2: "Title 2"};
</script>

Luego, puede usar esto más adelante en su código Javascript, asumiendo que su enlace tiene una ID que corresponde a la ID en esta tabla hash.

No tiene las desventajas de los otros dos métodos: no tiene atributos no estándar ni el espacio oculto feo.

La desventaja es que puede ser un poco exagerado para cosas tan simples como su ejemplo. Pero para escenarios más complejos, donde tiene más datos para pasar, es una buena opción. Especialmente considerando que los datos se pasan como JSON, por lo que puede pasar objetos complejos con facilidad.

Además, mantiene los datos separados del formato, lo cual es bueno para el mantenimiento.

Incluso puede tener algo como esto (que realmente no puede hacer con los otros métodos):

var poi_types = {1: "City", 2: "Restaurant"};
var poi = {1: {lat: X, lng: Y, name: "Beijing", type: 1}, 2: {lat: A, lng: B, name: "Hatsune", type: 2}};

...

<a id="poi-2" href="/poi/2/">Hatsune</a>

Y dado que lo más probable es que use algún lenguaje de programación del lado del servidor, esta tabla hash debería ser trivial para generar dinámicamente (simplemente serialícela en JSON y escúpala en la sección de encabezado de la página).

Bueno, en este caso, la solución óptima es

<a href="#" alt="" title="Title of My Pop-up">click</a>

y usando el atributo de título.

A veces rompo la especificación si realmente lo necesito. Pero rara vez, y solo por una buena razón.

EDITAR: No estoy seguro de por qué el -1, pero estaba señalando que a veces crees que necesitas romper las especificaciones, cuando no es así.

¿Por qué no declarar el atributo popup_title en una DTD personalizada? Esto resuelve el problema de la validación. Hago esto con todos los elementos, atributos y valores no estándar y agradezco que esta validación me muestre solo problemas reales con mi código. Esto también hace que los errores del navegador sean menos posibles con dicho HTML.

Puede anidar elementos de entrada ocultos DENTRO del elemento de anclaje

<a id="anchor_id">
  <input type="hidden" class="articleid" value="5">
  Link text here
</a>

Entonces puede extraer los datos fácilmente

$('#anchor_id .articleid').val()

Mi solución al final fue ocultar datos adicionales en la etiqueta de identificación separados por algún tipo de delimitador (un guión bajo es un espacio, dos es el final de ese argumento), el segundo argumento hay una identificación:

<a href="#" class="article" id="Title_of_My_Pop-up__47">click</a>

Feo, y asume que aún no estás usando la etiqueta de identificación para otra cosa, pero es compatible con todos los navegadores.

Mi sentimiento personal en su ejemplo es que la ruta de tramo es más apropiada, ya que cumple con los estándares de la especificación XHTML. Sin embargo, puedo ver un argumento para los atributos personalizados, pero creo que agregan un nivel de confusión que no es necesario.

También me he devanado la cabeza por esto. Me gusta la legibilidad de los atributos no estándar, pero no me gusta que rompa el estándar. El ejemplo de tramo oculto es compatible, pero no es muy legible. ¿Qué pasa con esto?

<a href="#" alt="" title="" rel="{popup_title:'Title of My Pop-up'}">click</a>

Aquí el código es muy legible, debido a la notación de pares clave / valor de JSON. Puede decir que se trata de metadatos que pertenecen al enlace con solo mirarlo. El único defecto que puedo ver además de secuestrar el atributo "rel" es que esto se complicaría para los objetos complejos. Realmente me gusta la idea de atributos con prefijo "datos" mencionada anteriormente. ¿Algún navegador actual lo admite?

Aquí hay algo más en lo que pensar. ¿Cuánto impacto tiene el código no compatible en SEO?