XHTMLHace poco un alumno de mi curso de ASP.NET 2.0 de campusMVP me preguntaba por el estándar XHTML 1.0 Strict y cómo conseguir que ASP.NET fuera capaz de generar páginas compatibles con él. Retomo ahora el tema para publicar unas cuantas cosas sobre él en el Blog, ya que en algunos tipos de apliaciones (por ejemplo, si trabajamos para un organismo público) puede ser importante.

Primeramente veremos qué es XHTML y qué niveles tiene. En sucesivos post explicaré cómo sacarle partido en ASP.NET 2.0 y cómo nos podemos "columpiar" fácilmente con esto a menos que tengamos un cuidado extremo. Espero que os parezca interesante.

¿Qué es XHTML?

El estándar XHTML está definido por la W3C (World Wide Web Consortium) y define las páginas HTML como si se tratara de documentos XML bien formados. Esta es su principal ventaja ya que pueden ser tratadas y procesadas por un analizador XML cualquiera sin problemas, lo cual las convierte en algo mucho más fácil de usar y transformar por máquinas. Además, las páginas XHTML tienen otras ventajas como que son más fáciles de adaptar a estándares de accesibilidad, nos garantiza que no hemos metido la pata en la definición de la página (olvidándonos de cerrar un elemento, por ejemplo) y, sobre todo, nos aseguramos que serán bien interpretadas por casi cualquier navegador moderno a medida que todos ellos implementan el estándar.

Aunque el estándar XHTML es uno sólo, en realidad se definen varios niveles de cumplimiento del mismo, siendo más o menos estrictos en cada caso respecto a los requerimientos del código generado. Existen:

  • XHTML 1.0 Transitional
  • XHTML 1.0 Frameset
  • XHTML 1.0 Strict
  • XHTML 1.1

Incluso hay ya una nueva especificación XHTML 2.0 que está en borrador desde hace casi un año, pero de momento no debe preocuparnos.

El más estricto en cuanto a condiciones del código es el último de ellos, XHTML 1.1, aunque por su nombre pudiera parecer que iba a ser el anterior. Los dos primeros permiten bastante flexibilidad y además soportan sintaxis antiguas de HTML como veremos luego.

¿En qué consiste la sintaxis XHTML?

Bueno, en realidad define un montón de reglas especiales, pero nos podemos hacer una idea muy buena si pensamos en lo dicho antes y consideramos un documento HTML como si fuera XML puro y duro. De ello deducimos fácilmente algunas reglas:

  • Todas las etiquetas que se abren deben tener su correspondiente cierre. Es decir, se acabó usar sólo un <image> o un <br>, ahora hay que cerrarlos: <image />, <br />
  • Todos los elementos deben estar incluidos dentro de algún otro elemento. Es decir, no puede haber etiquetas "colgando" que no estén contenidas en ninguna otra. Al fin y al cabo se trata de una jerarquía XML.
  • Las etiquetas de apertura y cierre deben ser exactamente iguales, incluso en el uso de mayúsculas y minúsculas.
  • El código de Script se debe incluir dentro comentarios XML.

Además de estas hay otras reglas menos obvias pero que, sin embargo, parecen razonables siguiendo la filosofía XML:

  • Dado que en XML la diferencia entre minúsculas y mayúsculas es tenida en cuenta, los atributos de las etiquetas deberán escribirse todos igual. En este caso implica que todos ellos deben ser definidos en letras minúsculas.
  • Todos los valores de los atributos deben estar incluidos entre comillas dobles. Nada de comillas simples o directamente sin comillas.
  • Existen unas reglas de como nombrar a los elementos. Éstos se identifican opcionalmente con un atributo 'id' que debe segir estas reglas (que se parecen a las de cualquier lenguaje de programación tradicional: letras y números, no comenzar por un número, no usar espacios, etc...)
  • Codificación de caracteres: todos los caracteres no ASCII se codifican siguiendo la sintaxis HTML que comienza con un operador 'et' (&).

Aparte de estas reglas hay un montón de ellas más que, a mi parecer, son bastante aleatorias y dificultan el trabajo bastante, aunque algunas de ellas tienen cierta lógica:

  • No se puede especificar información de formato como nodos XHTML. Es decir, no podemos especificar un tipo de letra, tamaño, negrita, etc... usando etiquetas <FONT> o <B>. La forma de hacerlo es obligatoriamente medienta atributos 'style' y clases de hojas de estilo en cascada (CSS). La lógica detrás de esto imagino que es que el XML de la página XHTML incluya sólo información sobre el contenido, dejando el formato como atributos. O sea, que no haya elementos en el XML que no sean contenido puro y duro. Repito: tiene cierta lógica pero me parece ir en contra del espíritu del HTML original que buscaba justo lo contrario. De hecho ni siquiera se admiten atributos de formato como podría ser bgcolor y similares. En fin...
  • Los formularios no pueden contener un atributo 'name' como toda la vida para identificarlos. En XHTML 1.0 Transational se admite (pero no se aconseja), pero en XHTML 1.1 ya no está permitido. Nuevamente esto sigue cierta lógica ya que existe el atributo 'id' genérico para identificar cualquier elemento de una página y localizarla con getElementById en JavaScript, pero ¿no os parece un poco radical?. A mi sí.
  • El código de Script que incluyamos debe llevar el atributo type="text/javaScript" aplicado y además no puede llevar el atributo 'language'. Me deja alucinado. Ya sé que a estas alturas de la película es un poco de bicho raro querer usar VBScript o cosas más esotéricas en páginas Web, pero ¿por qué sólo JavaScript?. Bueno, pues porque es lo único que entienden todos los navegadores. A mi me viene estupendamente pues tengo un libro de JavaScript que se vende como los churros y con esto mucho mejor ¿no?, pero hombre...
  • Esta es la que más me "gusta": no se puede usar el atributo 'target' en ningún elemento. ¿Por qué? Pues por lo visto porque el XML del documento no debería expresar intenciones sobre el contenido, sólo contenido. A mi me parece una chorrada en este caso concreto y creo que el engorro que entraña sustituir este tipo de atributo no merece la pena por un motivo como este.
    Debido a esto algo tan sencillo y directo como este enlace:

    <a href="http://www.jasoft.org" target=_blank>JASoft.org</a>

    Se convierte en el siguiente engorro:

    <a href="http://www.jasoft.org"
           onclick="window.open(this.href); return false;"
           onkeypress="window.open(this.href); return false;">JASoft.org</a>


    ¡Buff! Yo no le veo la ventaja, la verdad.
    Además debido a esto (y como veremos en otro post) los controles de servidor como HyperLink, LinkButton, Treeview, Calendar o los controles de validación, directamente no son compatibles con XHTML 1.1.

El que quiera estudiar a fondo el estándar puede hacerlo desde la página correspondiente del W3C.

En el siguiente post voy a explicar cómo se relaciona ASP.NET con XHTML, y como podemos conseguir compatibilidad (o al menos cierta compatibilidad) con este estándar desde nuestras aplicaciones Web.

Escrito por un humano, no por una IA