Javier Belmonte » HTML

La jornada en Twitter (Día 718)

Javier Belmonte — Mon, 08 Feb 2010 22:30:05 +0000

[Música] Ahora mismo estamos escuchando: A.F.I. – Sing The Sorrow (2003)
10:35 AM Feb 8th from TweetDeck

Hoy, Febrero de 2010, ha llegado por fin un juego de PS3 que compré a través de Fnac.es en Octubre de 2009… #FAIL
4:12 PM Feb 8th from TweetDeck

Peleandome todo el día con jQuery, Flash, CSS, HTML… Y lo que me divierto!!!
5:56 PM Feb 8th from TweetDeck

[Noticia] El hijo de Ringo a la batería de The Who: La mítica banda británica estuvo presente en la Super Bowl. http://bit.ly/tln0369
9:03 PM Feb 8th from TweetDeck

[Noticia] Pearl Jam y Rammstein en BBK Live 2010: Ambas bandas ya han sido confirmadas para el BBK Live de este año. http://bit.ly/tln0370
9:07 PM Feb 8th from TweetDeck

Cerrando por hoy… Los días dan mucho de si, pero hay que saber parar a tiempo!
9:13 PM Feb 8th from TweetDeck

[Disco] Manmade God – Manmade God (2003): Angel Garrido Alonso nos descubre un disco realmente interesante. http://bit.ly/tln0371
9:40 PM Feb 8th from TweetDeck

[Noticia] Stone Sour y su tercer álbum: El próximo disco de Stone Sour verá la luz presumiblemente en verano del 2010. http://bit.ly/tln0372
11:01 PM Feb 8th from TweetDeck

Recien instalada la v0.33.0 de TweetDeck… Y a la espera de la tan cacareada nueva interface de Facebook. Dije parar?
11:08 PM Feb 8th from TweetDeck

Recomendaciones: Pasar de HTML a XHTML

Javier Belmonte — Thu, 13 Nov 2008 21:30:55 +0000

En muchas ocasiones, cuando se aborda un cambio en el lenguaje de marcado utilizado habitualmente para crear nuestras páginas webs, como es por ejemplo el paso de HTML a XHTML, frecuentemente nos encontramos con problemas de varios tipos, atributos usados de forma indebida, etiquetas mal cerradas, e incluso en algunos casos el comportamiento de los CSS varía, con lo que hay que volver revisarlos y redefinirlos.

Puede parecer, y no falta razón en ocasiones, que los que diseñamos y creamos páginas web ante un cambio de lenguaje de marcado, no nos paramos ni un segundo a estudiar las nuevas reglas de uso y que nos limitamos a dejar que el día a día sea el que nos muestre esos nuevos cambios. Algo que puede tener su origen quizás, en nuestra condición de autodidactas, al menos en mi caso. Ignoro si en el mundo de la programación sucede igual, pero para los que hacemos páginas web creo que éste es uno de nuestros mayores hándicaps, la falta de concienciación sobre las reglas de nuestro lenguaje de marcado.

Ni que decir tiene que el lenguaje de marcado que vayamos a utilizar influye de manera crítica en la forma que nuestro navegador va a interpretar los CSS, una de las piedras angulares sobre los que sustentan nuestros diseños y nuestras páginas web. Es por ello por lo que no está de más conocer cuáles son algunos de los cambios más importantes que XHTML ha incorporado, sobre todo si no queremos que nos afecte a nuestros CSS.

Por ejemplo, una de las nuevas características de XHTML es que es case sensitive. Podríamos pensar que ahí reside uno de los mayores conflictos con CSS, pero este cambio introducido en XHTML, no representa muchas diferencias con lo que se venía haciendo, ya que en HTML la definición de atributos id y class también era case sensitive.

Entonces, ¿por qué el paso de un documento HTML a XHTML deriva en todos estos inconvenientes? La respuesta la podemos encontrar fácilmente en la forma que han tenido y tienen los navegadores de Internet de interpretar el documento que se está abriendo.

La correcta definición en la cabecera de los tipos de los documentos utilizados, ya sean HTML o XHTML, ha sido una práctica poco habitual en el mundo web. Actualmente se ha convertido en algo realmente necesario, sobre todo para que los navegadores apliquen correctamente los estándares y sepan interpretar los documentos de la forma adecuada.

Ejemplo: Definición de un documento de tipo XHTML 1.0 Transitional.

La ausencia de esta definición, derivaba en un conflicto realmente importante con los navegadores de Internet, quienes al desconocer el tipo de documento que estaban procesando, y en lugar de usar al azar alguno de los estándares definidos, el Standar Mode, adoptaban el modo de compatibilidad por defecto, o más conocido como Quirks Mode.

Una de las particularidades de este modo era precisamente no ser case sensitive. Esto afectaba, y sigue afectando, no sólo a la forma de visualizar e interpretar las páginas web, sino a la forma en la que los que desconocían esta circunstancia generaban su código CSS. Siempre ha existido, o al menos esa es mi impresión, la tendencia de diseñar para los navegadores, sin pensar que la solución pasa por diseñar pensando en los estándares. Unos estándares que los propios navegadores ya son capaces de interpretar a la perfección a poco que se lo indiquemos de forma adecuada.

Podríamos decir pues que, al margen de la experiencia de cada uno, no hay nada mejor que saber y conocer perfectamente las reglas, particularidades y características fundamentales del lenguaje de marcado que estamos utilizando. Pero además debemos ser capaces de ver a los navegadores de Internet como lo que son, unos simples intérpretes de nuestro código.

Así, cuando nos topemos de nuevo con la disyuntiva, más que habitual hoy día, de que IE6, IE7, FF2 y FF3 no muestran nuestra página web de la misma forma, sabremos reconocer que quizás el problema sea simplemente que no hemos sabido utilizar de forma adecuada todos los estándares, herramientas y lenguajes de los que disponemos.

¿Cómo validar nuestro (X)HTML?

Javier Belmonte — Mon, 10 Nov 2008 21:14:37 +0000

En el último post os comentaba la importancia del buen y correcto uso de los estándares en el desarrollo web actual, abordado desde el punto de vista de las hojas de estilos, o más comúnmente conocidas como CSS. Hoy volveré a incidir en la importancia de este asunto, pero esta vez desde la perspectiva de los lenguajes de programación que se utilizan en la composición y creación de nuestro proyecto web.

Como diseñadores web, hemos de ser conscientes de la importancia de utilizar nuestras herramientas de forma totalmente apropiada. Es por ello por lo que si optamos por crear nuestra página web en XHTML 1.0 Transitional o en HTML 4.01 Transitional, por ejemplo, y además así es como lo definimos en la cabecera de nuestro código, parece razonable que procuremos desarrollar basándonos en las reglas que lo definen. Algo que aparentemente parece muy lógico y evidente, pero que no siempre es fácil de recordar y tener en cuenta, sobre todo si el código lo generamos nosotros directamente.

Por suerte, al igual que en el caso de los validadores automáticos de código CSS que ya comentáramos con anterioridad, el World Wide Web Consortium (W3C) también ha creado un excelente servicio para validar el código fuente de nuestro proyecto web. Un validador que automáticamente detecta el tipo de documento con el que estamos trabajando, ya sea XHTML o HTML, y en tiempo real nos muestra los resultados de la validación, remarcando en caso de error la razón por la cual no es aplicable el código invalidado.

VALIDADOR (X)HTML
http://validator.w3.org/