¿Es aceptable para XHTML no válido?

Question

He notado que muchos sitios, incluido SO, usan XHTML como lenguaje de marcado y luego no cumplen con las especificaciones.Con solo buscar SO en la fuente, faltan etiquetas de cierre para párrafos, elementos no válidos, etc.

Entonces, ¿deberían las herramientas (y los desarrolladores) utilizar el tipo de documento XHTML si van a producir un marcado no válido?¿Y deberían los navegadores ser más firmes en su aceptación del marcado deficiente?

Y antes de que alguien grite hipócrita, mi blog tiene un marcado no válido relacionado con captha (o lo tenía la última vez que revisé) que implica diseñar la etiqueta noscript.

Answer 1

Hay muchas razones para utilizar un marcado válido.Mi favorito es que le permite utilizar la validación como una forma de prueba de regresión, evitando que el marcado equivalente a "delta rot" provoque problemas reales de renderizado una vez que los errores alcancen cierta masa crítica.Y realmente, es simplemente descuidado permitir que se acumulen errores "perezosos" como errores tipográficos y etiquetas mal anidadas/abiertas.El marcado válido es una forma de identificar programadores apasionados.

También está la cuestión de la depuración:El marcado válido también le brinda una base estable desde la cual trabajar en los inevitables problemas de compatibilidad entre navegadores.Ningún desarrollador web que valore su tiempo debería comenzar a depurar problemas de compatibilidad del navegador sin asegurarse primero de que el marcado sea al menos sintácticamente válido, y cualquier otro marcado no válido debe tener una buena razón para estar ahí.

(Por cierto, stackoverflow.com no supera ambas pruebas y las sugerencias para solucionar los problemas eran rechazado.)

Dicho todo esto, para responder a su pregunta específica, probablemente no valga la pena utilizar uno de los tipos de documentos XHTML a menos que planee producir documentos válidos (o al menos). el menos bien formado) marcado.Las principales ventajas de XHTML se derivan del hecho de que XHTML es XML, lo que permite que sea procesado y transformado por herramientas y tecnologías que funcionan con XML.Si no planea hacer que su XHTML sea XML bien formado, entonces no tiene mucho sentido elegir ese tipo de documento.La última especificación HTML 4 probablemente hará todo lo que necesita y es mucho más indulgente.

Answer 2

Siempre debemos intentar validarlo según los estándares.Nos aseguraremos de que el sitio web se muestre y funcione correctamente en los navegadores actuales Y futuros.

Answer 3

No creo que, si especifica un tipo de documento, haya alguna razón para no adherirse a este tipo de documento.

El uso de XHTML facilita la detección automática de errores; cada cambio se puede verificar automáticamente para detectar marcas no válidas.Esto evita errores, especialmente cuando se utiliza contenido generado automáticamente.Es realmente fácil para un desarrollador web que utiliza un motor de plantillas (JSP, ASP.NET StringTemplate, etcétera) copiar/pegar una etiqueta de cierre muy poca o demasiada.Cuando este es su único error, puede detectarse y solucionarse de inmediato.Una vez trabajé para un sitio que tenía 165 errores de validación por página, de los cuales 2 o 3 eran errores reales.Era difícil encontrarlos entre el desorden de otros errores.La validación automática habría evitado estos errores en el origen.

No hace falta decir que elegir un estándar y apegarse a él nunca puede beneficiar la interoperabilidad con otros sistemas (screen scrapers, lectores de pantalla, motores de búsqueda) y nunca me he encontrado con una situación en la que una solución XHTML semántica válida con CSS no fuera posible para todos. principales navegadores.

Obviamente, cuando se trabaja con sistemas complejos, no siempre es posible ceñirse a su tipo de documento, pero esto se debe principalmente a una comunicación inadecuada entre los diferentes equipos que desarrollan diferentes partes de estos sistemas o, muy probablemente, sistemas heredados.En el último caso, probablemente sea mejor aislar estos casos y cambiar su tipo de documento en consecuencia.

Es bueno ser pragmático y no adherirse a XHTML sólo porque alguien lo diga, sin importar los costos, pero con el conocimiento actual sobre CSS y navegadores, herramientas de prueba y validación, la mayoría de las veces los beneficios son mucho mayores que los costos.

Answer 4

Se puede decir que tengo un TOC sobre la validez de XHTML.Encuentro que la mayoría de los problemas con el código que no es válido provienen de que los programadores no conocen la diferencia entre HTML y XHTML.He estado escribiendo XHTML y CSS 100% válidos desde hace un tiempo y nunca he tenido problemas importantes de renderizado con otros navegadores.Si mantiene todo válido y no intenta nada demasiado exótico en cuanto a CSS, se ahorrará un montón de tiempo en correcciones.

Answer 5

No usaría XHTML en absoluto solo para ahorrarme el estrés filosófico.De todos modos, no es que ningún navegador lo trate como XHTML.

Los navegadores rechazarán el marcado deficiente si la página se envía como aplicación/xhtml+xml, pero rara vez lo hacen.Esto esta bien.

Me preocuparían más cosas como el uso en línea de CSS y JavaScript con Stack Overflow, simplemente porque dificultan el mantenimiento.

Answer 6

Aunque creo en la lucha por lograr XHTML y CSS válidos, a menudo es difícil hacerlo por varias razones.

• Primero, parte del contenido podría cargarse mediante AJAX.A veces, los fragmentos no se insertan correctamente en el DOM existente.
• Es posible que no todo el HTML que está viendo se haya producido en el mismo documento.Por ejemplo, la página podría estar formada por componentes o plantillas y luego unirse justo antes de que el navegador la muestre.Esto no es una excusa, pero no puedes asumir que el HTML que estás viendo fue codificado a mano de una sola vez.
• ¿Qué pasa si parte del código generado por Markdown no es válido?No se puede culpar a Stack Overflow por no producir código válido.
• Por último, el propósito de DOCTYPE no es simplemente decir "Oye, estoy usando un código válido", sino también informar al navegador de lo que estás intentando hacer para que al menos pueda acercarse al análisis correcto. Esa información.

No creo que la mayoría de los desarrolladores especifiquen un DOCTYPE y luego no lo cumplan explícitamente.

Answer 7

Si bien estoy de acuerdo con la frase "si funciona bien, no te preocupes", es bueno seguir un estándar, aunque es posible que no sea totalmente compatible en este momento.aún puedes usar Table para el diseño, pero no es bueno por una razón.

Answer 8

No, no debe usar XHTML si no puede garantizar que esté bien formado y, en la práctica, no puede garantizarlo si no usa el serializador XML para generar marcado.Leer sobre la producción de XML.

La buena formación es el Lo que diferencia a XHTML de HTML.XHTML con "sólo un" error de marcado deja de ser XHTML. Tiene que ser perfecto cada vez..

Si el sitio "XHTML" parece funcionar con algunos errores, es porque Los navegadores ignoran el DOCTYPE. e interpretar la página como HTML.

Ver Proxy XHTML que fuerza la interpretación de las páginas como XHTML.La mayor parte del tiempo fracasan miserablemente.Esta es una de las razones por las que el futuro de XHTML es incierto y ¿Por qué se ha reanudado el desarrollo de HTML?.

Answer 9

Eso depende.tuve eso problema con mi blog donde un vídeo de YouTube provocó un XHTML no válido, pero se mostró bien.Por otro lado, tengo un enlace "XHTML válido" y una combinación de un reclamo "XHTML válido" y XHTML no válido no es profesional.

Como SO no pretende ser válido, creo que es aceptable, pero personalmente, si yo fuera Jeff, me molestaría e intentaría solucionarlo incluso si se ve bien en los navegadores modernos, pero algunas personas prefieren seguir adelante y hacer las cosas. en lugar de corregir errores inexistentes.

Answer 10

Siempre que funcione en IE, FF, Safari (inserte otro navegador aquí), debería estar bien.La validación no es tan importante como que se muestre correctamente en varios navegadores.El hecho de que sea válido no significa que funcionará correctamente en IE, por ejemplo.

Ejecute Google Analytics o similar en su sitio y vea qué tipo de navegadores utilizan sus usuarios y luego juzgue qué navegadores necesita admitir más y preocúpese por los menos importantes cuando tenga tiempo libre para hacerlo.

Answer 11

Yo digo, si se reproduce bien, entonces no importa si tiene píxeles perfectos.

Se necesita un tiempo para que un sitio esté en funcionamiento de la manera deseada, retroceder y realizar cambios cambiará ligeramente la forma en que se muestra la página, luego debe arreglarlo. aquellos problemas.

Ahora bien, no estoy diciendo que debas crear páginas web descuidadas, pero no veo ninguna razón para arreglar lo que no está roto.Los navegadores no dejarán de admitir la corrección de errores en el futuro cercano.

Answer 12

No entiendo por qué todo el mundo se queda atrapado intentando que sus sitios web se ajusten al estándar cuando algunos navegadores todavía tienen problemas para representar correctamente el código estándar.He estado en diseño web durante unos 10 años y dejé de codificar dos veces (lea:hackear css) y cambiar cosas estúpidas sólo para poder poner un botón en mi sitio.

Creo que usar un <div> hará que no sea válido de todos modos, y será un poco más difícil hacer cualquier JavaScript/AJAX importante sin él.

Answer 13

Hay tantos estándares y están tan mal "aplicados" o respaldados que no creo que importe.No me malinterpreten, creo que deberían existir estándares, pero como no se aplican, nadie los sigue y es una enorme espiral descendente.

Answer 14

Para el 99,999% de los sitios que existen, realmente no importará.La única vez que me ha importado, ejecuté la entrada HTML a través de HTMLTidy para convertirla en XHTML y luego ejecuté mi procesamiento en ella.

Más o menos, es el axioma del viejo programador:No confíes en ninguna entrada.