javascript - son - todas las etiquetas de html y sus atributos
Atributos no estándar en etiquetas HTML. ¿Buena cosa? ¿Cosa mala? ¿Tus pensamientos? (9)
¿Por qué no declarar el atributo popup_title en una DTD personalizada? Esto resuelve el problema con la validación. Hago esto con todos los elementos, atributos y valores no estándar y gracias a esta validación me muestra solo problemas reales con mi código. Esto hace que los errores del navegador sean menos posibles con dicho HTML.
HTML (o tal vez solo XHTML?) Es relativamente estricto cuando se trata de atributos no estándar en las etiquetas. Si no son parte de la especificación, entonces su código se considera no conforme.
Sin embargo, los atributos no estándar pueden ser bastante útiles para pasar los 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 lapso:
<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, estoy desgarrado sobre cuál debería ser el método preferido. El primer método es más conciso y, supongo, no afecta tanto a los motores de búsqueda como a 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 los pensamientos de esta comunidad. ¿Cómo manejas una situación como esta? ¿La simplicidad del primer método supera las posibles desventajas (si hay alguna)?
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 la 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 piensas que necesitas romper las especificaciones, cuando no lo haces.
Los atributos personalizados proporcionan una forma conveniente de llevar datos adicionales al lado del cliente. Dojo Toolkit está haciendo esto regularmente y se ha señalado ( Debunking Dojo Toolkit Myths ) que:
Los atributos personalizados siempre han sido HTML válido, simplemente no validan cuando se prueban contra un DTD. [...] La especificación HTML establece que cualquier atributo no reconocido debe ser ignorado por el motor de representación HTML en agentes de usuario, y Dojo aprovecha esto de forma opcional para mejorar la facilidad de desarrollo.
Mi sensación personal en su ejemplo es que la ruta span es más apropiada, ya que cumple con los estándares de la especificación XHTML. Sin embargo, puedo ver un argment para atributos personalizados, pero creo que agregan un nivel de confusión que no es necesario.
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 arg hay una identificación:
<a href="#" class="article" id="Title_of_My_Pop-up__47">click</a>
Feo, y se supone que ya no está usando la etiqueta de identificación para otra cosa, pero cumple con todos los navegadores.
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, suponiendo que su enlace tenga una ID que corresponda a la ID en esta tabla hash.
No tiene las desventajas de los otros dos métodos: ningún atributo no estándar ni el feo intervalo oculto.
La desventaja es que puede ser un poco exagerado para cosas tan simples como tu ejemplo. Pero para escenarios más complejos, donde tiene más datos para pasar, es una buena opción. Especialmente teniendo en cuenta 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 puedes tener algo como esto (que no puedes 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 es muy probable que utilice algún lenguaje de programación del lado del servidor, esta tabla hash debe ser trivial para generar dinámicamente (simplemente serialícela en JSON y escúpela en la sección del encabezado de la página).
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>
Luego puede extraer los datos fácilmente
$(''#anchor_id .articleid'').val()
Soy un gran admirador de la solución HTML 5 propuesta (atributos con prefijo de data-
). Editar: agregaría que probablemente haya mejores ejemplos para el uso de atributos personalizados. Por ejemplo, datos que usará una aplicación personalizada que no tengan un análogo en los atributos estándar (por ejemplo, personalización para manejadores de eventos basados en algo que no necesariamente se puede expresar en un className o id).
También he estado analizando mi cerebro con esto. Me gusta la legibilidad de los atributos no estándar, pero no me gusta que rompa el estándar. El ejemplo de span oculto es compatible, pero no es muy legible. ¿Qué tal 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 par clave / valor de JSON. Puedes decir que esto es metadatos que pertenecen al enlace simplemente al mirarlo. El único defecto que puedo ver además de secuestrar el atributo "rel" es que esto se volvería confuso para objetos complejos. Me gusta mucho la idea de los atributos prefijados "data-" mencionados anteriormente. ¿Los navegadores actuales lo soportan?
Aquí hay algo más en qué pensar. ¿Qué tanto impacto tiene el código no conforme en SEO?