xhtml - what is xml
¿Es aceptable para XHTML no válido? (14)
Me he dado cuenta de que hay muchos sitios, TAN incluido, usan XHTML como lenguaje de marcado y luego no se adhieren a la especificación. Simplemente navegando por la fuente de SO, faltan etiquetas de cierre para párrafos, elementos no válidos, etc.
Entonces, ¿deberían las herramientas (y los desarrolladores) usar el doctype XHTML si van a producir marcas no válidas? ¿Y deberían los navegadores ser más firmes en su aceptación del pobre margen de beneficio?
Y antes de que alguien grite hipócrita, mi blog tiene una sola marca de marcado no válida que involucra al captha (o lo hizo la última vez que revisé) que implica el diseño de la etiqueta noscript.
Puedes decir que tengo un TOC en validez XHTML. Encuentro que la mayoría de los problemas con el código no es válido proviene de programadores que no conocen la diferencia entre HTML y XHTML. He estado escribiendo XHTML y CSS 100% válidos o desde hace un tiempo y nunca he tenido problemas importantes de renderizado con otros navegadores. Si mantienes todo lo que es válido, y no pruebas nada demasiado exótico, te ahorrarás mucho tiempo en las correcciones.
Aunque creo en esforzarme por XHTML y CSS válidos, a menudo es difícil hacerlo por varias razones.
- Primero, parte del contenido se puede cargar a través de AJAX. A veces, los fragmentos no se insertan correctamente en el DOM existente.
- El HTML que está viendo puede no haber sido producido en el mismo documento. Por ejemplo, la página puede estar compuesta por componentes o plantillas, y luego juntarse justo antes de que el navegador la represente. Esto no es una excusa, pero no puede suponer que el código HTML que está viendo está codificado a mano, todo a la vez.
- ¿Qué sucede si parte del código generado por Markdown no es válido? No puede culpar a por no producir un código válido.
- Por último, el propósito de DOCTYPE no es simplemente decir "Hola, estoy usando un código válido", sino también darle al navegador una pista sobre lo que estás tratando de hacer para que al menos se acerque al análisis correcto. Esa información.
No creo que la mayoría de los desarrolladores especifiquen un DOCTYPE y luego explícitamente no se adhieren a él.
Depende. Tuve ese problema con mi blog, donde un video de YouTube causó XHTML no válido, pero se procesó correctamente. 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 fuera Jeff, me molestaría e intentaría solucionarlo, incluso si se ve bien en los navegadores modernos, pero algunas personas simplemente siguen adelante y realmente hacen las cosas bien. en lugar de corregir errores inexistentes.
Digo, si se muestra bien, entonces no importa si es perfecto en píxeles.
Se necesita un tiempo para que un sitio se ejecute de la manera que usted lo desee, retroceder y realizar cambios va a cambiar la forma en que la página rinde un poco, luego debe solucionar esos problemas.
Ahora, no digo que debas crear páginas web descuidadas, pero no veo razón para arreglar lo que no está roto. Los navegadores no van a dejar de admitir la corrección de errores en cualquier momento en el futuro cercano.
Hay tantos estándares y están tan "reforzados" o respaldados que no creo que importen. No me malinterpreten, creo que debería haber normas, pero como no se aplican, nadie las sigue y es una espiral descendente masiva.
Mientras funcione en IE, FF, Safari, (inserte otro navegador aquí) debería estar bien. La validación no es tan importante como tener que renderizar correctamente en múltiples navegadores. El hecho de que sea válido no significa que funcione correctamente en IE, por ejemplo.
Ejecute Google Analytics o similar en su sitio y vea qué tipo de navegadores usan sus usuarios y luego evalúe qué navegadores necesita para que más soporte y los menos importantes cuando tenga tiempo libre para hacerlo.
No entiendo por qué todos quedan atrapados tratando de hacer que sus sitios web se ajusten al estándar cuando algunos navegadores tienen problemas para procesar correctamente el código estándar. Llevo 10 años en el diseño web y detuve la doble codificación (léase: hackear CSS) y cambiar cosas estúpidas solo para poder poner un botón en mi sitio.
Creo que usar un <div> hará que seas inválido independientemente, y se hará un poco más difícil hacer JavaScript / AJAX mayor sin él.
No usaría XHTML en absoluto solo para salvarme del estrés filosófico. No es como si los navegadores lo trataran como XHTML de todos modos.
Los navegadores rechazarán el marcado pobre si la página se envía como application / xhtml + xml, pero rara vez lo son. Esto esta bien.
Me preocuparían más cosas como el uso en línea de CSS y JavaScript con , solo porque dificultan el mantenimiento.
Para el 99.999% de los sitios que hay, realmente no importará. La única vez que tuve algo importante, ejecuté la entrada de HTML a través de HTMLTidy para XHTML-ize, y luego ejecuté mi procesamiento en él.
Más o menos, es el axioma del viejo programador: no confíes en ninguna entrada.
a pesar de que estoy de acuerdo con el sentimiento de "si funciona bien, no te preocupes por eso", sin embargo, es bueno seguir un estándar, aunque puede que ahora no sea totalmente compatible. aún puede usar Table para el diseño, pero no es bueno por una razón.
No creo que, si especifica un doctype, haya alguna razón para no adherirse a este doctype.
El uso de XHTML hace que la detección automatizada de errores sea fácil, cada cambio puede verificarse automáticamente para detectar marcas no válidas. Esto evita errores, especialmente cuando se utiliza contenido generado automáticamente. Es muy fácil para un desarrollador web que usa un motor de plantillas (JSP, ASP.NET StringTemplate, etcétera) copiar / pegar una etiqueta de cierre muy poco o demasiado. Cuando este es su único error, se puede detectar y solucionar 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. Estos fueron difíciles de encontrar en el desorden de otros errores. La validación automática habría evitado estos errores en la fuente.
Huelga decir que elegir un estándar y cumplirlo nunca puede beneficiar la interoperabilidad con otros sistemas (raspadores de pantalla, 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 apegarse a su doctype, pero esto es principalmente el resultado de una comunicación inadecuada entre los diferentes equipos que desarrollan diferentes partes de estos sistemas o, lo más probable, heredados. En el último caso, probablemente sea mejor aislar estos casos y cambiar su doctype en consecuencia.
Es bueno ser pragmático y no adherirse a XHTML simplemente porque alguien lo dijo, independientemente de 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.
Siempre debemos tratar de hacerlo validar de acuerdo con los estándares. Nos aseguraremos de que el sitio web se muestre y funcione correctamente en los navegadores actuales Y futuros navegadores.
No, no debe usar XHTML si no puede garantizar la buena formación y, en la práctica, no puede garantizarlo si no utiliza el serializador XML para generar el marcado. Lea acerca de producir XML .
La buena formación es lo que diferencia a XHTML de HTML. XHTML con el error de marcado "solo uno" deja de ser XHTML. Tiene que ser perfecto todo el tiempo .
Si el sitio "XHTML" parece funcionar con algunos errores, es porque los navegadores ignoran el DOCTYPE e interpretan la página como HTML.
Vea el proxy XHTML que fuerza la interpretación de las páginas como XHTML. La mayoría de las veces fallan miserablemente . Esta es una de las razones por las cuales el futuro de XHTML es incierto y por qué se ha reanudado el desarrollo de HTML .
Hay muchas razones para usar un marcado válido. Mi favorito es que le permite usar la validación como una forma de prueba de regresión, evitando que el marcado equivalente a "delta podrido" lleve a problemas reales de representación una vez que los errores alcanzan cierta masa crítica. Y realmente, es simplemente descuidado permitir que se acumulen errores "vagos" como errores tipográficos y etiquetas mal anidadas / no cerradas. El marcado válido es una forma de identificar programadores apasionados .
También está el problema de la depuración: el marcado válido también le brinda una línea 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 los problemas de compatibilidad del navegador sin antes asegurarse de que el marcado sea al menos sintácticamente válido, y cualquier otro marcado no válido debería tener una buena razón para estar allí.
(Incidentalmente, .com falla ambas pruebas, y las sugerencias para solucionar los problemas fueron rechazadas ).
Dicho todo esto, para responder a su pregunta específica, probablemente no valga la pena usar uno de los tipos de documento XHTML a menos que planee producir un marcado válido (o al menos bien formado). Las principales ventajas de XHTML se derivan del hecho de que XHTML es XML, lo que le permite ser procesado y transformado por herramientas y tecnologías que funcionan con XML. Si no planea hacer su XML XHTML bien formado, entonces no tiene mucho sentido elegir ese tipo de documento. La última especificación de HTML 4 probablemente hará todo lo que necesita, y es mucho más indulgente.