example - ¿Cuál es la necesidad de XHTML?
xhtml example (16)
Creo que ayuda a los navegadores a mostrar correctamente el html sin hacer suposiciones sobre dónde deben cerrarse las etiquetas. Cada vez que un navegador asume algo, sabes lo que sucede.
En una entrevista, me hicieron una pregunta que nunca había pensado, que fue: "Ya tenemos HTML que cumple con todos los requisitos para escribir una página web, así que ¿cuál es la necesidad de XHTML?"
Busqué mucho en Google y también leí muchos artículos, pero no puedo entender correctamente por qué se ha introducido XHTML. Por favor explícame.
De Wiki :
Debido a que necesitan estar bien formados, los verdaderos documentos XHTML permiten que el procesamiento automatizado se realice utilizando herramientas XML estándar, a diferencia del HTML, que requiere un analizador relativamente complejo, indulgente y generalmente personalizado. XHTML se puede considerar como la intersección de HTML y XML en muchos aspectos, ya que es una reformulación de HTML en XML.
Tener HTML conforme a los estándares XML permite un análisis mucho más consistente de la página. Mientras que en HTML, por ejemplo, se le permitía tener etiquetas fuera de orden <b><u>test</b></u> ahora no se puede, se deben cerrar en el orden en que se abrieron. Este tipo de cosas hacen que el análisis de DOM (que ahora se usa mucho en AJAX) sea mucho más fácil.
De hecho, estoy escribiendo esto para preguntar por qué las tres publicaciones anteriores que hablan sobre la coherencia del navegador y el html bien formado han sido rechazadas.
Como es sabido, HTML es un estándar de la industria. Los navegadores se implementan para que muestren el contenido marcado como se describe en el estándar HTML. Lamentablemente, hay áreas que no se han definido bien en HTML: ¿qué sucede si el usuario olvidó una etiqueta de cierre o qué hacer si no se encuentra una imagen referida? algunos navegadores usan la etiqueta ''alt'' para tener un elemento de texto de marcador de posición y algunos navegadores muestran la etiqueta ''alt'' como información sobre herramientas. El famoso modo de ''caprichos'' de los navegadores es el resultado de esta falta de claridad. Debido a esto, es muy posible que la misma página web se muestre de manera diferente en diferentes navegadores.
Además, a medida que el uso de HTML creció hubo un problema más: no era extensible, no había forma de agregar etiquetas definidas por el usuario.
XHTML resuelve los problemas anteriores :
- adopta XML para proporcionar etiquetas extensibles.
- proporcionar un estándar ''estricto'' para los navegadores web
XHTML tiene reglas bien definidas sobre la estructura y estas pueden ser aplicadas programáticamente. Verifique los diversos "Validadores de XHTML" en línea. Le indicarán si su XHTML está bien formado o no (y resaltar las áreas problemáticas). Debido a estas reglas estrictas, su página tiene más o menos la garantía de tener el mismo aspecto en todos los navegadores que implementan XHTML.
[ nota ] si desea verificar lo anterior, consulte el texto "Head First XHTML y CSS"
Estoy seguro de que debes haber encontrado este artículo de W3.Hay mucho que aprender de ese artículo. En resumen, XHTML respeta las reglas xml además de tener un conjunto de etiquetas HTML. Las diferencias más importantes:
* XHTML elements must be properly nested
* XHTML elements must always be closed
* XHTML elements must be in lowercase
* XHTML documents must have one root element
Porque es un XML válido. Eso ayuda mucho, ya que puede utilizar muchas herramientas diseñadas originalmente para XML, como analizadores XML, XSLT, XPath, XQuery, ...
HTML normal es un dialecto SGML y no es analizable sin el conocimiento del esquema.
<ul>
<li>one
<li>two
<li>three
</ul>
es correcto HTML pero no correcto XML. Si desea analizar eso, debe saber que los elementos ul deben cerrarse, pero no es así.
XHTML también le permite incrustar otros dialectos XML como MathML, Ruby, SVG, etc. (También puede incrustar XHTML en otros dialectos XML, si lo desea).
Si solo está ''haciendo una página web'', no necesariamente necesita XHTML. Pero si está generando una página mediante programación, puede encontrar que las herramientas para generar XML son mejores que las que generan HTML.
XHTML te obliga a escribir un código más limpio que sea más fácil de mantener, que se vuelva más consistente y fácil de conectar al DOM. La comparación de XHTML a HTML es como comparar un lenguaje de programación fuertemente tipado a un lenguaje de programación que no tiene muchos tipeos.
Como se mencionó anteriormente, XHTML te permite jugar con SVG y MathML. Me gustaría agregar RDFa a esa lista. RDFa le permite agregar semántica a su contenido que no está cubierto por microformatos. Personalmente he estado haciendo mucho con Dublin Core y Friend-of-a-Friend.
Además de la respuesta de Johannes, HTML es demasiado flexible en sus interpretaciones y tolerancia, donde la estricta formalización de XHTML niega esto.
La tolerancia conduce a la varianza, lo que conduce a incompatibilidades del navegador, lo que lleva al lado oscuro.
XHTML es simplemente una comunicación entre sistemas. HTML es muy difícil de analizar, debido a la cantidad de variaciones que pueden ocurrir en cuanto a lo que está bien formado. Como XML es estricto en su interpretación, este problema se ha eliminado.
Piensa en una arquitectura RESTful. Si una URL es una ubicación permanente para un elemento, los sistemas que deseen acceder a este elemento deberían poder consumir la información devuelta al acceder a la URL. XHTML no lo hace posible per se, porque un sistema ya puede analizar el HTML y recuperar la información necesaria. XML simplemente hace esto más fácil. No existe un conjunto limitado de etiquetas predefinidas que dificulten la clasificación de datos en un documento (aunque técnicamente puede hacerlo en HTML, porque los navegadores lo ignorarán). Puede usar lo que quiera para clasificar qué datos se recuperan.
XHTML es un intento de fomentar el desarrollo de HTML "bien formado".
HTML ha evolucionado durante más de 10 años. Su implementación y la implementación de los navegadores que lo analizan y lo procesan no son exactamente consistentes. Esta es la razón por la compatibilidad entre navegadores es un gran dolor de cabeza.
HTML se basa en SGML (Lenguaje de marcado generalizado estándar). XML también se deriva de SGML, por lo que son primos de un tipo. XHTML se casa con los dos, proporcionando (en teoría) los beneficios de XML a HTML. Esto incluye un esquema bien definido que se puede validar, consultar y transformar confiablemente.
Si quiero rastrear su sitio y analizar su contenido, solo puedo hacerlo si es XML.
Analizar HTML es una pesadilla.
XML es un formato de intercambio de datos; es perfecto para crear sitios web porque, después de todo, estamos tratando con información y esta información debe ser rastreada y comprendida por las computadoras (como los motores de búsqueda).
Veo un montón de respuestas aquí votadas que hacen suposiciones incorrectas sobre cómo funcionan los navegadores. Así que déjenme dar mis 2 centavos sobre el asunto.
En primer lugar, ¿por qué existe XHTML?
se organizó un taller de dos días para analizar si se necesitaba una nueva versión de HTML en XML. La opinión en el taller fue un claro ''Sí'': con un HTML basado en XML, otros lenguajes XML podrían incluir fragmentos de XHTML, y los documentos XHTML podrían incluir fragmentos de otros lenguajes de marcado. También podríamos aprovechar el rediseño para limpiar algunas de las partes más desordenadas de HTML y agregar algunas nuevas funcionalidades necesarias, como mejores formularios.
En resumen, XHTML fue creado por dos razones:
- Para permitir mezclar otro contenido (como mathml y svg) en el mismo documento con reglas de formato claras.
- Para extender y limpiar HTML.
Hacer las cosas más fáciles de validar no era un objetivo de diseño, y tampoco algo necesario porque los validadores HTML4 existen y son completos.
¿XHTML es más fácil de analizar para los navegadores?
Si y no. XML es más fácil de analizar que la sopa de etiquetas HTML, pero, a menos que use un tipo xhtml + xml o mime application / xml para su página XHTML, los navegadores lo analizan utilizando el motor de análisis HTML. Sin embargo, si utiliza los tipos xml mime, IE ahoga su contenido. Este comportamiento se explica en el blog de IE. ¡No hay diferencia en la forma en que los navegadores tratan XHTML y HTML si lo está usando con un tipo de letra mime de texto / html!
¡Ellos si! ¡Tu mientes!
De hecho lo hacen, pero solo por el tipo de documento. Los navegadores usan doctypes en la parte superior de los documentos HTML para determinar si deben usar el modo estándar o el modo peculiar (= modo de errores). Todos los documentos XHTML válidos incluyen un doctype que activa el modo estándar. Sin embargo, en HTML puede obtener el mismo resultado al incluir "<! Doctype html>" en la parte superior de la página.
Entonces, ¿estás diciendo que XHTML no tiene ningún propósito?
De ningún modo. XHTML tiene muchas ventajas:
- Se puede transformar utilizando herramientas XML, como XSLT
- Se puede analizar más fácilmente en el código del lado del servidor
- Puede integrar marcado personalizado mientras pasa una prueba de validación
Entonces, ¿debería usarlo entonces?
Como siempre, la respuesta es "depende".
- Del lado del servidor, posiblemente útil. Si quiere tener las ventajas del lado del servidor de XML, quiere usar una variante XHTML, ya sea XHTML1 (serialización HTML4 como XML) o XHTML5 (serialización HTML5 como XML).
- Del lado del cliente, no es útil. Recomiendo encarecidamente que evite a sus usuarios un tipo de mimo XML. El análisis XML no se combina con el manejo elegante de errores, produciendo solo un "error de análisis XML" en lugar de un documento si tiene algún problema de marcado en su página. A menos que nunca escriba errores, necesitará manejo elegante de errores.
¿Qué hay de HTML5? ¿Compite con XHTML?
No, no. HTML5 tiene dos serializaciones , una como HTML y otra como XML. El beneficio es que ambos ahora tienen reglas de análisis estrictas. Obtendrá un comportamiento predecible en todos los navegadores, independientemente del enfoque que utilice. Sin embargo, HTML5 analizado como HTML tiene el beneficio del manejo elegante de errores. Es por eso que prefiero ese enfoque. Como siempre, YMMV.
¿Por qué se creó XHTML?
- HTML no es muy extensible. El objetivo de XHTML era solucionar esto al introducir espacios de nombres para que idiomas como MathML o SVG pudieran incluirse en línea.
- XMl es mucho más simple de analizar que SGML (el formato utilizado por HTML antes de la versión 5)
- Debido a la abrumadora cantidad de sitios web con errores, los navegadores intentaron corregir el marcado incorrecto. Los nuevos navegadores han tenido que intentar corregirlo de la misma manera. XHTML intenta aumentar los estándares al especificar que solo se mostrará el código estructuralmente correcto.
¿Qué tan bien ha tenido éxito?
- XHTML está muy extendido, pero casi siempre se sirve con el tipo texto / html MIME debido a incompatibilidades con Internet Explorer (hasta la versión 8). Muchas de estas páginas realmente se romperían si se sirven como XML. Por lo tanto, ninguna de las tres ventajas anteriores se ha materializado realmente.
- Muchas personas optaron por usar XHTML porque pensaron que proporcionaría una mejor compatibilidad futura. El trabajo se detuvo en XHTML2.0 y mientras que HTML5 tendrá una serialización XHTML, esto parece estar recibiendo una atención mínima. XHTML no ofrece futuras ventajas de compatibilidad para el futuro previsible. Mozilla y Safari recomiendan usar solo HTML.
- HTML con una estricta DTD ya tiene un formato mucho más limpio. HTML5 lo llevará más lejos al eliminar la DTD de transición, eliminar elementos innecesarios y definir una forma estándar para analizar documentos con un grado de compatibilidad con versiones anteriores. Los navegadores corregirán los errores de la serialización de HTML, en lugar de forzar su corrección, pero al menos lo harán de la misma manera. Aquellos que se preocupan por el código correcto usarán validadores de todos modos.
¿Cuál es la necesidad de XHTML?
XHTML tenía objetivos loables y tal vez será capaz de ofrecer en el futuro. No puedo recomendar XHTML para las posibles ventajas futuras que podría proporcionar, cuando HTML es mucho más fácil ahora. Solo debería usar XHTML si el código anterior o sus herramientas lo obligan a hacerlo.
¡Porque XHTML tiene mucho más sentido!
El punto es que, aunque algo podría no ofrecer más posibilidades técnicas, sigue siendo una mejora si se rehace para ser más claro y lógico. Es por eso que la refacturación de código es una buena idea, incluso si no cambia ninguna de las funciones. Es por eso que Brainfuck no fue un buen lenguaje de programación, incluso si tenía todas las capacidades de Java.
XHTML tiene más sentido porque la estructura subyacente de las etiquetas y sus atributos siempre es coherente, no depende de la semántica de la etiqueta. La forma en que tiene más sentido es bastante evidente, una vez que se familiariza con su diferencia con HTML, pero las etiquetas siempre se anidan ordenadamente, todas las etiquetas deben cerrarse, los nombres deben estar minúsculos, los valores de los atributos deben tener caracteres limitadores a su alrededor.
En pocas palabras: XHTML a menudo solo es beneficioso y preferido sobre HTML siempre que quiera usar una herramienta basada en XML para manipular / transformar / generar páginas HTML en el lado del servidor.
Se pueden encontrar muchos ejemplos en marcos MVC basados en componentes como Sun Oracle JSF que usa Facelets como una tecnología de visualización basada en XHTML. Los componentes del lado del servidor están definidos en XSD y las páginas se analizan usando un analizador SAX . Incluso puede agregar un <!DOCTYPE html> a la parte superior de la página para permitir que Facelets genere un HTML5 "puro" válido y estricto. Microsoft ASP.NET MVC tiene una tecnología de visualización similar.
Cuando está escribiendo a mano HTML, XHTML no agrega muchos beneficios, o debe estar alentando la "frialdad" de usar una tecnología (exagerada).