sábado, 11 de febrero de 2017

4.24 [A+] XML: HTML y XHTML

4.24 [A+] XML: HTML y XHTML

En el siguiente vídeo se explican las diferencias entre XML, HTML y XHTML.

XHTML es el acrónimo de eXtensible Hypertext Markup Language, en castellano Lenguaje extensible de marcado de hipertexto.
XHTML es el lenguaje de marcado pensado para sustituir a HTML como estándar para las páginas web.
Si XHTML es el sucesor de HTML, ¿qué relación existe con XML?
En su versión 1.0, XHTML es solamente la versión XML de HTML, por lo que tiene, básicamente, las mismas etiquetas y funcionalidades, pero cumple las especificaciones, más estrictas, de XML.
Recordemos que HTML, XHTML y XML son los tres estándares de facto desarrollados por el World Wide Web Consortium, el W3C, un consorcio internacional que produce recomendaciones para la World Wide Web.
Desde la publicación de la primera página web en diciembre de 1990, el lenguaje HTML ha ido mejorando con nuevas versiones. En noviembre de 1995 se publicó HTML 2.0. En enero de 1997 HTML 3.2. Y en diciembre de 1997, apareció HTML 4.
La última revisión, HTML 4.01, se publicó en diciembre de 1999.
En enero de 2000 se publico XHTML 1.0, una reformulación de HTML 4 utilizando XML 1.0.
Una revisión de XHTML 1.0 fue publicada en agosto de 2002.
XHTML es el lenguaje de marcado pensado para sustituir a HTML como estándar para las páginas web.
En su versión 1.0, XHTML es solamente la versión XML de HTML, por lo que tiene, básicamente, las mismas funcionalidades, pero cumple las especificaciones, más estrictas, de XML.
XHTML incorpora a las páginas web el rigor de XML, lo cual se traduce en un mejor procesamiento, un mantenimiento más sencillo y es el primer paso hacia la llamada web semántica.
Desgraciadamente, todas estas promesas se pararon en seco a mediados del año 2009.
En julio del año 2009, el W3C anunció que cuando el grupo de trabajo de XHTML 2, la próxima versión de XHTML, terminase su trabajo a finales de 2009, no iba a ser renovado, ya que el W3C quería aumentar los recursos destinados a HTML 5. Finalmente, en diciembre de 2010 el grupo de trabajo de XHTML 2 fue definitivamente cerrado.
¿Y qué es HTML 5? HTML 5 es la quinta y última versión, por ahora, del lenguaje de etiquetado HTML.
Pero, ¿qué pasó con XHTML?
XHTML 1.0 fue publicado en el año 2000, y en los siguientes años se desarrollaron numerosas tecnologías que lo complementaban o que lo iban a suceder. Desgraciadamente, todas estas tecnologías complicaron bastante el desarrollo y el uso de XHTML.
En el año 2004, algunos miembros de Apple, Mozilla Foundation y Opera Software fundaron el Web Hypertext Application Technology Working Group porque no estaban contentos con la evolución de XHTML y con la falta de interés del W3C por las necesidades reales de los desarrolladores web.
De forma independiente, este grupo empezó a desarrollar su propia visión de cómo debía ser la próxima versión de HTML.
En el año 2006, el W3C mostró su interés por participar en el desarrollo de HTML 5, y en el año 2007, el W3C formó un grupo de trabajo destinado a trabajar con el WHATWG en el desarrollo de la especificación de HTML5.
Por tanto, el W3C abandonó sus trabajos sobre XHTML 2.0, y pasó a centrar su interés en HTML 5, versión que está actualmente en desarrollo y que se espera que se termine en 2014.
Entonces, ¿está muerto XHTML?
No, para nada, no está muerto. Existen millones de sitios web y miles de herramientas basados en XHTML.
Más aún, HTML 5 se está desarrollando con dos sintaxis, una basada en XHTML y otra basada en HTML. Por tanto, tiene mucho sentido seguir trabajando con XHTML los próximos años.
A continuación, vamos a ver las principales diferencias que existen entre HTML y XHTML 1.0.
En HTML 4 existen tres variantes del lenguaje: la versión estricta, la versión transicional y la versión con marcos.
En XHTML 1.0 se conservan las tres variantes, pero claro están, con sus propios DOCTYPEs. Así tenemos la versión estricta, la versión transicional y la versión con marcos.
En la página web “Lista recomendada de declaraciones de Doctype” del W3C podemos en encontrar estas declaraciones que acabamos de ver y algunas más.
En esta misma página web del W3C también podemos encontrar esta plantilla para crear un nuevo documento XHTML 1.0. Este documento está configurado para el juego de caracteres UTF-8. Si se quisiera utilizar otro juego de caracteres, como por ejemplo ISO-8859-1, también llamado Latin-1, habría que añadir esta declaración de documento XML y habría que cambiar el valor del juego de caracteres en esta etiqueta.
Para comprobar si una página XHTML está correctamente escrita, se puede emplear algún validador como por ejemplo el que proporciona el W3C.
Veamos a continuación las principales diferencias que existen entre HTML y XHTML 1.0. Debido a que XHTML es una aplicación de XML, ciertas prácticas que eran posibles en HTML, que está basado en SGML, ahora no son posibles.
Pero en primer lugar recordemos la estructura de un elemento HTML. Un elemento HTML se compone de una etiqueta inicial y una etiqueta final que tienen el mismo nombre. La etiqueta inicial puede llevar atributos, pero la final nunca lleva. En HTML, los atributos pueden llevar un valor. Por último, las etiquetas pueden tener contenido: el contenido puede estar formado por otras etiquetas de HTML o puede ser simplemente texto como en este ejemplo.
En primer lugar, los elementos anidados deben tener un correcto orden de apertura/cierre: el que se abre el último, debe cerrarse el primero. Por ejemplo, en HTML, es posible este ejemplo, pero esto es totalmente imposible en XHTML porque los elementos están superpuestos. La forma correcta de escribirlo en XHTML sería la siguiente.
Los elementos, los nombres de elementos y atributos deben de ir siempre en minúsculas. Esto es debido a que XML diferencia las mayúsculas y minúsculas. En HTML, es posible escribir las etiquetas y atributos en mayúsculas y minúsculas, sin ningún problema. En XHTML esto es totalmente incorrecto, todo tiene que estar escrito en minúsculas.
Los elementos vacíos deben cerrarse siempre: o bien aparece la etiqueta final, o bien la etiqueta inicial termina con />. En HTML, los elementos vacíos no llevan etiqueta de cierre. Por tanto, se pueden escribir directamente de esta forma. Sin embargo, esto es incorrecto en XHTML. En XHTML, o se cierra la etiqueta o se escribe con una etiqueta vacía.
Los elementos no vacíos también deben de cerrarse siempre en XHTML. En HTML se permite no cerrar ciertos elementos, ya que se cierran de forma implícita. Pero esto es totalmente imposible en XHTML.
Por ejemplo, la etiqueta <p> de párrafo se puede no cerrar en HTML, pero esto está mal en XHTML. En XHTML los elementos se deben de cerrar siempre.
Los valores de los atributos deben siempre ir encerrados entre comillas simples o dobles. En HTML, los valores de los atributos se pueden escribir sin comillas. Sin embargo, esto es incorrecto en XHTML, siempre hay que encerrar los valores de los atributos entre comillas dobles o comillas simples.
No está permitida la minimización de atributos. En aquellos casos en que el atributo no tiene definido un conjunto de valores, sino que simplemente está o no está, se usa el nombre del atributo como único valor posible. En HTML, es posible minimizar los valores de los atributos, y simplemente se escribe el nombre del atributo como vemos aquí en este ejemplo <dl compact> o <option selected> o <input checked>. Esto es totalmente incorrecto en XHTML. En XHTML se tiene que asignar siempre un valor y se toma la regla de asignarle como valor el mismo nombre del atributo.
El tratamiento de los espacios en blanco en los valores de los atributos varía en XHTML respecto a HTML:
Los espacios en blanco al principio y al final se eliminan.
Y uno o más espacios en blanco, incluyendo los saltos de línea, se traducen en un único espacio en blanco entre las palabras del valor de un atributo.
En XHTML, el contenido de la etiqueta <script> y <style> está definido como #PCDATA. Como resultado de ellos, los símbolos < y & se interpretan por parte del procesador de XML como inicio de etiqueta y como entidad de carácter. Si se encierra el contenido de script o de estilo con CDATA se evita este comportamiento. Como alternativa más cómoda, también se pueden almacenar en ficheros separados.
En SGML se pueden definir exclusiones: evitar que ciertos elementos sean contenidos en otros elementos. Esto no es posible definirlo en XML y, por tanto, tampoco en XHTML. En XHTML no se pueden definir de forma formal a través del DTD, sino que sólo se puede proporcionar en forma de lista.
En HTML 4, tanto el atributo name como el atributo id se pueden emplear para identificar un fragmento de código. En XHTML sólo es posible emplear el atributo id.
En HTML, el tratamiento de los atributos con conjuntos de valores predefinidos, como align o type, es no sensible a mayúsculas y minúsculas. Sin embargo, en XHTML sí que es sensible a las mayúsculas y minúsculas y se deben escribir siempre los valores en minúsculas.
En HTML, las referencias de entidad se pueden escribir como &X y el código hexadecimal o como &x y el código hexadecimal. En XML, y por tanto en XHTML, sólo se puede emplear la versión en minúsculas.
Y con esto termina este videotutorial sobre las diferencias entre HTML y XHTML. Como hemos visto, estas diferencias están originadas por el hecho de que XHTML es una aplicación de XML que impone una serie de reglas más estrictas.
Si necesitas más información o quieres contactar conmigo, en mis páginas web http://accesibilidadweb.dlsi.ua.es y en http://desarrolloweb.dlsi.ua.es podrás encontrar más información sobre la accesibilidad web y el desarrollo web o también puedes contactar directamente conmigo a través de mi dirección de correo electrónico sergio.lujan@ua.es.

4.23 [A+] HTML: ¿migrar a un nuevo juego de caracteres?

4.23 [A+] HTML: ¿migrar a un nuevo juego de caracteres?

Debes ver el vídeo "HTML: ¿migrar a un nuevo juego de caracteres?" en el que plantean diferentes posibilidades ante el problema de migrar o no migrar un sitio web que ya existe a otro juego de caracteres.

Antes de empezar, me gustaría recordarte algunos de los sitios web en los que puedes encontrar más información sobre mí y sobre mi trabajo, y dos formas de contactar conmigo, a través de mi correo electrónico sergio.lujan@ua.es y a través de mi cuenta en Twitter @sergiolujanmora.
Antes de ver este vídeo te recomiendo que veas los vídeos “HTML: juego de caracteres” y
“HTML: el juego de caracteres y los editores de texto”, que te ayudarán a entender mejor qué es el juego de caracteres.
En esos dos vídeos el consejo que doy es que lo mejor es usar el juego de caracteres UTF-8 sin BOM, ya que es la solución a todos los problemas que pueden aparecer con el juego de caracteres y permite mezclar en un mismo documento textos en cualquier idioma, es decir, te permite mezclar caracteres de cualquier alfabeto.
Pero, ¿qué pasa si ya tenemos un sitio web con otro juego de caracteres? ¿Debemos migrar el sitio web al juego de caracteres UTF-8 sin BOM? Vamos a analizarlo con un caso real,
la situación que me ha planteado un amigo que es alumno de este curso.
Mi amigo es biólogo y empezó a hacer páginas web en el año 1996. Sus primeras páginas web las hacía con el programa Microsoft Frontpage.
Desde hace varios años, mi amigo mantiene un sitio web sobre rutas de montaña, de senderismo, muy popular, con un buen número de visitas.
Mi amigo me mandó el siguiente mensaje al ver uno de mis vídeos:
Una duda técnica. Después de ver el último vídeo que has publicado sobre codificación UTF-8 sin BOM, me he dado cuenta de dos cosas. Una, de que eso existe. Dos, que en mi editor de HTML (Dreamveawer 8) las nuevas páginas están configuradas como tipo de documento (DTD: XHTML 1.0 Transitional) y codificación (encoding: europeo occidental). Sobre la codificación, no hay problema para ponerla en UTF-8 sin BOM, pero con respecto al tipo de documento, ¿cuál de las siguientes posibilidades que me ofrece debo escoger?: HTML 4.01 Transitional, HTML 4.01 Strict, XHTML 1.0 Transitional, XHTML 1.0 Strict, XHTML Mobile 1.0.
Y continúa:
Esto es más que nada para hacer la práctica del curso, aunque también me bajaré Notepad++ a ver si me acostumbro. Aparte de eso, ya me he dado cuenta de que todo lo que he escrito más o menos desde 2004 está en XHTML 1.0 Transitional y europeo occidental. Supongo que algún día tendré que validar y limpiar todo ese código. ¿Es tan simple como guardar las páginas con la nueva codificación, o se debe hacer una revisión completa y manual para detectar errores? Tampoco estoy pensando en revisar todo lo viejo, sino de aprovechar lo que funcione bien, se entiende.
Mi amigo usa Dreamweaver 8. Cuando se crea un nuevo documento, aparece un asistente que permite elegir la categoría de documento que se quiere crear. Cuando se elige crear una página web, se tiene que elegir el tipo de documento, el DTD que se quiere aplicar. El DTD, el DOCTYPE, indica la versión de HTML que se usa.
Además, en las propiedades de un documento también se puede definir la codificación, el encoding del documento, el juego de caracteres.
Al final, todo esto se traduce en dos cosas en el código HTML:
En el DOCTYPE en el que se indica la versión de HTML.
Y en la etiqueta meta charset en la que se indica la codificación o juego de caracteres.
Mi amigo usa el juego de caracteres ISO-8859-1, también llamado Latin1,
que Dreamweaver llama “Europa occidental”, porque es el mejor juego de caracteres para los idiomas de Europa occidental, incluido el español. No hay ningún problema en usar este juego de caracteres, pero mi amigo hace algo que no es necesario.
Mi amigo escribe los caracteres que no pertenecen al juego de caracteres ASCII, como las vocales acentuadas y la eñe como referencias de carácter con nombre.
En el vídeo “HTML: tres errores típicos” ya expliqué que cuando se escribe el código así, a veces es muy difícil de leer.
¿Este código está mal? No, no está mal, pero si se emplea el juego de caracteres adecuado, y mi amigo está utilizando ISO-8859-1, que es un juego de caracteres adecuado, entonces escribir el texto así es totalmente inútil porque no es necesario y no aporta ninguna ventaja.
Volviendo al correo de mi amigo, le contesté lo siguiente:
Este consejo (utilizar UTF-8 sin BOM) es para la creación de las páginas nuevas. En tu caso, yo te aconsejo que sigas como hasta ahora, no te vale la pena realizar una migración si ahora mismo no tienes ningún problema. No hay ningún problema para trabajar con Europeo Occidental (ISO-8859-1/Latin1) si no tienes que incluir idiomas con otros alfabetos o no te vas a conectar con otro sistema que tenga otra codificación.
Mi amigo podría tener problemas si se conecta a una base de datos y no elige el juego de caracteres adecuado, o si utiliza un servicio web que le devuelve los datos en un juego de caracteres distinto al suyo, pero en principio no tiene planes de hacer nada de esto.
Y continuaba con mi respuesta:
Digamos que "UTF-8 sin BOM" es la solución fácil para todo y que te asegura que no tendrás problemas en el futuro, pero usar Europa Occidental es una buena opción, es más, es lo mejor porque ahorras espacio.
¿Qué significa “ahorrar espacio”?
Vamos a hacer una prueba. Me bajo el fichero HTML de la página principal de la Universidad de Alicante.
Y con el Notepad++ lo convierto del formato original, UTF-8 sin BOM a ISO-8859-1 o Latin1.
Si comparamos los tamaños de los ficheros, comprobamos que la versión original de la página web, que está en formato UTF-8 sin BOM, la que podemos ver a la izquierda, ocupa 360 bytes más que la versión en formato Latin1, que aparece a la derecha. Esto se debe a que ciertos caracteres, las vocales acentuadas o la eñe, ocupan 2 bytes en vez de uno.
Y por último, le decía a mi amigo:
Respecto al DOCTYPE, sí que te aconsejo que utilices <!DOCTYPE html>, para HTML5, en tus nuevas páginas. Si no, sigue con el XHTML 1.0 Transitional.
¿Por qué le aconsejo esto? Porque es muy probable que en un plazo corto de tiempo le interese aprovechar algunas de las nuevas características de HTML5.
Y para terminar, ¿cómo podemos convertir fácilmente un conjunto de páginas de una codificación a otra? Es decir, ¿cómo puedo migrar un sitio web de una codificación a otra?
Pues en Windows no es fácil. En Linux y Mac OS X es fácil desde la línea de comandos.
Por un lado, tenemos el comando file que nos permite conocer el tipo y la codificación de un fichero y por otro lado tenemos iconv, que convierte la codificación de un fichero de una codificación a otra.
En Windows, el único método que conozco es utilizar un editor de texto, como por ejemplo
el Notepad++ y convertir fichero a fichero nuestro sitio web.
Por último, en el sitio web del W3C dedicado a la internacionalización podemos encontrar mucha información sobre el juego de caracteres. Te recomiendo la lectura de los artículos
“Codificación de caracteres: conceptos básicos” y “Selección y aplicación de codificación de caracteres”.

Espero que estos vídeos te ayuden a entender qué es el juego de caracteres, y lo sepas utilizar un poco mejor.


4.20 ¿Y ahora qué?

4.20 ¿Y ahora qué?

Si has llegado hasta aquí y has leído todas las lecciones, has visto todos los vídeos y has hecho todos los ejercicios debes de haber aprendido muchas cosas, pero el haber llegado hasta aquí no es el final de tu aprendizaje, más bien es el principio.
Todavía te quedan muchas cosas por aprender de HTML. Gracias a este curso tienes una base para seguir aprendiendo por tu cuenta. Pero quedan muchas más cosas que vas a aprender con nosotros, pero eso será en la segunda parte de este curso.

4.19 Presentación del proyecto

4.19 Presentación del proyecto


Objetivos


  • Mejorar el sitio web con la incorporación de nuevos elementos como las tablas, las imágenes y los nuevos controles de formulario de HTML5.
  • Comprobar que todas las páginas web están correctamente escritas y no presentan errores.
  • Publicar en Internet el sitio web formado por varias páginas conectadas mediante enlaces.

Qué tengo que hacer


En este módulo tienes que mejorar las páginas de tu sitio web con la incorporación de nuevos elementos, como las tablas y las imágenes.

Recuerda que las tablas no las tienes que utilizar para distribuir el contenido en tus páginas web: las tablas son para mostrar datos tabulados, no para maquetar el contenido de las páginas web. La maquetación se realizará mediante CSS (Cascading Style Sheets), la tecnología que se explicará en la segunda parte de este curso. Si quieres saber más cosas sobre esto te recomendamos la lectura de Porqué diseñar con tablas es estúpido: problemas definidos, soluciones ofrecidas.

También puedes mejorar los formularios de tu sitio web con la incorporación de los nuevos controles que añade HTML5. HTML5 ya es un estándar, fue publicado como recomendación el 28 de octubre de 2014 (HTML5 - A vocabulary and associated APIs for HTML and XHTML), pero eso no significa que todas sus características se puedan emplear: no todos los navegadores actuales admiten las nuevas características y por supuesto existe un problema de compatibilidad con los navegadores antiguos. Por tanto, antes de usar una nueva característica te recomendamos que consultes algún sitio web en el que puedas comprobar el grado de compatibilidad de las nuevas características de HTML5:


Por último, en este proyecto también te pedimos que escribas páginas web válidas, páginas web que se ajustan al estándar. Muchas personas han aprendido a hacer páginas web por la simple observación de cómo están hechas las páginas web y eso ha conducido a que se repitan malas prácticas. En el artículo Obsolete practices to avoid se indican algunas cosas que no se deben hacer en las páginas web porque son erróneas o han quedado obsoletas (ya no tiene sentido hacerlas). Al principio de este artículo se indica un problema que se da muchas veces:

Many people learned HTML, CSS, and JavaScript by viewing the source of pages and then copying and pasting them, without considering whether or not the original site was well implemented. This means that they have perpetuated coding practices that might have been necessary in the past, but are irrelevant now.This article tries to list older coding practices that over time have become unnecessary or bad practices.

Traducido al español:

Muchas personas aprendieron HTML, CSS y JavaScript mediante la visualización del código fuente de las páginas y luego copiaban y pegaban el código, sin tener en cuenta si el sitio web original estaba bien implementado. Esto significa que se han perpetuado prácticas de codificación que podrían haber sido necesarias en el pasado, pero que son irrelevantes ahora.

Tienes que aprender a utilizar las herramientas que te pueden ayudar a validar el código HTML de tus páginas web. Por ejemplo, te recomendamos que utilices Markup Validation Service del W3C.

Por último, no te olvides de publicar en Internet tu sitio web.



4.18 HTML5: ¿Por qué es importante escribir código correcto? (3/3)

4.18 HTML5: ¿Por qué es importante escribir código correcto? (3/3)

En este vídeo se explica qué es el DOM (Document Object Model) y por qué es la razón por la que los navegadores muestran una página de diferentes formas cuando tiene un error.


En la primera parte de este videotutorial vimos las principales cuatro razones que pueden ocasionar que no se vea igual una página web en todos los navegadores. Vimos lo
importante que es escribir código HTML correcto para que una página web no se rompa.
En la segunda parte vimos cinco ejemplos sencillos que contenían errores que producían que una página web no se mostrase igual en todos los navegadores.
Las pruebas las realizamos en el sistema operativo Windows 7 con los cuatro navegadores web más comunes: Mozilla Firefox 3.6, Google Chrome 10, Internet Explorer 8 y Opera
11.
Al final, vimos que ante algunos errores los navegadores mostraban el mismo comportamiento, mientras que frente a otros errores había diferencias importantes en el
comportamiento.
¿A qué se debe este errático comportamiento de los navegadores frente a los errores de una página?
La clave está en el DOM, el Document Object Model. Con el DOM vamos a entender por qué una página web que tiene errores no se visualiza igual en todos los navegadores.
La mayoría de la gente que hace página web no tiene ni idea de qué es el DOM. Y los que sí lo conocen, suelen tener muchas lagunas o ideas erróneas sobre él.
El DOM es una recomendación del World Wide Web Consortium, el W3C, el consorcio internacional que produce recomendaciones para la Web.
En la traducción al castellano de la versión 3 de la especificación del DOM encontramos el apartado “¿Qué es el Modelo de Objetos del Documento?”, donde se nos define el
DOM:
El Modelo de Objetos del Documento (DOM) es una interfaz de programación de aplicaciones (API) para documentos válidos HTML y bien construidos XML. Define la estructura
lógica de los documentos y el modo en que se accede y manipula.
Y en otro punto de la especificación podemos leer:
En DOM, los documentos tienen una estructura lógica que es muy parecida a un árbol; para ser más preciso, es más bien como un "bosque" o una "arboleda", que puede contener
más de un árbol. Cada documento contiene cero o un nodo doctype, un nodo de elemento de documento, y cero o más comentarios o instrucciones de tratamiento; el elemento del
documento sirve como la raíz del árbol para el documento.
Con un ejemplo lo entenderemos mejor. Tenemos este fragmento de un documento HTML, que representa una tabla con dos filas y dos columnas.
El DOM es una representación en forma de árbol de una página web. Es sencilla, pero para su comprensión y uso correcto hace falta realizar un proceso de abstracción que
mucha gente es incapaz de realizar.
La representación en forma de árbol de este fragmento es la siguiente:
Los rectángulos representan nodos de tipo elemento, mientras que los óvalos representan nodos de tipo texto. La raíz del árbol es la etiqueta <table>, que contiene un sólo
hijo con la etiqueta <tbody>, el cual a su vez tiene dos hijos, los cuales a su vez también tienen dos hijos.
Una vez que sabemos qué es el DOM, que es el Document Object Model, vamos a aplicarlo para entender por qué una misma página web se visualiza de diferente forma en
diferentes navegadores.
Vamos a empezar con el ejemplo que ya vimos en la parte anterior de este videotutorial en el que se empleaba la etiqueta <span> con el atributo style y la propiedad font-
weight de CSS para mostrar el texto en negrita.
En este ejemplo, esta etiqueta <span> no se cierra en el párrafo y tampoco se cierra en el documento.
En Mozilla Firefox el efecto de la etiqueta <span> finaliza cuando termina el párrafo en la que se encuentra.
En Google Chrome podemos ver que la presentación de la página es igual que en Mozilla Firefox.
Pero en Internet Explorer aparecen diferencias y todo aparece en negrita hasta el final del documento.
Por último, Opera también se comporta igual que Internet Explorer y la etiqueta <span> que no se cierra actúa hasta el final del documento.
Para entender por qué los navegadores se comportan de diferente forma debemos comparar el DOM que construye cada navegador a partir del código HTML de la página.
Aquí podemos ver el DOM en Mozilla Firefox. Podemos ver como la etiqueta <span> que no está cerrada en el código HTML, el navegador la cierra automáticamente en este punto,
antes de que finalice el párrafo. Por ello, cuando se muestra la página, el texto de este párrafo sí que aparece en negrita, pero el siguiente no, porque la etiqueta <span>
ya ha sido cerrada antes.
Sin embargo, en Opera, el DOM que se construye es distinto. Como podemos ver aquí, como la etiqueta <span> no se ha cerrado en el código HTML, todo lo que aparece a
continuación se considera parte del contenido de la etiqueta <span> que no se ha cerrado. Por eso, todo el texto que aparece a continuación se muestra en negrita. Pero al
actuar de esta forma, se llega a una representación de la página que es inconsistente con la especificación oficial de HTML, ya que un párrafo de texto no puede contener
otros párrafos de texto.
En el siguiente ejemplo el error está en la etiqueta <link> que enlaza con una hoja de estilo que está en otro fichero. En esta etiqueta, el valor del atributo rel no tiene
la comilla de cierre.
La página es muy sencilla: contiene un encabezado y un párrafo de texto.
La hoja de estilo CSS también es muy sencilla. Contiene dos reglas, body y h1, para definir el tamaño y el tipo de letra de toda la página, y para definir el tipo de letra
y el color del encabezado.
¿Cómo se verá esta página?
En Mozilla Firefox parece que el error no produce ningún efecto negativo en la visualización de la página: el encabezado aparece con el tipo de letra Garamond y en color
rojo, y el resto del texto de la página aparece con el tipo de letra Verdana.
Sin embargo, en Google Chrome esto es lo que se muestra: absolutamente nada.
En Internet Explorer parece que la hoja de estilo CSS no se tiene en cuenta. Además, podemos ver que en la página aparece el código de la etiqueta <link>.
Y en Opera se vuelve a mostrar absolutamente nada.
Aquí tenemos el DOM que Mozilla Firefox construye a partir del código HTML. Como podemos ver, Firefox ha descartado el atributo rel que no tenía la comilla de cierre.
Además, se ha recuperado correctamente frente a este error y ha construido el árbol del documento como se esperaba.
En el caso de Google Chrome, el navegador descarta la etiqueta <link> y todo lo que aparece a continuación hasta el final de la página. Por eso la página aparece vacía
cuando se muestra.
En el caso de Internet Explorer, el navegador ha descartado toda la etiqueta <link> que estaba mal escrita y la ha movido al <body>, al cuerpo de la página, como podemos
ver aquí. Por eso se muestra en la página. Pero a diferencia de Google Chrome, Internet Explorer en algún momento (por ejemplo, al encontrar la etiqueta <body>) se ha
recuperado correctamente y muestra, de forma correcta, el resto de la página.
Por último, en el caso de Opera, podemos ver que el navegador asume que todo lo que aparece a continuación del atributo rel forma parte del valor del atributo, ya que no se
ha cerrado la comilla. Por eso, en la página no aparece nada, aparece vacía, todo forma parte del atributo rel, como podemos ver aquí.
El último ejemplo es una modificación del anterior, en el que se ha añadido una etiqueta <div> con un atributo id. Como podemos observar por el color verde del editor,
parece que el editor cierra esta comilla que no hemos cerrado en este punto. Y todo esto va a formar parte del valor del atributo. Esto es una señal de lo que van a hacer
los navegadores.
La hoja de estilo CSS es también la del ejemplo anterior, pero le hemos añadido esta regla “almohadilla contenido” para que el contenedor <div> se muestre con un color de
fondo gris.
En Mozilla Firefox, el encabezado y el texto aparecen correctamente. Sin embargo, el contenedor <div> no aparece con el color de fondo gris.
Como veremos a continuación, el resto de navegadores tienen el mismo comportamiento.
En Google Chrome, en Internet Explorer, y en Opera se muestra el mismo resultado.
Aquí tenemos el DOM, el árbol que construye Mozilla Firefox. Podemos ver que el navegador ha considerado que el valor del atributo rel va desde esta comilla hasta esta otra
comilla. Lo que viene a continuación lo ha transformado en un nuevo atributo, como podemos ver aquí, “contenido” se ha transformado en un nuevo atributo. Y a partir de ahí
ha seguido correctamente con la interpretación del código. La etiqueta <body> ha desaparecido, porque ha pasado a formar parte del atributo rel, pero el navegador la ha
incorporado al DOM automáticamente, ya que siempre debe existir. Como el <div> ha desaparecido, la página no se muestra con el color de fondo gris.
En Google Chrome, también parece que todo lo que aparece a continuación del atributo rel hasta la siguiente comilla lo ha considerado parte del valor del atributo.
“contenido” lo interpreta como un nuevo atributo de la etiqueta <link>, como podemos ver aquí. Y a partir de ahí el navegador se ha recuperado de forma correcta.
Internet Explorer hace algo parecido a Mozilla Firefox y Google Chrome y por eso la página se muestra igual. Podemos ver aquí como Internet Explorer, todo lo que viene a
continuación también lo mete en el valor del atributo rel hasta que se encuentra la comilla. Y “contenido” también lo ha transformado en un nuevo atributo de la etiqueta
<link>.
Y por último Opera también muestra un comportamiento similar, aquí tenemos el valor del atributo rel que vuelve a ser lo mismo y “contenido” también lo ha vuelto a
transformar en un atributo de la etiqueta <link> y a partir de este punto se ha recuperado correctamente en la presentación de la página web.
En resumen, hemos visto que la clave para entender los diferentes comportamientos de los navegadores es el DOM, el Document Object Model. Los navegadores construyen un
mismo DOM, un mismo árbol, a partir de un código HTML correcto, pero cuando el código contiene errores, cada navegador puede construir un árbol diferente.


viernes, 10 de febrero de 2017

4.17 HTML5: ¿Por qué es importante escribir código correcto? (2/3)

4.17 HTML5: ¿Por qué es importante escribir código correcto? (2/3)

En este vídeo se muestran algunos ejemplos de errores en el código HTML:
  • Etiqueta <b> sin cerrar.
  • Etiqueta <span> sin cerrar.
  • Comillas del valor de un atributo sin cerrar (2 versiones).
  • Valor del atributo size de la etiqueta "input" incorrecto.
En la primera parte de este videotutorial estuvimos viendo por qué muchos desarrolladores web se plantean alguna vez por qué una página web se ve bien en todos los navegadores pero no en alguno concreto.
Vimos las principales cuatro razones por las que una página web se puede visualizar de forma incorrecta en un navegador.
De estas cuatro razones, las tres primeras están fuera del control de los desarrolladores web. La última causa sí que depende de los desarrolladores web, de las personas que hacen las páginas web, y es la que vamos a tratar en este videotutorial.
Para demostrar por qué es importante escribir código HTML correcto, vamos a ver cinco ejemplos sencillos en los que se aíslan algunas situaciones de error típicas.
Las pruebas que vamos a ver a continuación se han realizado en Windows 7 con los cuatro navegadores web más comunes: Mozilla Firefox 3.6, Google Chrome 10, Internet Explorer 8 y Opera 11.
Veamos el primer ejemplo. Este es el código HTML de una página sencilla. En el segundo párrafo hay una etiqueta <b> de negrita que no ha sido cerrada al final del párrafo. En el tercer párrafo vuelve a aparecer la etiqueta <b> de negrita, pero esta vez sí que ha sido cerrada al final del párrafo. ¿Cómo se visualizará esta página en los diferentes navegadores?
Antes que nada, comprobemos que esta página realmente tiene un error. Para ello, vamos a usar el “HTML and markup validator del W3C”. Validamos la página web y el validador nos indica que la página tiene 6 errores. ¿6 errores? Si vemos el informe completo de validación, el primer error nos indica correctamente que existe alguna etiqueta que no ha sido cerrada. Pero el resto de errores son falsos y desaparecerán una vez que se haya corregido el primer error.
Veamos ahora como se visualiza la página en los diferentes navegadores.
En Mozilla Firefox, desde el punto de inicio de la etiqueta <b> que no se cierra hasta el final de la página, todo aparece en negrita.
Como ahora veremos, el resto de navegadores se comporta igual.
En Google Chrome comprobamos que ocurre lo mismo, toda la página se muestra en negrita.
Igual en Internet Explorer 8.
Y por último, vemos que la página se visualiza igual en Opera 11.
Por tanto, la conclusión a la que llegamos es que los navegadores, hasta que no se cierra la etiqueta <b> de negrita, su efecto continúa hasta el final de la página.
Veamos ahora otro ejemplo. A partir del ejemplo anterior, sustituimos la etiqueta <b> de negrita por la etiqueta <span> con el atributo style que incluye la propiedad font-weight de CSS para mostrar el texto en negrita.
No es exactamente lo mismo, pero un navegador web debería presentar esta página web igual que el ejemplo anterior, ya que el efecto visual que se consigue es el mismo.
Como podemos ver, en Mozilla Firefox hay un cambio importante respecto el ejemplo anterior: el efecto de la etiqueta <span> finaliza cuando termina el párrafo en la que se encuentra.
En Google Chrome podemos ver que la presentación de la página es igual que en Mozilla Firefox. El efecto de la etiqueta <span> finaliza cuando finaliza el párrafo y por tanto, el siguiente párrafo no aparece en negrita.
Pero en Internet Explorer aparecen diferencias y este navegador se comporta de forma similar a cómo lo hace en el ejemplo anterior y todo aparece en negrita hasta el final del documento.
Por último, Opera también se comporta igual que Internet Explorer y todo aparece en negrita.
Por tanto, en este ejemplo, Mozilla Firefox y Google Chrome tienen un comportamiento similar, la etiqueta <span> la cierra automáticamente cuando se llega al final del párrafo, mientras que Internet Explorer y Opera muestran la página de la misma forma, la etiqueta <span> no la cierran y su efecto actúa hasta el final de la página.
En el siguiente ejemplo el error está en la etiqueta <link> que enlaza con una hoja de estilo CSS que está en otro fichero. En esta etiqueta, el valor del atributo rel no tiene la comilla de cierre.
El editor de texto ya nos avisa de que hay un problema en el código HTML ya que a partir de este punto todo el código aparece pintado en verde, como si todo fuese el valor de un atributo.
La página es muy sencilla: contiene un encabezado <h1> y un párrafo de texto.
La hoja de estilo CSS también es muy sencilla. Contiene solamente dos reglas, una para definir el tamaño y el tipo de letra de toda la página y otra para definir el tipo de letra y el color del encabezado.
¿Cómo se verá esta página?
En Mozilla Firefox parece que el error no produce ningún efecto negativo en la visualización de la página: el encabezado aparece con el tipo de letra Garamond y en color rojo, y el resto del texto de la página aparece con el tipo de letra Verdana.
Sin embargo, en Google Chrome esto es lo que se muestra: absolutamente nada, no hay página.
En Internet Explorer parece que la hoja de estilo CSS no se tiene en cuenta. Además, podemos ver que en la página aparece el código de la etiqueta <link>.
Y en Opera se vuelve a mostrar absolutamente nada.
Como podemos ver, por falta de una comilla puede desaparecer toda una página web. Desgraciadamente, mucha gente no le da importancia a errores como éste.
El siguiente ejemplo es una modificación del anterior, en el que se ha añadido una etiqueta <div> con un atributo id. Como podemos observar por el color verde, parece que el editor de textos cierra el atributo que no se había cerrado, el atributo rel, lo cierra correctamente en este punto. Esto puede ser una señal de lo que van a hacer los navegadores y de cómo van a interpretar esta página web.
La hoja de estilo CSS es también la del ejemplo anterior, pero le hemos añadido esta regla #contenido para que el contenedor <div> se muestre con un color de fondo gris.
Así es como se debería mostrar la página web si no tuviera el error del valor del atributo que no se cierra su comilla, vemos que el <div> se muestra con un color de fondo gris.
En Mozilla Firefox, el encabezado y el texto aparecen correctamente, con el tipo de letra y con el color adecuado. Sin embargo, el contenedor <div> no aparece con el color de fondo gris.
Como veremos a continuación, el resto de navegadores tienen el mismo comportamiento.
En Google Chrome, en Internet Explorer, y en Opera se muestra el mismo resultado.
El comportamiento de los navegadores coincide con el comportamiento del editor de textos: este atributo, el atributo rel, se cierra en este punto y, por tanto, la etiqueta <div> se rompe y no se tiene en cuenta en la presentación de la página por el navegador.
Y llegamos al último ejemplo. En este ejemplo se muestra un formulario que contiene cuatro cuadros de texto. En tres de los cuadros de texto se incluye el atributo size para modificar el tamaño del cuadro de texto. En este atributo size se ha cometido un error: parece que pone “treinta”, pero en realidad pone “tres o”.
Como podemos ver aquí, cuando un cuadro de texto no tiene definido un tamaño con el atributo size, el valor por defecto es 20. En Mozilla Firefox, el valor “tres o” se interpreta como “tres”.
En Google Chrome se observa el mismo comportamiento que en Mozilla Firefox, el primer cuadro de texto tiene un tamaño 20, el segundo un tamaño 30 que es el que se indica en el código HTML, el tercer cuadro de texto tiene un tamaño 3, que es la interpretación de “tres o”, y el último cuadro de texto tiene un tamaño 3.
En Internet Explorer cambia la forma de interpretar el valor “tres o”. El navegador le asigna el valor por defecto que es 20, el navegador no reconoce este valor como válido y le asigna el valor por defecto.
Por último, en Opera se observa el mismo comportamiento que en Internet Explorer: al detectar un valor no correcto, se le asigna el valor por defecto.
Resumamos los cinco ejemplos que hemos visto.
En el ejemplo de la etiqueta <b> no cerrada, los cuatro navegadores se comportan de la misma forma. En el ejemplo de la etiqueta <span> no cerrada, Mozilla Firefox y Google Chrome muestran el mismo comportamiento, mientras que Microsoft Internet Explorer y Opera se comportan de igual forma. En el primer ejemplo de las comillas no cerradas, Firefox, Chrome e Internet Explorer muestran un comportamiento distinto, mientras que Opera muestra un comportamiento similar a Chrome. En el segundo ejemplo de las comillas no cerradas los cuatro navegadores muestran un comportamiento similar. Y en el último ejemplo, Firefox y Chrome muestran el mismo comportamiento, mientras que Microsoft Internet Explorer y Opera se comportan de igual forma.
¿A qué se debe este errático comportamiento de los navegadores? Lo veremos en la tercera y última parte de este videotutorial.