Entradas ocultas vs atributos de datos HTML5

Question

Algo que me ha estado molestando recientemente es el uso de HTML5 data attributes y cuándo es el apropiado para usarlos.

Normalmente, en una página que realiza varias llamadas AJAX a mi servidor, necesito el ID que es representativo de la página que se está viendo. Actualmente he estado almacenando esto en un elemento <input> oculto en la página, que luego se accede y se almacena en una variable JS en la parte superior de mi llamada jQuery doc ready.

He estado considerando moverlo a un atributo data-id en el elemento del cuerpo, que luego accedería en jQuery usando $('body').data('id');.

¿Hay alguna ventaja con el uso de atributos de datos HTML5 o viceversa? ¿Actuación? ¿Seguridad? "Mejores prácticas"?

Tengo entendido que todos los navegadores tienen acceso a los atributos de los datos, por lo que no es motivo de preocupación tratar con IE.

Answer 1

Como los atributos de los datos son nuevos, no creo que haya un consenso real sobre cuándo son apropiados o cuáles son las mejores prácticas. Mi sensación personal es que tienen mucho sentido cuando se adjuntan datos a los elementos DOM más abajo en la página porque lógicamente van junto con los elementos DOM. Cuando miras usarlos en la etiqueta corporal, me pregunto por qué no mantienes esos valores en las variables regulares de JavaScript. Sospecho que tendrías un mejor rendimiento al usar variables regulares de JavaScript. Todas estas variables se verían fácilmente en Firebug, etc. por lo que es poco probable que uno esté más o menos seguro en ese sentido.

En cuanto al estado inicial de la página, parece que probablemente podría poner la variable javascript directamente en la página en lugar de en un campo oculto con la forma en que lo está utilizando. Si estaba publicando un formulario en el servidor, el elemento oculto podría ser útil allí, para eso se diseñaron los elementos ocultos.

Es una buena pregunta abierta sobre cuáles son las mejores prácticas en esto.

Answer 2

en función de cómo se utiliza el "id" para identificar la página tal vez sería mejor poner el id en la url

como http://www.example.com/page/123

donde 123 es el identificador de

Answer 3

Aquí es mi tomar:

• ocultos input s están destinados a ser utilizados en las formas como una forma de pasar datos de vuelta al servidor sin hacerlo visible o editable, en la pag mi.
• Los atributos están destinados a describir una propiedad de un elemento. Los atributos data- están destinados a transmitir información sobre un elemento a JavaScript en la página.

Basado en esto, un atributo data- en el elemento o htmlbody parecería más apropiado.

Una solución alternativa, aunque menos semántica, es serializar los metadatos de su página como JSON y usar una etiqueta script para establecerla como variable global en la página.Puede ver esto en acción en, por ejemplo, GitHub repositories, donde se crea un objeto global GitHub cerca de la parte superior de la página y se le agrega cierta información (el nombre del repositorio, la rama actual, el último compromiso) para acceder fácilmente.

Answer 4

Uno de los principales inconvenientes es la accesibilidad.

Dado que esos atributos no se envían al servidor en los POST, deberá tener en cuenta lo que sucede en los navegadores con JavaScript desactivado. Si su página también puede degradarse correctamente y realizar esas mismas funciones solicitadas por AJAX a través de envíos de formularios tradicionales si es necesario, un campo oculto seguirá siendo necesario.

Dicho esto, soy un gran admirador de los atributos de datos cuando tienen sentido, especialmente en sitios de tipo "aplicación" estrictamente donde se puede asignar JavaScript de manera segura. Es mucho más agradable etiquetar una fila de tabla con un atributo de id de datos que rellenar un campo oculto en una de sus celdas, por ejemplo. Especialmente junto con el buen soporte de atributos de datos de jQuery para el método .data(), que hace que el código sea limpio e intuitivo en situaciones donde los campos ocultos pueden ser un poco desordenados.

Answer 5

En pocas palabras un atributo de datos se puede conectar al elemento que se describe por el atributo donde las áreas de la entrada oculto no pueden estar dentro de otro elemento DOM y su uso está limitado a formas (en buenas prácticas de todos modos) . La entrada oculta es un elemento DOM real, mientras que el atributo de datos está bien ... es un atributo, por lo que puede vincularse a un elemento DOM. Que en su mayor parte, pero si necesita más información y tal vez un ejemplo de seguir leyendo, te advierto que es un poco largo y el inglés no es mi lengua materna.

Básicamente, el atributo de datos se creó para agregar información adicional a los elementos DOM, que de otro modo no se le pueden asociar con los atributos existentes, como clase o la buena ID anterior.

Esto afecta principalmente a aplicaciones basadas en web o más específicamente a Saas, para las cuales la necesidad de atributos basados ​​en datos es mucho más extensa que un sitio web normal (incluso con un CMS detrás).

Solía ​​día sueño sobre este atributo hace muchos años, cuando sólo tenía 2 opciones:

1. utilizar los atributos del HTML para algo que no estamos
   creado originalmente diseñado o
2. utilice los atributos de hTML con fichas en ellos, para decodificarlos con el lado del cliente o una función de servidor (split, de empalme, explotar)

el problema con este enfoque es que n Independientemente de cómo lo mires, no eres usando los atributos html de la forma en que están destinados y diseñados para ser utilizados.

Html es un lenguaje de marcado, por lo que naturalmente no tiene los atributos de datos con los que no se puede trabajar para manipular el procesamiento de datos y el comportamiento.

El escenario básico que tenía entonces es que quería tener un solo jQuery diálogo para cargar todos los formularios de entrada de datos (clientes, productos, proveedores, etc.) Cada formulario con diferente anchura y altura. De esta forma, el script del lado del cliente sería mucho más pequeño y necesitaría agregar un nuevo cuadro de diálogo para cada formulario nuevo que fuera agregado a la aplicación solicitada por el cliente.

Esta es la forma en que solía hacerlo antes de que el atributo de datos llegó:

Haga clic para añadir un nuevo producto

Dentro de la ficha Identificación tuve 3 valores:

1. El formulario que se va a cargar desde el servidor
2. El ancho de la ventana de diálogo
3. La altura del dialo ventana g

Otro enfoque sería utilizar el atributo href pero esto es mucho peor que utilizando el ID simplemente porque el atributo href está destinado a señalar a un elemento DOM o de otra fuente, no para mantener los datos para estar procesado.

Cualquiera de los dos enfoques implica desglosar el token mediante división o una función similar.

Esto cómo lo hago ahora con el atributo de datos impresionante:

Haga clic para añadir un nuevo producto

De esta manera no necesito una ficha, que sólo puede obtener el valor de cada atributo con un buen viejo $ (this) .attr ('data-form') ;, $ (this) .attr ('data-dwith'); y así.

EN MI OPINIÓN Creo que es mejor agregar un poco más de datos a los elementos html que crear un archivo javascript mucho más largo y más pesado.

Answer 6

Sé que ha pasado un tiempo desde que esta publicación estuvo activa, pero recientemente me encontré con el tema, y ​​quería comentar sobre el aspecto de rendimiento de los dos.

Como otros señalaron, los atributos de Datos son para almacenar datos en el propio DOM, y antes de HTML5 había diferentes maneras de evitar esa necesidad mediante el uso de entradas ocultas anidadas en DOM o mediante el uso de otros atributos.

las entradas ocultas son más intensivas en el rendimiento (especialmente cuando las amplía) porque son objetos DOM con muchos otros atributos (que ocupan más memoria).

utilizando otros atributos es más eficiente en cuanto a la memoria en comparación con las entradas ocultas, pero puede requerir más procesamiento. Probablemente necesites ponerles un prefijo y extraer datos usando esos prefijos. Además, establecerlos y obtenerlos también puede ser complicado y puede dañar la funcionalidad predeterminada de algunos elementos.

Así que aquí hay un conjunto de pautas que establecí para mí cuando se trata de elegir entre entradas ocultas y atributos de datos.

• Elige atributos de datos cuando los datos sólo se diseñó para la funcionalidad de extremo frontal (sin necesidad de enviar de vuelta)
• seleccione los atributos de los datos cuando hay datos a gran escala que necesita para almacenar (ejemplo: Gráfico de coordenada, largas listas con múltiples parámetros)
• Elegir entradas ocultas cuando el almacenamiento de grandes cantidades de datos o datos con caracteres especiales