tutorial - Valdrá la pena la validación HTML 5?
tutorial django (6)
En general, se considera que la mejor razón para validar el código HTML de uno es garantizar que todos los navegadores lo traten de manera consistente y predecible.
El borrador de HTML 5, sin embargo, contiene dos especificaciones en una. Primero una especificación de autor, que describe los elementos y atributos que los autores de HTML deben usar, y sus interrelaciones. La validación de una página HTML 5 se basa en esta especificación. Los elementos y atributos incluidos no se extraen directamente de HTML 4, pero deben justificarse a partir de los primeros principios, lo que significa que algunas características de HTML 4, como el atributo de resumen en <table>, longdesc on <img> y el atributo de perfil en <head>, actualmente no aparece en este borrador. Tales características no se consideran obsoletas, simplemente no están incluidas. (Su ausencia del borrador sigue siendo motivo de disputa, aunque su inclusión en el futuro no parece probable).
En segundo lugar, el borrador define una especificación de procesamiento del navegador que busca definir exactamente cómo el analizador de un navegador tratará cualquier flujo de bytes que se le proporcione, independientemente de cuán bien formado y válido sea el HTML. Esto significa que cuando los navegadores sean totalmente compatibles con HTML 5, será posible predecir cómo cualquier navegador tratará HTML para una gama de entradas mucho más amplia que aquellos que pasan la validación.
En particular, debido a que HTML 5 se define como 100% compatible con la versión anterior de la web de hoy, todos los HTML 4 válidos y todos los márgenes no válidos pero de uso común continuarán procesándose exactamente igual que hoy, independientemente de si es HTML 5 válido o no.
Por lo tanto, como mínimo, cualquier persona que utilice alguna función de HTML 5, HTML 4 o cualquier versión anterior de HTML, además de muchas extensiones propietarias, puede confiar en que su HTML obtendrá un tratamiento consistente y predecible en todos los navegadores.
Teniendo esto en cuenta, ¿tiene algún sentido limitar los HTML 5 a lo que validará, y qué beneficio práctico obtendremos al hacerlo?
Teniendo esto en cuenta, ¿tiene algún sentido limitar los HTML 5 a lo que validará, y qué beneficio práctico obtendremos al hacerlo?
Sí, por supuesto. Olvidas que el futuro no es fijo. En particular, supones implícitamente que las especificaciones de HTML 5 nunca cambiarán y nunca desaprobarán ninguna función. Esto, por supuesto, solo cementa el status quo. Definitivamente es deseable eliminar el soporte para algunas funciones a largo plazo, para facilitar el desarrollo de nuevos desarrollos (en particular, si estos pudieran entrar en conflicto entre sí).
Puede que no haya un beneficio inmediato en la producción de HTML 5 válido (excepto que todavía hace que la validación y, por lo tanto, el desarrollo sean más fáciles). Pero puede haber un beneficio a largo plazo si la mayoría de los sitios web mejora en calidad porque hace que moverse más allá de las tecnologías y estándares actuales sea mucho más fácil.
Es una buena pregunta.
El objetivo principal de la validación (al menos para mí) es ayudarme a detectar errores en mi marcado y darme una buena base sobre la cual construir al probar páginas en diferentes navegadores; si el marcado es válido y la página tiene un borked en IE6, se trata de un problema de IE6.
El hecho de que los navegadores aún se comporten de manera predecible, incluso si su marcado incluye HTML5 técnicamente no válido, como un resumen de tabla o una clave de acceso de anclaje, enturbia un poco las aguas.
Como regla general, siempre me gustaría que mis páginas validen, por la razón antes mencionada. Sin embargo, si (por ejemplo) se quitó un atributo de la especificación HTML5 sin agregar un reemplazo aparentemente adecuado, podría inclinarme a continuar usando el atributo en desuso u obsoleto, y aceptar los errores de validación.
Como siempre, creo que es un caso de conocer tu oficio.
Si sabes lo que estás haciendo y has tomado la decisión consciente de crear una página que no valide por razones sólidas, no es un problema. Si solo estás escribiendo un código que no valida porque no conoces nada mejor, eso es otro asunto completamente diferente.
Stephen
Este es, de hecho, uno de mis problemas con HTML5. No tiene sentido definir un subconjunto de secuencias como ''válido'', si un navegador debe manejar todas las secuencias de la misma manera de todos modos. Los eones gastados en la lista WHATWG para debatir los mecanismos de retroceso es una pérdida masiva del tiempo de todos, especialmente cuando XML ya debería haber resuelto todos los problemas de análisis.
Habría sido una idea útil para producir un documento de mejores prácticas sobre el análisis de documentos no válidos heredados, pero esto no tiene parte en un estándar web, es solo otro ingrediente para enturbiar las aguas alrededor de HTML5, que no puede decidir si quiere o no codificar el comportamiento existente (como lo hizo HTML 3.2), redefinir una plataforma más limpia (como lo intentó HTML 3.0) o agregar nuevas extensiones por partes.
De todos modos, la pregunta puede estar fuera de lugar porque nunca habrá un navegador que "admita completamente HTML5". Hay demasiado, demasiado: los fabricantes de navegadores no pudieron implementar absolutamente todo hasta las minucias, incluso si quisieran, lo que al menos Microsoft explícitamente no hace. En cambio, las características obviamente útiles serán seleccionadas por el vendedor y tendrán una aceptación más amplia.
HTML5 no es una especificación de HTML coherente, es la receta expansiva, ilegible e inacabada de Hixie para cada cosa aleatoria que cree que debería hacer un navegador web. Fallará Y el enfoque alternativo de W3, XHTML2, ya ha fallado. No hay una dirección futura coherente para los estándares web. Hemos dejado caer la pelota.
La validación nunca ha sido realmente obtener resultados consistentes en todos los navegadores, incluso antes de que comenzara HTML5. Ese es un mito propagado por aquellos que no entienden de lo que están hablando, incluso si creen que lo hacen.
El verdadero motivo de la validación es, y siempre ha sido, puramente una cuestión de garantía de calidad. Es solo una forma de detectar errores, que. Aunque los resultados de cualquier error dado pueden ser, o pueden llegar a serlo, consistentes entre los navegadores, aún es posible que el resultado en sí no sea el esperado.
Es importante que los autores puedan detectar errores en su código porque es más fácil trabajar con ellos y mantenerlos, especialmente cuando se trabaja en un entorno de equipo. Si bien la mayoría de los errores individuales pueden terminar siendo benignos y no causar problemas importantes, hay algunos que pueden dar resultados inesperados. Por ejemplo, incorrectamente, los elementos superpuestos o no cerrados pueden causar problemas de diseño inesperados en algunos casos, y dejar que un validador le diga dónde está el error ayuda a rectificar el problema. Pero si los resultados se llenan con docenas de errores benignos, puede hacer que la detección y el proceso sean más difíciles de lo necesario.
- Primero está la capa de validez correspondiente a "errores de análisis" en el algoritmo de análisis HTML5 . Esta capa es similar a la formación de XML. La principal razón para evitar errores en sus documentos en esta capa es que puede obtener un árbol de análisis sorprendente. Si su documento está libre de errores en esta capa, obtendrá menos sorpresas para depurar al escribir JS o CSS que funcione con DOM.
- Como un caso especial de la capa mencionada anteriormente, está el doctype HTML5:
<!DOCTYPE html>. La razón por la cual uno querría cumplir aquí es obtener el modo estándar de la manera más fácil posible. Es algo que puede memorizar a diferencia de los tipos de documento HTML 4.01 o XHTML 1.0 que necesita buscar y copiar y pegar cada vez. Por supuesto, la razón por la que desea el modo estándar es menos sorpresas en la capa de CSS. - La razón principal para preocuparse por la validación en la capa más alta que el algoritmo de análisis es capturar sus errores tipográficos para que pase menos tiempo depurando por qué su página no funciona como espera.
- El punto anterior no explica por qué debería preocuparse por la validación cuando un elemento o atributo dado que no haya escrito mal es compatible con los navegadores como una cuestión de herencia, pero las especificaciones de HTML5 todavía lo evitan. He aquí por qué HTML5 tiene una sintaxis obsoleta como esta:
- HTML5 usa la obsolescencia para indicarles a los autores que algunas funciones son una pérdida de tiempo. Estos incluyen
longdesc,summaryyprofile. (Tenga en cuenta que las personas no están de acuerdo sobre si estas son, de hecho, una pérdida de tiempo, pero como está redactado actualmente, HTML5 las hace obsoletas). Es decir, si tiene recursos limitados para mejorar la accesibilidad, sus recursos limitados se gastan mejor en algo que no sealongdescysummarySi tiene recursos limitados para la pureza semántica, sus recursos se gastarán mejor en algo que no sea asegurarse de tener el hechizo correcto en elprofile. - HTML5 obsoleto algunas características de presentación que se pueden duplicar en CSS para guiar a los autores a usar CSS para su propio bien. De esta forma, se supone que los autores que no consideran la mantenibilidad por sí mismos deben guiarse hacia un código más fácil de mantener. Personalmente, preferiría adaptar más elementos heredables de presentación y dejar que los propios autores decidan qué forma de hacer las cosas funciona para ellos.
- Algunas cosas están obsoletas por razones políticas. El elemento
<font>está obsoleto, porque hacerlo conforme haría que los anti-<font>standardistas piensen que los HTML5 se han vuelto locos, lo que podría conducir a malas relaciones públicas.<applet>está obsoleto principalmente por una cuestión de principio de no otorgar un marcado especial a un plug-in en particular. El atributoclassiden<object>está obsoleto, porque en la práctica es específico de ActiveX. - Algunas cosas están obsoletas sobre la base de la estética del diseño del lenguaje. Esto incluye el atributo de
nameen<a>y el atributo delanguageen<script>.
- HTML5 usa la obsolescencia para indicarles a los autores que algunas funciones son una pérdida de tiempo. Estos incluyen
(Desarrollo el validador HTML5 Validator.nu que también es el motor de validación HTML5 utilizado por el validador W3C).
W3C HTML5 validator manteiner aquí. Hace poco escribí una breve sección "¿Por qué validar?" Para la sección "Acerca de" del validador de HTML5:
http://validator.w3.org/nu/about.html#why-validate
La fuente del texto de esa sección está aquí:
https://github.com/validator/validator/blob/master/site/nu-about.html#L160
Y las solicitudes de extracción con mejoras / adiciones sugeridas son bienvenidas.
Lo que tengo allí actualmente es esto:
La razón principal para ejecutar sus documentos HTML a través de un comprobador de conformidad es simple: detectar errores involuntarios, errores que de otro modo podría haber pasado por alto, para que pueda solucionarlos.
Más allá de eso, algunos requisitos de conformidad de documentos (reglas de validez) en las especificaciones de HTML están ahí para ayudarlo a usted y a los usuarios de sus documentos a evitar ciertos tipos de problemas potenciales. Para explicar el razonamiento detrás de esos requisitos, la especificación de HTML contiene estas dos secciones:
- razonamiento para los errores de nivel de sintaxis
- justificación de las restricciones en los modelos de contenido y en los valores de los atributos
Para resumir lo que está establecido en esas dos secciones:
- Hay algunos casos de marcado definidos como errores porque son posibles problemas de accesibilidad, usabilidad, interoperabilidad, seguridad o capacidad de mantenimiento, o porque pueden dar como resultado un rendimiento deficiente o que pueden provocar fallas en las secuencias de comandos que son difíciles de solucionar.
- Junto con estos, algunos casos de marcado se definen como errores porque pueden provocar problemas potenciales en el análisis de HTML y en el comportamiento de manejo de errores, por lo que, por ejemplo, terminarías con un resultado no intuitivo e inesperado en el DOM.
La validación de sus documentos le alerta sobre esos posibles problemas.