12-09-2011

Doctypes y HTML5

Un agrado. Trabajar ahora con HMTL5 nos da la magia de hacer una declaración para el Doctype de tamaño minúsculo.

Doctypes

Los Doctypes de trabajo anteriores pasaban por una cantidad increíble de declaraciones, desde los Doctypes estrictos (strict) y los relajados (transitional) e incluyendo los marcos (framesets). Aparte de ello debían contener la versión y tipo de documento al que se aludían, desde HTML4.01 al XHTML1 y XHTML1.1. Las distintas declaraciones incluían problemas graves por el simple hecho de agregar un elemento no permitido en el esquema (que obviamente está bien, pero visualizar la página en forma errónea en vez de no visualizarla es una opción que vale la pena pensarla). Incluso en ocasiones todo dependía del browser y cómo interpretaba la declaración del esquema.

Ahora eso se acabó.

Doctype HTML5

El Doctype de HTML5 es simple: <!DOCTYPE html>

Aparte de ser simple, las ventajas que tiene son muchas. Primero que nada es compatible con las versiones anteriores de los Doctypes. Segundo, es tan estricto o relajado dependiendo de lo estricto o relajado que sea uno con el código. Tercero, soporta el cierre de tags de XHTML. Cuarto, en los documentos de trabajo de HTML5 se incluyó una guía de qué debería pasar cuando se cometen ciertos errores en la sintaxis del HTML, por lo que los browsers muestran problemas consistentes con los mismos errores. Se acabó la época en que un browser mostraba el contenido bien porque ignoraba el error al visualizarlo, y en el otro todo se desarmaba porque sus instrucciones para el manejo de errores eran demasiado estrictas. Hoy, al fin, casi podemos hablar que tenemos estándares.

 

Salud por eso.

 

Technorati Tags: ,,,

19-04-2011

Mejoramiento Progresivo

Resolviendo el problema de ser accesible a través de navegadores, a pesar de las versiones y el tiempo, sin dejar de mejorar.

(Partes pensadas en base a Developing with Web Standards, de John Allsopp)

La idea poder desarrollar y diseñar los sitios web de tal forma que se consiguiera la interoperabilidad a través de navegadores e incluso entre sus propias versiones (lamentablemente me refiero a IE más que a ningún otro en esto último), no es nada nuevo para quienes hemos estado metidos en este mundo del metalenguaje hipertextual de la red.

Recuerdo que alrededor del año 2000 la discusión se centraba en las incongruencias entre IE5 y Netscape 4, con IE6 haciendo entrada triunfal y destronando a sus competidores, tanto en la estandarización de sus métodos, como en la forma de llamarlos.

Hoy, el escenario ha cambiado tanto que en pocos años Microsoft ha sacado 3 versiones de su navegador, siendo la última uno de sus mejores logros, Firefox se ha posicionado como una opción muy atendible (sobre todo en su calidad de software libre de desarrollo no propietario), Chrome es ya un nuevo jugador en el mercado y Safari y Opera se mantienen como una buena opción, a una buena distancia del resto, pero no por ello menos merecedores de ser nombrados y tomados en cuenta.

Sin embargo, dichos cambios han demostrado que cada día es más importante tener en cuenta no sólo qué se diseña y cómo, sino que, de qué forma y hacia quiénes para producir qué. Para eso, hay que entender por qué hoy se habla tanto de algo que hasta hace poco era sólo campo para los especialistas en lenguas y para los diseñadores gráficos que se quedaron fascinados por el lenguaje y la comunicación: la semántica.

X/HTML

El HyperText Markup Language, publicado por Tim Berners Lee en 1991, fue creado con el fin de marcar y denotar internamente texto, principalmente, científico. La idea original fue marcar/denotar el significado y la estructura del documento (su semántica).

Las definiciones no ayudan mucho a comprender la idea, pero podríamos resumirla en que la semántica es el significado de varias partes del lenguaje y que para el caso del HTML, consiste en aplicar reglas de Sintaxis (reglas que los desarrolladores deben seguir para producir lenguaje válido y significativo), como que nunca puede haber una etiqueta sin cerrar (mediante los corchetes <h1></h1>) y que estas etiquetas dan un orden de significado respecto al contenido (semántica) de tal manera que, por ejemplo, nunca puede haber un encabezado H1 dentro de una sección iniciada por un texto H1 que, originalmente tenga menor valor en el documento que el H1 inicial. Me refiero a:

1) H1---H2---H3---H4
                H2---H3
                           H3---H4---H5---H6

2) H1---H2---H3---H4
                H1---H2
                           H6---H3---H1---H2

Donde 1) está correcto y 2) tiene errores en la semántica.

Mejoramiento Progresivo

Lo importante a la hora de comprender el Mejoramiento Progresivo, es que su propósito es definir, la información y funcionalidad del documento, comenzando desde un enfoque macro, para luego ir dando paso a mejoras en la apariencia y el comportamiento del documento relacionados con navegadores y herramientas más modernas: lo micro.

Los pasos que podríamos definir para ello son:

  1. Revisar la Semántica del documento.
  2. Revisar la Sintaxis del documento.
  3. Aplicar la gráfica general básica, separada del lenguaje.
  4. Mejorar la gráfica, diagramación y programación.
  5. Revisar para no alterar lo conseguido en los puntos anteriores. Si se rompe volver al 4, si no, dar por terminado o pasar a un nuevo nivel de mejoramiento.

Para conseguir esto, actualmente contamos con dos aliados que han venido a salvar lo que antes, sólo podía conseguirse con tediosas horas de buscar scripts de java, hacks y cosas por el estilo. HTML5 y CSS3.

Si bien, ambos pertenecen a tecnologías que llevan años de desarrollo y que esperan estar listas (terminadas y absolutamente documentadas) en unos 5-6 años, no hay para qué esperar. Todos los navegadores en este momento presentan un nivel de funcionamiento bastante bueno de ambas. Su aplicación no choca con la tecnología anterior y se puede desarrollar fácilmente mediante el mejoramiento progresivo.

El futuro es brillante y no hay excusas para no abrazar la nueva paradoja. Si quieren esperar 5 años para recién comenzar a usar estas tecnologías y estos métodos de trabajo, adelante, pero no digan que nadie les avisó.

15-04-2011

Nueva imagen.



Este será el nuevo logo de Hiperescriba, ahora que me decidí a escribir de nuevo y que tengo de qué escribir también.



19-01-2011

Reglas de Contención en HTML

Block Elements: Headings, Paragraphs, Preformatted Text, Divs, Ordered Lists, Unordered Lists, Definition Lists.

Block Elements pueden contener otros Block Elements e Inline Elements.

Block Elements sólo pueden ser contenidos dentro de Block Elements.

Inline Elements sólo pueden contener Inline Elements.

Inline Elements pueden ser contenidos tanto en Block Elements como en Inline Elements.

Paragraphs son Block Elements, pero no pueden contener otros Block Elements.