Entonces, ¿qué pasa si los atributos HTML personalizados no son XHTML válido?

Sé que esa es la razón por la que algunas personas no los aprueban, pero ¿realmente importa? Creo que el poder que proporcionan, al interactuar con JavaScript y almacenar y enviar información desde y hacia el servidor, supera la preocupación de la validación. ¿Me estoy perdiendo de algo? ¿Cuáles son las ramificaciones del HTML "no válido"? ¿Y no los resolvería un DTD personalizado de todos modos?

La ramificación es que w3c aparece en 2, 5, 10 años y crea un atributo con el mismo nombre. Ahora tu página está rota.

HTML5 proporcionará un tipo de atributo de datos para atributos personalizados legales (como data-myattr = "foo"), por lo que tal vez pueda comenzar a usarlo ahora y estar razonablemente a salvo de futuras colisiones de nombres.

Finalmente, puede estar pasando por alto que la lógica personalizada es lo racional detrás del atributo de clase. Aunque generalmente se considera un atributo de estilo, en realidad es una forma legal de establecer metapropiedades personalizadas en un elemento. Desafortunadamente, está básicamente limitado a las propiedades booleanas, razón por la cual HTML5 agrega el prefijo de datos.

Por cierto, por "básicamente booleano" me refiero en principio. En realidad, no hay nada que le impida usar un separador en el nombre de su clase para definir valores personalizados y atributos.

class="document docId.56 permissions.RW"

Sí, puede agregar atributos personalizados legalmente utilizando "datos".

Por ejemplo:

<div id="testDiv" data-myData="just testing"></div>

Después de eso, simplemente use la última versión de jquery para hacer algo como:

alert($('#testDiv').data('myData'))

o para establecer un atributo de datos:

$('#testDiv').data('myData', 'new custom data')

Y dado que jQuery funciona en casi todos los navegadores, no debería tener ningún problema;)

actualizar

• data-myData se puede convertir a data-mydata en algunos navegadores, en lo que respecta al motor javascript. Lo mejor es mantenerlo todo en minúsculas.

La validación no es un fin en sí mismo, sino una herramienta que se utiliza para ayudar a detectar errores temprano y reducir la cantidad de misteriosos problemas de renderizado y comportamiento que pueden enfrentar sus páginas web cuando se utilizan en varios tipos de navegadores.

Agregar atributos personalizados no afectará ninguno de estos problemas ahora, y es poco probable que lo haga en el futuro, pero debido a que no se validan, significa que cuando llegue a evaluar el resultado de una validación de su página, deberá Elija cuidadosamente entre los problemas de validación que importan y los que no. Cada vez que cambie su página y vuelva a validar, debe repetir esta operación. Si su página se valida por completo, obtendrá un bonito mensaje PASS verde y podrá pasar a la siguiente etapa de prueba o al siguiente cambio que deba realizarse.

He visto personas obsesionadas con la validación haciendo cosas mucho peores / extrañas que usar un simple atributo personalizado:

<base href="http://example.com/" /><!--[if IE]></base><![endif]-->

En mi opinión, los atributos personalizados realmente no importan. Como dicen otros, puede ser bueno estar atento a futuras adiciones de atributos en los estándares. Pero ahora tenemos atributos data- * en HTML5, así que estamos salvados.

Lo que realmente importa es que tenga etiquetas anidadas correctamente y valores de atributo citados correctamente.

Incluso utilizo nombres de etiquetas personalizados (los introducidos por HTML5, como encabezado, pie de página, etc.), pero estos tienen problemas en IE.

Por cierto, a menudo encuentro irónicamente cómo todos esos fanáticos de la validación se inclinan ante los ingeniosos trucos de Google, como las cargas de iframe.

En lugar de usar atributos personalizados, puede asociar sus elementos HTML con los atributos usando JSON:

var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };

Y en cuanto a las ramificaciones, consulte la respuesta de SpliFF .

Almacenar múltiples valores en el atributo de clase no es una encapsulación correcta del código y solo una forma complicada de hacer las cosas. Tome un rotador de anuncios personalizado, por ejemplo, que usa jquery. Es mucho más limpio en la página que hacer

<div class="left blue imagerotator" AdsImagesDir="images/ads/" startWithImage="0" endWithImage="10" rotatorTimerSeconds="3" />

y deje que un código jquery simple haga el trabajo desde aquí. Cualquier desarrollador o diseñador web ahora puede trabajar en el rotador de anuncios y cambiar los valores a este cuando se le solicite sin mucho esfuerzo.

Volver al proyecto un año después o entrar en uno nuevo donde el desarrollador anterior se separó y se fue a una isla en algún lugar del Pacífico puede ser un infierno tratando de averiguar las intenciones cuando el código está escrito de una manera cifrada poco clara como esta:

<div class="left blue imagerotator dir:images-ads endwith:10 t:3 tf:yes"  />

Cuando escribimos código en C # y otros lenguajes, no escribimos código poniendo todas las propiedades personalizadas en una propiedad como una cadena delimitada por espacios y terminamos teniendo que analizar esa cadena cada vez que necesitamos acceder o escribir en ella. Piense en la próxima persona que trabajará en su código.

Lo que pasa con la validación es que HOY puede que no importe, pero no puedes saber si importará mañana (y, según la ley de Murphy, importará mañana).

Simplemente es mejor elegir una alternativa preparada para el futuro. Si no existen ( lo hacen en este caso particular ), el camino a seguir es inventar una alternativa a prueba de futuro.

El uso de atributos personalizados probablemente sea inofensivo, pero aún así, ¿por qué elegir una solución potencialmente dañina solo porque cree (nunca puede estar seguro) que no causará daño? Podría valer la pena discutir esto más a fondo si la alternativa a prueba de futuro fuera demasiado costosa o difícil de manejar, pero ciertamente no es el caso.

Discusión vieja pero sin embargo; en mi opinión, dado que html es un lenguaje de marcado y no un lenguaje de programación, siempre debe interpretarse con indulgencia para los "errores" de marcado. Un navegador puede hacerlo perfectamente. No creo que esto cambie ni deba cambiar nunca. Por lo tanto, el único criterio práctico importante es que la mayoría de los navegadores mostrarán correctamente su HTML y continuará haciéndolo en, digamos, algunos años. Después de ese tiempo, su html probablemente será rediseñado de todos modos.

Solo para agregar mi ingrediente a la mezcla, la validación también es importante cuando necesita crear contenido que pueda / podría procesarse posteriormente con herramientas automatizadas. Si su contenido es válido, puede convertir el marcado de un formato a otro con mucha más facilidad. Por ejemplo, hacer un código XHTML a XML válido con un esquema específico es mucho más fácil cuando se analizan datos que conoce y puede verificar para seguir un formato predecible.

Yo, por ejemplo, NECESITO que mi contenido sea XHTML válido porque muy a menudo se convierte a XML para varios trabajos y luego se vuelve a convertir sin pérdida de datos o resultados de representación inesperados.

Bueno, depende de su cliente / jefe / etc. ¿Requieren que valide XHTML?

Algunas personas dicen que hay muchas soluciones y, dependiendo de la escena, pueden funcionar muy bien. Esto incluye agregar clases, aprovechar larel atributo y alguien que incluso haya escrito su propio analizador para extraer JSON de los comentarios HTML.

HTML5 proporciona una forma estándar de hacer esto, prefija sus atributos personalizados con "datos-". Recomendaría hacer esto ahora de todos modos, ya que existe la posibilidad de que pueda usar un atributo que se usará en el futuro en XHTML estándar.

El uso de HTML no estándar podría hacer que el navegador renderice la página en "modo peculiar", en cuyo caso algunas otras partes de la página pueden renderizarse de forma diferente, y otras cosas como el posicionamiento pueden ser ligeramente diferentes. Sin embargo, el uso de una DTD personalizada puede solucionar esto.

Debido a que no son estándar, no tienes idea de lo que podría suceder, ni ahora ni en el futuro. Como han dicho otros, el W3C podría comenzar a usar esos mismos nombres en el futuro. Pero lo que es aún más peligroso es que no sabes qué han hecho los desarrolladores de "browser xxx" cuando se encuentran con ellos.

Tal vez la página se muestre en modo peculiar, tal vez la página no se muestre en absoluto en algún navegador móvil oscuro, tal vez el navegador pierda memoria, tal vez un asesino de virus se ahogue en su página, etc., etc., etc.

Sé que seguir los estándares religiosamente puede parecer un esnobismo. Sin embargo, una vez que ha experimentado problemas debido a no seguirlos, tiende a dejar de pensar así. Sin embargo, entonces es demasiado tarde y necesita iniciar su aplicación desde cero con un marco diferente ...

Creo que los desarrolladores validan solo para validar, pero hay algo que decir sobre el hecho de que mantiene limpio el marcado. Sin embargo, debido a que cada navegador (¡advertencia exagerada!) Muestra todo de manera diferente, realmente no existe un estándar. Tratamos de seguir los estándares porque nos hace sentir que al menos tenemos alguna dirección. Algunas personas argumentan que mantener el código estándar evitará problemas y conflictos en el futuro. Mi opinión: Al diablo con que nadie implementa los estándares de manera correcta y completa hoy en día, también podría suponer que todo su código fallará eventualmente. Si funciona, funciona, úselo, a menos que sea complicado o simplemente intente ignorar los estándares para pegarlo al W3C o algo así. Creo que es importante recordar que los estándares se implementan muy lentamente, la web ha cambiado tanto en 5 años. YO' Estoy seguro de que cualquier persona tendrá años de aviso cuando necesite solucionar un posible conflicto. No hay motivo para planificar la compatibilidad de los estándares en el futuro cuando ni siquiera puede confiar en los estándares actuales.

Oh, casi lo olvido, si tu código no valida 10 gatitos morirán. ¿Eres un asesino de gatitos?

Jquery .html (marcado) no funciona si el marcado no es válido.

Validación

No debería necesitar atributos personalizados para proporcionar validación. Un mejor enfoque sería agregar validación basada en la tarea real de los campos.

Asignar significado mediante el uso de clases. Tengo nombres de clases como:

• date (Fechas)
• zip (Código postal)
• area (Áreas)
• ssn (Número de seguridad social)

Marcado de ejemplo:

<input class="date" name="date" value="2011-08-09" />

Javascript de ejemplo (con jQuery):

$('.date').validate(); // use your custom function/framework etc here.

Si necesita validadores especiales para un determinado escenario, simplemente invente nuevas clases (o use selectores ) para su caso especial:

Ejemplo para comprobar si dos contraseñas coinciden:

<input id="password" />
<input id="password-confirm" />

if($('#password').val() != $('#password-confirm').val())
{
 // do something if the passwords don't match
}

(Este enfoque funciona sin problemas tanto con la validación de jQuery como con el framework mvc .net y probablemente también con otros)

Bonificación: puede asignar varias clases separadas por un espacio class = "ssn custom-one custom-two"

Envío de información "desde y hacia el servidor"

Si necesita devolver datos, use <input type="hidden" />. Funcionan fuera de la caja.

(Asegúrese de no pasar ningún dato sensible con entradas ocultas, ya que el usuario puede modificarlas casi sin ningún esfuerzo)