xhtml - lenguaje - que es un atributo en html

¿Cuáles son los problemas asociados con la publicación de páginas con contenido? Application/xhtml+xml (5)

Recientemente, algunas de mis nuevas páginas web (XHTML 1.1) están configuradas para hacer una expresión regular del encabezado de solicitud Accept y enviar los encabezados de respuesta HTTP correctos si el agente de usuario acepta XML (Firefox y Safari lo hacen).

IE (o cualquier otro navegador que no lo acepte) obtendrá el tipo de text/html sin text/html .

¿El bot de Google (o cualquier otro bot de búsqueda) tendrá algún problema con esto? ¿Hay algún aspecto negativo de mi enfoque que he revisado? ¿Creerías que este detector de encabezado tendría mucho efecto en el rendimiento?

El único problema real es que los navegadores mostrarán xml parse errors si su página contiene código inválido, mientras que en text / html mostrarán al menos algo visible.

Realmente no hay ningún beneficio de enviar xml a menos que desee incrustar svg o esté haciendo el procesamiento xml de la página.

El problema es que debe limitar su marcado a un subconjunto de HTML y XHTML.

No puede usar las características XHTML (espacios de nombres, sintaxis de cierre automático en todos los elementos), ya que se romperán en HTML (por ejemplo, <script/> se cierra para el analizador de text/html y matará el documento hasta el próximo </script> ) .
No puede usar el serializador XML, porque podría romper el modo text/html (puede usar las funciones solo XML mencionadas en el punto anterior, puede agregar prefijos de nombre de etiqueta (PHP DOM a veces lo hace <default:h1> ). <script> es CDATA en HTML, pero el serializador XML puede generar <script>if (a && b)</script> ).
No puede usar la sintaxis compacta de HTML (etiquetas implícitas, comillas opcionales), ya que no se analizará como XML.
Es arriesgado usar herramientas HTML (incluida la mayoría de los motores de plantillas), porque no les importa la buena formación (un solo diseño & en href o en inglés romperá por completo XML, y hará que su sitio parezca funcionar solo en IE !

Probé la indexación de mi sitio web solo para XML. Se ha indexado aunque he utilizado application/xml tipo MIME, pero al parecer se analizó como HTML de todos modos (Google no indexó el texto que estaba en las secciones <[CDATA[ ]]> ).

Dado que IE no es compatible con xhtml como application / xhtml + xml, la única forma de obtener compatibilidad con navegadores cruzados es usar la negociación de contenido. Según Web Devout , la negociación de contenido es difícil debido al uso indebido de comodines, donde los navegadores web afirman que admiten todo tipo de contenido existente. Safari y Konquer admiten xhtml, pero solo implican este soporte mediante un comodín, mientras que IE no lo admite, pero también implica soporte.

El W3C recomienda enviar solo xhtml a navegadores que declaren específicamente compatibilidad en el encabezado HTTP Accept e ignoren aquellos navegadores que no declaran específicamente compatibilidad. Sin embargo, tenga en cuenta que los encabezados no siempre son confiables y se sabe que causan problemas con el almacenamiento en caché. Incluso si pudieras hacerlo funcionar, tener que mantener dos versiones similares, pero diferentes sería un dolor.

Teniendo en cuenta todos estos problemas, estoy a favor de dar un error xhtml, cuando sus herramientas y bibliotecas le permiten, por supuesto.

Uso la negociación de contenido para cambiar entre application/xhtml+xml y text/html tal como lo describe, sin notar ningún problema con los robots de búsqueda. Estrictamente, sin embargo, debe tener en cuenta los valores q en el encabezado accept que indica la preferencia del agente de usuario para cada tipo de contenido. Si un agente de usuario prefiere aceptar text/html pero aceptará application/xhtml+xml como alternativa, entonces para mayor seguridad debería tener la página servida como text/html .

Un problema con la negociación de contenido (y con el servicio de diferentes contenidos / encabezados para diferentes agentes de usuario) son los servidores proxy. Considerando lo siguiente; Me encontré con esto en los 4 días de Netscape y desde entonces no me gustó nada.

El usuario A descarga su página con Firefox y obtiene un tipo de contenido XHTML / XML. El ISP del usuario tiene un servidor proxy entre el usuario y su sitio, por lo que esta página ahora está en caché.

El usuario B, el mismo ISP, solicita su página usando Internet Explorer. La solicitud llega primero al proxy, el proxy dice "hey, tengo esa página, aquí está, como application / xhtml + xml ". Se solicita al usuario B que descargue el archivo (ya que IE descargará todo lo enviado como application / xhtml + xml.

Puede solucionar este problema en particular usando el encabezado Vary , como se describe en este artículo 456 de Berea Street . También asumo que los servidores proxy se han vuelto un poco más inteligentes sobre la detección automática de estas cosas.

Aquí es donde comienza a aparecer el CF que es HTML / XHTML . Cuando utiliza la negociación de contenido para servir application / xhtml + xml a un conjunto de user-agents, y text / html a otro conjunto de agentes de usuario, usted confía en todos los proxies entre su servidor y sus usuarios deben comportarse bien.

Incluso si todos los servidores proxy en el mundo fueran lo suficientemente inteligentes como para reconocer el encabezado Vary (no lo son), usted todavía tiene que contender con los conserjes de computadora del mundo. Hay muchos profesionales de TI inteligentes, talentosos y dedicados en el mundo. Hay más personas no tan inteligentes que se pasan el día haciendo doble clic en las aplicaciones del instalador y pensando que "Internet" es esa E azul en su menú. Un proxy mal configurado aún podría cachear indebidamente páginas y encabezados, dejándolo sin suerte.