son - etiquetas html

Entonces, ¿qué pasa si los atributos HTML personalizados no son válidos XHTML? (15)

Validación

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

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

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

Ejemplo de marcado:

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

Ejemplo javascript (con jQuery):

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

Si necesita validadores especiales para una determinada situación o escenario, simplemente invente nuevas clases (o use selectors ) para su caso especial:

Ejemplo para verificar 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 bastante bien con la validación jQuery y el framework mvc .net y probablemente también con otros)

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

Enviar información "desde y hacia el servidor"

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

(Asegúrese de no pasar datos confidenciales con entradas ocultas, ya que el usuario puede modificarlos sin apenas esfuerzo)

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 validación. ¿Me estoy perdiendo de algo? ¿Cuáles son las ramificaciones del HTML "inválido"? ¿Y una DTD personalizada no los resolvería de todos modos?

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

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

y deje que algún código simple de jquery haga el trabajo desde aquí. Cualquier desarrollador o diseñador web ahora puede trabajar en el rotador de anuncios y cambiar los valores cuando se le solicite sin demasiado preámbulo.

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 descubrir las intenciones cuando el código está escrito de una manera encriptada 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 en otros idiomas, 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 tenemos que acceder o escribir en ella. Piensa en la siguiente persona que trabajará en tu código.

Bueno, depende de tu cliente / jefe / etc. ¿requieren que valide XHTML?

Algunas personas dicen que hay muchas soluciones temporales, y que, según el sceneraio, pueden funcionar muy bien. Esto incluye agregar clases, aprovechar el atributo rel 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 utilice un atributo que se utilizará en la pista en XHTML estándar.

Creo que los desarrolladores validan solo para validar, pero hay algo que decir sobre el hecho de que mantiene el marcado limpio. Sin embargo, debido a que cada navegador (¡advertencia de exageración!) 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 una dirección. Algunas personas argumentan que mantener el código estándar evitará problemas y conflictos en el futuro. Mi opinión: confunde que nadie implemente los estándares de forma correcta y completa hoy, de todos modos, también podría suponer que todo tu código fallará eventualmente. Si funciona, utilícelo, a menos que sea complicado o simplemente trate de 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 red ha cambiado mucho en 5 años. Estoy seguro de que cualquiera tendrá años de aviso cuando necesiten 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 bebé morirán. ¿Eres un gatito asesino?

Debido a que no son estándar, no tienes idea de lo que podría suceder, ni ahora ni en el futuro. Como otros han dicho, 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 lo que los desarrolladores de "browser xxx" han hecho cuando los encuentran.

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

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

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

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, vea la respuesta de SpliFF .

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

<base href="http://example.com/" />

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

Lo que realmente importa es que haya anidado correctamente las etiquetas y los valores de los atributos entre comillas.

Incluso uso nombres de etiquetas personalizadas (las introducidas por HTML5, como encabezado, pie de página, etc.), pero estas tienen problemas en IE.

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

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

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 los atributos personalizados legales (como data-myattr = "foo") por lo que tal vez podría comenzar a usar eso ahora y estar razonablemente a salvo de futuras colisiones de nombres.

Finalmente, puede pasar por alto que la lógica personalizada es la racional detrás del atributo de clase. Aunque generalmente se considera un atributo de estilo, en realidad es una forma legal de establecer meta-propiedades personalizadas en un elemento. Desafortunadamente, usted está básicamente limitado a las propiedades booleanas y es por eso que HTML5 está agregando el prefijo de datos.

Por cierto, por "básicamente booleano" quiero decir en principio. En realidad, no hay nada que te impida usar un separador en tu nombre de clase para definir valores personalizados así como atributos.

class="document docId.56 permissions.RW"

La validación no es un fin en sí misma, sino una herramienta que se utilizará para ayudar a detectar errores de manera temprana, y reducir la cantidad de misteriosos problemas de procesamiento y comportamiento que sus páginas web pueden enfrentar cuando se utilizan en múltiples tipos de navegadores.

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

Lo valioso es que HOY no importa, pero no se puede saber si va a importar mañana (y, según la ley de Murphy, va a importar mañana).

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

Usar atributos personalizados es probablemente inofensivo, pero aún así, ¿por qué elegir una solución potencialmente dañina solo porque piensas (nunca puedes estar seguro) que no causará ningún daño ?. Podría valer la pena analizar esto más a fondo si la alternativa a prueba futura fuera demasiado costosa o poco manejable, pero ciertamente este no es el caso.

Sí, puede legalmente agregar atributos personalizados mediante el uso de "datos".

Por ejemplo:

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

Después de eso, solo usa 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 como 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 en minúscula todo el camino.

Solo para agregar mi ingrediente a la mezcla, la validación también es importante cuando necesita crear contenido que pueda / pueda postprocesarse usando herramientas automatizadas. Si su contenido es válido, puede convertir mucho más fácilmente el formato de un formato a otro. Por ejemplo, hacer XHTML válido a XML con un esquema específico es mucho más fácil cuando se analizan datos que usted 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 en XML para varios trabajos y luego se convierte de nuevo sin pérdida de datos o resultados de representación inesperados.

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