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

92

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)?

javascript html standards Dave Mankoff
fuente
3
Estos se denominan atributos "expando", si desea obtener más información sobre ellos.
Jason Bunting
2
AFAIK, los atributos de expansión se establecen en tiempo de ejecución usando javascript. No son parte del XHTML en sí mismo
Philippe Leybaert

Respuestas:

50

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).

falta de párpados
fuente
2
Tiendo a seguir esta solución ahora, aunque no cumple con los estándares.
Tom Ritter
1
Siempre he evitado esto, ya que no se valida. Pero ahora que lo pienso, meter todo en un atributo class = "" (como los metadatos de jquery) no es necesariamente mejor. ¿Hay alguna desventaja práctica y real de este método en <HTML5 land? Básicamente, ¿qué problemas surgirán ahora? Parece que no es ideal, pero no se me ocurren efectos secundarios.
rocketmonkeys
@Rocketmonkeys No estoy seguro, pero creo que el uso de datos dentro de un atributo de clase puede obligar al navegador a intentar aplicar reglas CSS no definidas a un elemento, esto puede causar algunos problemas o problemas de rendimiento. De nuevo, no estoy seguro.
Vitim.us
@ Vitim.us, si hay tal impacto en el rendimiento, sería insignificante. Los navegadores son bastante eficientes en ese tipo de cosas; el impacto de aplicar estilos realmente sería mayor. Y recuerde, las clases no son algo inventado con el propósito de diseñar, son solo datos de elementos como cualquier otro atributo. Se puede usar cualquier atributo en un selector, por lo que si hay tal impacto en el rendimiento, se aplicaría literalmente a cualquier atributo (incluido el data-prefijo) que agregue al elemento.
párpados
@eyelidlessness ese es un buen argumento, tengo que estar de acuerdo, incluso yo prefiero usar la estructura de datos correctamente dentro de Javascript. Encontré algunos casos en los que el uso de atributos de datos es adecuado. Evito jquery como dijo rocketmonkeys. Realmente necesito dejar de molestar a la gente con las micro optimizaciones.
Vitim.us
27

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.

Maine
fuente
9

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).

ibz
fuente
4

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í.

jskulski
fuente
4

¿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.

Marquesina
fuente
2

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()
Ioan Alexandru Cucu
fuente
1
Sí, pero la mejor manera es usar: <input type="hidden" title="article_id" value="5" />. Dado que la clase es algo para CSS, de hecho se da un código no válido si la clase no está en la información de estilo. Incluso si JS o CSS están desactivados, los datos permanecerán ocultos.
Yeti
1
@Yeti, la clase no es algo para CSS ni es inválida si no aparece en los estilos. Son solo datos sobre el elemento, como cualquier otro atributo. La asociación con CSS es que es un selector bien soportado.
párpados
0

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.

Matt Parkins
fuente
-1

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.

Vendedores de Mitchel
fuente
10
Sin embargo, la ruta SPAN es un mal uso de la etiqueta. Puede que cumpla con los estándares de validación, pero no cumple con los estándares semánticos.
ceejayoz
-1

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?


fuente
7
El atributo rel describe la relación entre la página actual y el recurso vinculado. No es un atributo genérico "Almacene los datos que desee". Entonces esto es horrible.
Quentin
1
¿Algún navegador actual lo admite? - ¿Qué hay para apoyar? Los navegadores ya pueden tolerar código no compatible. Teniendo en cuenta que esto es parte del nuevo HTML5, no hay nada que temer al agregar el atributo de datos tal como lo haría con cualquier otro atributo personalizado.
Eslavo