Muchos amigos me han dicho que tiene misofobia al código, es decir, si le piden que escriba XHTML, nunca está dispuesto a agregar etiquetas adicionales. Por poner un ejemplo sencillo, creo que mucha gente lo ha visto desde muchos lugares:
El siguiente es el contenido citado: <div id="navegación"> <ul> <li></li> <li></li> ... </ul> </div> |
Mucha gente, incluidos muchos expertos de la industria, sugieren escribir así:
El siguiente es el contenido citado: <ul id="nav"> <li></li> <li></li> ... </ul> |
Por supuesto, personalmente aprecio la segunda forma de escribir. Sí, es concisa, clara y semántica. Pero espera, ¿cuál proporciona más control si necesitas darle estilo? Obviamente, ¿el primero?
Entonces, esta pregunta se vuelve un poco exasperante. En una palabra: ¿Le das prioridad a la estructura (marcado) o a la presentación (presentación)? Creo que en los malos tiempos actuales, la primera regla es el rendimiento. Para muchas personas con ideales, incluido yo, al final, para lograr las necesidades de rendimiento, la sopa de etiquetas es en realidad inevitable.
Por tanto, esto sólo puede ser una cuestión de grado. No abuses de ello. No se considera abuso y no existen pautas. Mi regla general personal es la siguiente: si utiliza más de tres niveles de envoltorios (¿envoltorios?) para lograr un requisito de rendimiento, debe detenerse y pensar en ello. Aunque es un poco antiguo, te recomiendo que eches un vistazo a algunas discusiones interesantes en SimpleQuiz.
¿Por qué sucede esto? Porque nada es perfecto. Imagínese, si CSS pudiera proporcionar más reglas para controlar los elementos de la página, podría no ser tan vergonzoso. Por ejemplo, si background-image admite imágenes con cuatro direcciones diferentes de trlb (arriba, derecha, abajo, izquierda), no tenemos que devanarnos los sesos para lidiar con esquinas redondeadas si admite la generación de elementos desde la página, como; como contenido, entonces también se puede reducir considerablemente el uso de etiquetas...
¿XHTML? broma. De hecho, hasta ahora no mucha gente utiliza XHTML y todo es un autoengaño. ¡XHTML está muerto! XHTML es xml y tiene todas las ventajas de xml, pero lo que vemos ahora es texto. Si el texto se trata como xml, esto es perjudicial (enviar XHTML como texto/html se considera perjudicial).
Aunque todos indicamos en Doctype que estamos usando XHTML, en realidad todos usamos HTML. Esta es la realidad. De lo contrario, ¿cómo podrían mostrarse esas páginas mal formadas y llenas de errores en los navegadores modernos y tolerantes... No es de extrañar, XHTML 1 es solo una mejora de HTML 4. Sin embargo, el futuro XHTML 2 no es compatible con versiones anteriores y no sé por qué necesitamos usar XHTML 1. Además, no discutan conmigo sobre accesibilidad, HTML 4, que separa estructura y presentación, no es diferente de XHTML 1.
Entonces, tal vez el objetivo de usar XHTML 1 es decir que ya tenemos esta idea y estamos listos para XHTML 2 en el futuro.
Es por eso que recomiendo encarecidamente utilizar HTML 4.01 Strict Doctype. Desde la perspectiva de una empresa / empresa, no es fácil exigir que todo el equipo tenga ideas sobre estándares web e implemente principios relevantes. Varias ideas que quedaron del siglo pasado todavía se resisten obstinadamente. Si realmente usa XHTML 1, muchos scripts JavaScript que solo son compatibles con HTML fallarán, la edición inadvertida de un carácter sin escape provocará un error en toda la página (error de análisis xml), y así sucesivamente. Para evitar problemas, quizás HTML 4.01 Strict Doctype sea la mejor opción ahora.