html - lenguaje - que es la etiqueta lang

Al final del día, ¿por qué elegir XHTML sobre HTML? (18)

Use XHTML

Falla rápido Si hay alguna incoherencia, se encontrarán durante la validación.
Fomenta un mejor diseño al separar el marcado semántico de la presentación, etc.
Está estructurado, lo que significa que puede tratarlo como un objeto de datos y ejecutar todo tipo de consultas en su contra. Por ejemplo, puede encontrar todas las direcciones o citas dentro de su sitio web.
Puede hacer optimizaciones de tiempo de compilación . Dado que es un XML bien formado, puede encontrar / reemplazar operaciones fácilmente durante el tiempo de compilación. O cualquier gestión y manipulación de documentos.
Puede escribir XSLT u otros scripts de transformación para transformar su XHTML programáticamente para otras plataformas. Por ejemplo, podría tener un XSLT para el iPhone que transformaría todos los XHTML para hacerlo compatible o más fácil de usar para el iPhone
Usted está a prueba de futuro usted mismo. La transformación de XHTML a una semántica más nueva es, de nuevo, muy fácil usando la transformación.
Los motores de búsqueda continuarán evolucionando para reunir más información semántica como parte de la web programable .
Las operaciones DOM son más confiables ya que están estructuradas.
Desde una perspectiva algorítmica, produce un análisis más fácil y rápido .

Me pregunto por qué debería usar XHTML en lugar de HTML.

Se supone que XHTML debe ser "modularizado", pero no he visto que ningún lenguaje del lado del servidor se aproveche de nada de eso.

XHTML también es más estricto, y no veo la ventaja. ¿Qué ofrece XHTML que necesito tan mal? ¿Cómo hace que mi código sea "mejor"?

EDIT: otra pregunta que encontré en los comentarios: ¿XHTML analiza más rápido que HTML?

EDIT2: después de leer todos tus comentarios y enlaces, de hecho estoy de acuerdo en que otra publicación merece ser la respuesta correcta, así que elegí la que está directamente vinculada a la mejor fuente.

Además, demuestra que las personas votaron por el comentario verde sin siquiera leerlo.

Algunas diferencias son:

Las etiquetas XHTML deben estar anidadas correctamente
Los documentos deben tener un elemento raíz
Las etiquetas XHTML siempre están en minúsculas
Las etiquetas siempre deben estar cerradas (por ejemplo, usar la etiqueta   en XHTML debe tener la etiqueta de cierre   o   en XHTML)

Aquí hay algunos enlaces en él

wiki XHTML

wiki HTML contra XHTML

Como programador, deberías estar MUY preocupado por tu código. HTML es feo y sigue pocas reglas.

XHTML, por otro lado, convierte HTML en un lenguaje adecuado, siguiendo estrictas reglas estructurales y sintácticas.

XHTML es mejor para todos, ya que ayudará a mover la web a un punto en el que todos (todos los navegadores) puedan ponerse de acuerdo sobre cómo mostrar una página web.

XHTML es un descendiente de XML, y nosotros es mucho más fácil en analizadores creados para el trabajo de análisis sintáctico de documentos XML.

Si no puede ver el beneficio de XHTML, también podría estar usando MS Word para crear sus documentos HTML.

Creo que XHTML es (o debería ser) más rápido de analizar. Un documento XHTML válido debe escribirse en una especificación más estricta en el sentido de que los errores son fatales al analizar, mientras que HTML es más indulgente y permite que se mencionen las rarezas antes de mi comentario como etiquetas de cierre fuera de servicio y cosas por el estilo. Encontré esto útil para descubrir las diferencias entre el análisis HTML y XHTML:

http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Parsing

Una razón por la que podría usar XHTML sobre HTML podría ser si tiene la intención de tener usuarios móviles como parte de su audiencia. Si no recuerdo mal, muchos teléfonos usan algo más de un analizador XML, en lugar de uno HTML para mostrar la web. Si escribe para navegadores de escritorio, HTML probablemente sea aceptable.

Dicho esto, si va a servir los datos como texto / html de todos modos, debe usar HTML:

http://www.hixie.ch/advocacy/xhtml

Debes leer Cuidado con XHTML , que es un artículo informativo que advierte sobre algunos de los peligros de XHTML sobre HTML.

Estuve muy entusiasmado con el XHTML hasta que lo leí, pero tiene varios puntos válidos. Incluyendo el siguiente bit;

XHTML 1.x no es "compatible con el futuro". XHTML 2, actualmente en fase de diseño, no es compatible con XHTML 1.x. XHTML 2 tendrá muchos cambios importantes en la forma en que se escriben y estructuran los documentos, e incluso si ya tiene su sitio escrito en XHTML 1.1, normalmente será necesario reescribir todo el sitio para convertirlo a XHTML 2. adecuado. La transformación XSL no será suficiente en la mayoría de los casos, porque algunas semánticas no se traducirán correctamente.
HTML 4.01 es en realidad más compatible con el futuro. Un documento válido de HTML 4.01 escrito en niveles de soporte modernos será válido HTML 5, y HTML 5 es donde la mayoría de la atención proviene de los desarrolladores de navegadores y el W3C.

La compatibilidad futura puede ser enorme cuando se trabaja en algunos proyectos. El artículo continúa aportando otros buenos puntos, pero creo que eso puede haber sido lo más destacado para mí.

No confundas el artículo con una queja contra XHTML, el autor habla sobre los puntos buenos de XHTML, pero es bueno estar al tanto de las deficiencias antes de sumergirte.

Desarrollo interesante: Se espera que el grupo de trabajo XHTML 2 deje de funcionar a fines de 2009, W3C aumentará los recursos en HTML 5

2009-07-02: Hoy el Director anuncia que cuando la carta del Grupo de Trabajo XHTML 2 expire según lo programado a fines de 2009, la carta no se renovará. Al hacerlo, y al aumentar los recursos en el Grupo de Trabajo, W3C espera acelerar el progreso de HTML 5 y aclarar la posición del W3C con respecto al futuro de HTML. Las preguntas frecuentes responden preguntas sobre el futuro de los entregables del Grupo de trabajo XHTML 2 y el estado de varias discusiones relacionadas con HTML. Obtenga más información sobre la actividad HTML.

Bueno, supongo que eso hace que el futuro del HTML sea bastante claro.

Eche un vistazo a http://www.w3.org/MarkUp/2004/xhtml-faq#need . Hay algunas buenas razones aparte de la modularización.

Yo prefiero XHTML porque es más estricto y está más claramente establecido. HTML es peculiar y los navegadores tienen que aceptar cosas como sadasd . Si bien este es un ejemplo realmente simple, también podría ser más confuso y diferentes navegadores podrían diseñar las cosas de manera diferente.

También creo que XHTML tiene que ser "más rápido" ya que el navegador no tiene que hacer ese tipo de "reparaciones".

El subtítulo de la recomendación de XHTML 1.0:

Una reformulación de HTML 4 en XML 1.0

Existen muchas herramientas hoy para procesar XML. Al usar XHTML, está permitiendo que un gran conjunto de herramientas operen en sus páginas y extraigan información mediante programación.

Si tuviera que usar HTML, esto también sería posible. Existen herramientas para analizar árboles DOM HTML. Sin embargo, estas herramientas a menudo pueden ser más especializadas que las de XML. Puede que no encuentre sus herramientas de procesamiento de datos XML favoritas compatibles con HTML. Además, hay tantos usos para XML hoy en día que puede estar usando XML para alguna otra parte de una aplicación; ¿por qué no usar también el mismo analizador XML para analizar sus páginas web? Esta es la motivación detrás de XHTML.

Si ya te sientes cómodo y familiarizado con HTML 4.01, tienes un proyecto establecido que utiliza HTML 4 y no tienes mucho tiempo libre, simplemente utiliza HTML 4.01. Si tiene tiempo libre, aprenda XHTML 1.1 de todos modos, y comience sus nuevos proyectos en XHTML 1.1. No hay nada de malo en hacerlo. Si está utilizando algo que no sea HTML 4.01 o no está familiarizado con HTML 4 de todos modos, simplemente aprenda XHTML 1.1.

El uso de XHTML con el tipo de documento correcto obligará al navegador a procesar el contenido en un modo más estricto (compatible con los estándares). Esto hace que los diferentes navegadores se comporten mejor y, lo más importante, se parezcan más entre sí. Esto hace que su trabajo como desarrollador web sea mucho más fácil, ya que reduce la cantidad de ajustes específicos del navegador necesarios para que el contenido se vea igual en todos los navegadores.

Quirksmode.org tiene mucha información buena sobre este tema.

En lugar de seguir debatiendo HTML 4.01 Strict frente a XHTML Strict, sugeriría comenzar a usar HTML 5 hoy. John Resig, el autor de jquery, hizo una sugerencia similar el año pasado en su blog.

El doctype HTML 5, en su hermosa simplicidad activará el modo estándar en todos los navegadores (incluido IE6).

<!DOCTYPE html>

Eso es.

HTML 5 ofrece algunas características nuevas y emocionantes como la etiqueta <canvas> que potencialmente puede impulsar el desarrollo de aplicaciones javascript al siguiente nivel. HTML 5 también tiene soporte adecuado para medios (¡y los medios son un aspecto bastante importante de la web estos días!) En forma de etiquetas <video> y <audio> .

Si le gusta la sintaxis de XHTML, es decir, el cierre de etiquetas "vacías" como   , eso es totalmente compatible con HTML 5. De Karl Dubost de la publicación del W3C Aprenda cómo escribir HTML 5 :

la etiqueta de cierre automático está permitida y es conforme en HTML 5.

XHTML2 ha recibido relativamente poca atención en comparación con HTML 5. Cada vez está más claro que HTML 5 es el futuro del marcado en la web. El último navegador de Microsoft, IE8 sigue representando XHTML como text / xml como text / html.

Microsoft tiene un co-presidente en el grupo de trabajo de HTML W3C y hay un apoyo implícito de ellos para HTML 5. Todos los proveedores de navegadores han anunciado públicamente su compatibilidad con HTML 5.

Al final del día, incluso si XHTML2 recupera el apoyo de la industria, no será un problema significativo tener dos estándares en competencia como lo ha sido en el pasado. Ambos lenguajes admiten espacios de nombres XML (en el caso de HTML 5, serialización de HTML, es decir, conmutación DOCTYPE).

En mi opinión, la rigurosidad es, al menos en teoría, algo bueno, porque en HTML, no es necesario ser estricto, y debido a eso y la basura HTML5, los navegadores tienen algoritmos avanzados de corrección de errores que harán la mejor de HTML roto. El problema es que los algoritmos no son exactamente iguales y conducirán a un comportamiento realmente extraño que no se puede predecir. Con XHTML, por otro lado, normalmente tiene XHTML fino y válido, por lo que los algoritmos de corrección de errores no son necesarios, es decir, todo el comportamiento del navegador es predecible. Además, el código estricto hace que sea más fácil para sus herramientas trabajar con el código. Por lo tanto, no tiene nada que perder mediante el uso de XHTML, pero hay posibilidades de ganar. Las cosas empeorarán con HTML sencillo cuando HTML5 finalmente esté disponible y el mensaje "esté abierto en lo que usted acepta" dará lugar al comportamiento extraño descrito. Pero al menos entonces es un comportamiento extraño estandarizado. Suspiro.

Por otro lado, si usa un IDE bueno como Visual Studio, es casi imposible producir código HTML roto de todos modos, por lo que el resultado es el mismo.

Iba a agregar esto como un comentario a una de las otras publicaciones, pero creció demasiado.

Cuál es el punto fundamental que la mayoría de la gente parece estar perdiendo, es el propósito detrás de XHTML. Una de las principales razones para desarrollar la especificación XHTML fue restar importancia a las etiquetas relacionadas con la presentación en el marcado, y aplazar la presentación a CSS. Si bien esta separación se puede lograr con HTML simple, este comportamiento no es promovido por la especificación.

Separar el meta marcado y la presentación es una parte vital del desarrollo de la "web programable", y no solo mejorará el SEO y el acceso para lectores de pantalla / navegadores de texto, sino que también permitirá que su sitio web sea más fácilmente analizable por aquellos que deseen acceda a él mediante programación (en muchos casos simples, esto puede anular la necesidad de desarrollar una API específica, o incluso permitir que los scripts del lado del cliente hagan cosas como, identificar números de teléfono fácilmente). Si su página web cumple con la especificación XHTML, puede atravesarla fácilmente utilizando herramientas relacionadas con XML, y cosas como XPath ... que son noticias fantásticas para aquellos que desean extraer información particular de su sitio web.

XHTML no fue desarrollado para su uso por sí mismo, sino por el uso con una variedad de otras tecnologías. Se basa en gran medida en el uso de CSS para la presentación y sienta las bases para que Microformatos (tanto si los amas como si los odias) ofrezca un marcado estandarizado para la presentación de datos comunes.

No te dejes engañar por la multitud que piensa que XHTML es insignificante, y es demasiado restrictivo e inútil ... fue creado con un propósito que el 95% del mundo parece ignorar / no conocer.

Por supuesto, use HTML, pero úselo para lo que es bueno, y adopte el mismo enfoque al mirar XHTML.

Con respecto a la velocidad de análisis , imagino que habría muy poca diferencia en el análisis de los documentos reales entre XHTML y HTML. El intercambio vendrá puramente en la forma en que describa el documento utilizando el marcado disponible. Las etiquetas XHTML tienden a ser más largas, debido a los atributos requeridos, el cierre adecuado, etc., pero renunciarán a la necesidad de cualquier marcado de presentación en el documento. Siendo ese el caso, creo que estás hablando de comparar un tipo de manzana, con un tipo de manzana muy diferente ... son diferentes, pero es poco probable que tenga alguna consecuencia (en términos de análisis y representación). ) cuando lo único que quieres es una manzana saludable y sabrosa.

Me sorprende que todas las respuestas aquí recomienden XHTML sobre HTML. Estoy firmemente de acuerdo con la opinión contraria: no debe usar XHTML, en el futuro previsible. Este es el por qué:

Ningún navegador interpreta XHTML como XHTML a menos que lo publique como tipo de application/xhtml+xml mimet application/xhtml+xml . Si solo lo publica con el tipo mimet predeterminado, todos los navegadores lo interpretarán como HTML, por ejemplo, aceptar elementos no cerrados o anidados incorrectamente.
Sin embargo, nunca debería hacerlo , ya que Internet Explorer no reconoce application/xhtml+xml , y no podría renderizar la página por completo.
Hay diferencias significativas en el DOM entre XHTML y HTML. Dado que todas las llamadas páginas XHTML se están sirviendo como HTML en este momento, todos los códigos javascript se escriben usando HTML DOM. Si el soporte para el tipo mimético XHTML se vuelve lo suficientemente significativo como para convencer a las personas de que comiencen a usarlo, la mayoría de sus códigos JavaScript se romperán, incluso si creen que sus páginas se validan como XHTML.

Para el visitante de un sitio web, probablemente no haga ninguna diferencia visible. Además, XHTML suele ser más difícil de usar ya que al menos un navegador generalizado todavía no sabe cómo manejarlo y debe servirlo como texto / html en ese caso (lo que produce HTML no válido).

Si su HTML va a ser procesado regularmente por herramientas automatizadas en lugar de ser leído por humanos, entonces es posible que desee utilizar XHTML debido a su estructura más estricta y ser XML es más fácil de analizar (desde el punto de vista de una aplicación. No es que XML sea inherentemente fácil de analizar, sin embargo).

Además de eso, no veo razones convincentes para usarlo. XHTML fue creado en un enfoque de hacer uso de las características XML para HTML y básicamente se reduce a "HTML 4 con varios efectos secundarios molestos" (en mi humilde opinión).

Use HTML (HTML4 estricto o HTML5).

HTML puede utilizar CSS por completo, puede validarse y analizarse sin ambigüedades. La separación de la estructura y la presentación se ha realizado en HTML4 y XHTML simplemente continuó.
Todos los navegadores admiten HTML. Solo algunos navegadores admiten XHTML y los que sí lo tienen, a menudo cuentan con un soporte más maduro y mejor probado y optimizado para HTML (es causado por el hecho de que una pequeña fracción de páginas usa el modo XML).
Si le importan IE y Google, debe usar HTML o un subconjunto de XHTML y HTML definidos en el Apéndice C de la especificación XHTML. Este último es casi el peor de los dos mundos, porque dicho XHTML no puede generarse con herramientas XML estándar, no puede usar mecanismos de extensión nuevos para XHTML y tiene limitaciones adicionales sobre las de HTML únicamente.
XHTML1.0 tiene ahora más de 10 años, fue diseñado en tiempos de "Web1.0", y como dijo el jefe de W3C, en retrospectiva no funcionó y se necesita un mejor enfoque . W3C HTML5 se escribe mientras hablamos y aborda las necesidades de las aplicaciones web que se utilizan hoy en día, y tiene una compatibilidad muy buena con versiones anteriores.
HTML5 cierra muchas lagunas que estaban entre HTML4 y XHTML1 (por ejemplo, agrega SVG en línea, MathML i RDF), limpia el lenguaje más allá de lo que se hizo en XHTML1.0 y XHTML1.1.
XHTML2 no será compatible con los navegadores web en un futuro previsible. Es probable que nunca sea compatible (todos los proveedores de navegadores soportan [X] HTML5, algunos ya han declarado que no implementarán XHTML2).

XHTML1.0 tiene exactamente la misma semántica y separación de presentación de la estructura que HTML4.01. Cualquiera que diga lo contrario, no ha leído la especificación . Animo a todos a leer las especificaciones, es sorprendentemente breve y poco interesante.

Las hojas de estilo se introdujeron en HTML4.01 y no se cambiaron en XHTML1.0.
Los elementos de la presentación quedaron obsoletos en HTML4.01 y no se eliminaron en XHTML1.0.

webdevout.net/articles/beware-of-xhtml#myths .

No hay diferencias imposibles de traducir en HTML y XHTML que harían que el análisis de uno mucho más lento que otro. Depende de cómo se implemente el analizador.

Tanto los analizadores SGML como XML necesitan cargar y analizar toda la DTD para comprender las entidades. Esto solo suele ser más trabajo que el análisis del documento en sí. Los analizadores HTML casi siempre "engañan" y usan entidades codificadas e información de elementos. Los analizadores XHTML en navegadores también hacen trampa.
El análisis de HTML requiere el manejo de etiquetas de inicio y finalización implícitas, y el HTML del mundo real requiere trabajo adicional para manejar etiquetas mal colocadas.
El análisis adecuado de XHTML requiere el seguimiento de los espacios de nombres XML.
Las reglas de Draconian XML requieren comprobar si cada carácter está codificado correctamente. Los analizadores HTML pueden salirse con la suya, pero OTOH necesitan buscar <meta> .

La diferencia general en el costo del análisis es pequeña en comparación con el tiempo que lleva descargar el documento, generar DOM, ejecutar scripts, aplicar CSS y todo lo demás que los navegadores tienen que hacer.

XHTML permite usar todas las herramientas diseñadas para XML. Entre ellos, está XSLT, incrustando SVG, etc.

XHTML te obliga a estar limpio.

Por ejemplo, en HTML, puedes escribir:

<img src="image.jpg">

Esto no es muy lógico, porque la etiqueta img nunca se cierra. En XHTML, sin embargo, estás obligado a cerrar la etiqueta ordenadamente, así:

<img src="image.jpg" />

Me gusta usar algo que me obliga a estar limpio.

Steve

XHTMl es un buen punto de referencia para usar, porque si quieres un código válido necesitarías proporcionar algún aspecto de ayuda a la comunidad con discapacidad, ya que los lectores de pantalla necesitan las partes alt y título de la imagen y las etiquetas de enlace. Debe ser más rápido analizar en cierta medida porque, a diferencia del HTML, el analizador no debería verificar si la etiqueta no se cerró correctamente, si se anudó correctamente, etc. También es mejor usarlo porque sí, es estricto. pero te ayuda a pensar más lógicamente (en mi opinión) cuando se trata de aprender lenguajes de programación.