Vivencias personales, tecnología, y hobbies.

miércoles, 19 de septiembre de 2007

Me caso

Pues si... Me caso.

Supongo que la expresión adecuada es "Nos casamos", "Mi novia y yo, nos casamos", porque casarse uno mismo, mucho sentido no tiene, la verdad.

¿Y qué es casarse? ¿Es firmar un papel? ¿Es hacer el paripé? ¿Un gran e inútil gasto?

Supongo que cada uno tiene una percepción del matrimonio, y aunque, en un principio, la idea de casarnos era mas por asuntos legales que otra cosa, ahora creo que adquiere otros significados adicionales.

Evidentemente, casarse o no casarse, no es premisa para demostrar que se quiere mas o menos, pero sin duda es un paso mas en la vida de pareja, que, bien pensado, es bonito. La idea de unirse "mas" a la pareja (si... aunque sea una simple firma, no deja de ser adquirir mas compromiso), siempre está presente, y eso, es otro paso.

Me desvío... Sábado 24 de noviembre, "that's the great day!".
Decidimos casarnos en un pueblo, por la sencilla razón de que en Palma, hay cola de espera de más de 1 año... y eso, tira para atrás a cualquiera, y ahora que se acerca la fecha, me gusta el destino elegido: Puigpunyent, y mas concretamente, en el ayuntamiento. Y el banquete lo haremos en Santa María, en el Ruycal.

Tenemos todo bastante cerrado, aunque los últimos preparativos, que no son pocos, los está gestionando mas Patry, yo entre que me levanto a las 6, llego a las 19, entreno, me ducho, y estudio... pfff. Me podrían alargar el día unas horas, la verdad.

En resumen, que me caso!

viernes, 14 de septiembre de 2007

HTML / XHTML y nuestro querido DOCTYPE

Antes de adentrarnos en la materia, daré unas especificaciones, para no perdernos en el camino, de una serie de acrónimos:

HTML 4.0 Aplicación SGML (Lenguaje de Etiqueta Generalizado Estándar) conforme al estándar ISO 8879, ampliamente considerado como lenguaje de publicación estándar del WWW (World Wide Web).

SGML Lenguaje para describir lenguajes de Etiquetas, particularmente los basados en intercambio de documentos electrónicos, manejo de documentos y publicación.

XML Lenguaje de Etiqueta extensible, concebido para sacar lo mejor de SGML y evitando su complejidad.

Diferencias entre HTML y XHTML

  • Nombres de elementos y atributos en minúsculas. El XML es sensible a la utilización de mayúsculas y minúsculas.
  • Todos los valores de los atributos deben ir entrecomillados (comillas tanto simples como dobles).
  • Todos los elementos "no vacíos" deben ir entre la etiqueta de principio y la etiqueta de final, todos los elementos que no estén declarados en la DTD con EMPTY deben tener una etiqueta de cierre.
  • Todos los elementos deben estar anidados ordenadamente.
  • El XML no soporta la minimización de atributos. Los pares atributo-valor deben escribirse en toda su extensión.
  • Los elementos "vacíos" deben llevar terminación, los cuales deben tener una etiqueta de cierre o bien terminar su etiqueta de apertura con />.
Los XHTML deben incluir el tipo de documento, su utilización es obligatoria, y es necesario que antes del elemento raíz exista una declaración DOCTYPE. El identificador público incluido en la declaración DOCTYPE a alguna de las tres siguientes DTD: strict, transitional y Frameset.

Características más importantes:

  • Strict: Se utiliza cuando se da formato a los textos a través de CSS (cuando no se recurre a las etiquetas font, etc. La declaración debe ser:
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  • Transitional: Se utiliza cuando no se describe la presentación de los documentos por medio de hojas de estilo. La declaración debe ser de la siguiente manera:
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  • Frameset: Se utiliza cuando los documentos incorporan marcos. La declaración:
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

El elemento raíz del XHTML debe ser y en el debemos declarar el namespace usando el atributo xmlns. EL namespace para XHTML es: "http://www.w3.org/1999/xhtml"

En XHTML, los elementos style y script se declaran como elementos con contenido #PCDATA. El único carácter que no está permitido dentro es el que indica el cierre de la marca CDATA, es decir, el código ]] >.

Se puede evitar la utilización de las secciones CDATA, incluyendo los códigos en archivos externos:

<script language="JavaScript" src="global.js"></script>
<link href="style.css">

Para poder validar el documento se requiere en el mismo directorio la DTD xml html1-strict.dtd (o la que usemos) y los archivos de entidades a los que hace referencia. Después sólo nos queda validar el documento con algun parser de XML.

Para validar el documento XML se puede utilizar cualquier parser de XML.

Convertir HTML en XHTML


Son necesarios dos pasos para convertir un documento HTML en un documento XHTML válido.
  • Que esté bien formado
  • Que sea válido respecto de alguna de las tres DTD que conforman el XHTML.

Y nuestros amigos de la W3C hacen el resto -> http://validator.w3.org/

XHTML y los navegadores actuales

XHTML se visualizan sin problemas en IE5 y posteriores, pero no es así en todos los navegadores, en algunos de éllos hay problemas debido a los elementos vacíos (<br/>, <hr/>)

Aunque, según la especificación no hay ninguna obligación de que los documentos XHTML 1.0 sean compatibles con los navegadores existentes, en la práctica es fácil de conseguir:
  • Elementos vacíos . Incluir un espacio en blanco antes de la barra y ángulo de cierre / y >
  • Minimización de elementos . Dado un elemento vacío cuyo modelo de contenido no es empty, como por ejempo un título o un párrafo, no utilizar la forma minimizada, escribirlo como:<p> </p> en lugar de <p></p>
  • Hojas de estilo y archivos de código incrustados . Usar hojas de estilo externas o archivos de código externo si la hoja o el código en cuestión utiliza los caracteres < > o --. Notar que los analizadores XML tienen permitido suprimir el contenido de los comentarios.
  • Saltos de línea dentro de valores de atributos . Evitar saltos de línea y múltiples espacios en blanco dentro de los valores de los atributos.
  • Identificadores de fragmentos . En XML, los URI que terminan con identificadores de fragmentos del tipo #identificador no se refieren a elementos con un atributo name=identificador, sino que se refieren a elementos con un atributo de tipo ID. Muchos navegadores actuales no soportan este uso de atributos de tipo ID, de tal manera que se pueden dar valores idénticos a ambos atributos para asegurar la máxima compatibilidad futura y retroactiva.
  • Uso del carácter & amp; en valores de atributos. Cuando el valor de un atributo contenga un carácter &, debe expresarse como una referencia a la entidad de tipo carácter.
  • Codificación de caracteres . Para especificar una codificación de caracteres en el documento, usar tanto la especificación del atributo de codificación en la declaración XML como una sentencia meta http-equiv. El valor del atributo de codificación de la instrucción de proceso XML tiene preferencia.


Recomendación W3C de XHTML1.1 (31 mayo 2001) define un nuevo tipo de documento que está basado en un marco de módulos que están definidos en el documento de modularización de XHTML. Se busca que este nuevo tipo de documento sea la base para extender la familia XHTML y proveer consistencia, compatibilidad para aquellas opciones a eliminar (deprecated). Esta recomendación básicamente es una reformulación de XHTML 1.0 Strict incluyéndole el uso de módulos XHTML.

XHTML 1.1 da de baja el soporte para:
  • Base basefont
  • Center font
  • Frame frameset
  • Iframe isindex
  • Menu noframes
  • Object s
  • strike

El tipo de documento XHTML 1.1 esta hecho de los siguientes módulos, los cuales están definidos en el documento Modularización de XHTML.
  • Modulo Estructural: body, head, html, title
  • Modulo Texto: abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var.
  • Modulo Hipertexto: a
  • Modulo Lista: dl, dt, dd, ol, ul, li
  • Modulo Objeto: object, param
  • Modulo Presentación: b, big, hr, i, small, sub, sup, tt
  • Modulo Editar: del, ins
  • Modulo Texto Bidireccional: bdo
  • Modulo Formas: button, fieldset, form, input, label, legend, select, optgroup, option, textarea
  • Modulo Tablas: caption, col, colgroup, table, tbody, td, tfoot, th, thead, tr.
  • Modulo imagen: img
  • Modulo Mapa lado Cliente: area, map
  • Modulo Mapa lado Servidor: Attribute ismapon img
  • Modulo eventos intrínsecos: Atributos Events
  • Modulo Metainformación: meta
  • Modulo de Scripts: noscript, script
  • Modulo Hoja de estilos: elementos style
  • Modulo Atributo Style: Deprecated : atributo style
  • Modulo link: link
  • Modulo base: base

Extraído y reescrito. (Fuentes: W3C, WikiLearning, http://www.tejedoresdelweb.com/, etc)

lunes, 10 de septiembre de 2007

Estándares, ¿Por qué?

Después de leer algunos artículos por la red, en los cuáles se habla de las razones por las que es necesario seguir los estándares, me he visto "obligado" a enumerarlas, comentarlas y añadir algunos de mis puntos de vista acerca del tema.

Antecedentes.
Antes de empezar con el tema, pondré en antecedentes a los lectores profanos a los "estándares" de internet.
Basicamente, y resumiendo bastante, son un compendio de recomendaciones que da la W3C (World Wide Web Consortium) a la hora de crear o leer documentos que estén basados en la Web, con la intención de crear un mundo Web mas accesible y usable para todos.

Beneficios.
Aquí podemos sacar una larga lista, que voy a intentar ir argumentando.

Gracias al uso de XHTML y CSS, actualmente es relativamente "sencillo" aislar totalmente el diseño del contenido de un web, cosa que todo sea dicho, es mucho mas beneficioso de lo que puede llegar a parecer leerlo.

Motores de búsqueda: El XHTML válido (y las CSS) son muchísimo mas relevantes para los motores, ya que son "máquinas" a las que se les "enseña" qué leer y qué no leer, y la forma correcta de leerlo (estándares), por tanto un mejor código suele implicar un mejor posicionamiento en buscadores, cosa que hoy día, está claro que es muy importante.

Compatibilidad: Basándonos en estándares, haremos que mas gente pueda acceder a nuestra web, ya sea con distintos navegadores, como distinos sistemas operativos, dispositivos móviles, PDAS, etc, etc...

Accesibilidad: Ayudamos a que personas con discapacidades puedan utilizar su contenido (BRAILE, etc)

Mantenimiento: Obviamente, un sitio que siga los estándares, y aisle totalmente su diseño de su código, es mas fácilmente actualizable, permitiendo ahorrar en desarrolladores (aunque tiro piedras sobre mi tejado, jejeje).

Ancho de banda: Parece mentira, y actualmente al poder acceder a mayores anchos de banda esto pasa mas inadvertido, pero probablemente un site bien montado y respetando estándares, reduciendo códigos etc, debería ser mas rápido a otro que no.

Rapidez: Que provoca el punto anterior.

Resumiendo (opinión).
Siempre defiendo este tema ante compañeros de trabajo y/o profesión, algunos opinan como yo, otros no (para gustos los colores, ¿no?), pero mi opinión es que el tiempo nos va dando la razón, y el tema de las validaciones cobra cada día mas importancia, prueba de ello, por ejemplo, son los posicionamientos en motores de búsqueda.
Sin olvidar que poco a poco, todo este "movimiento" desemboca en la "web semántica", de la cuál hablaremos mas adelante.

En resumen, si hay unos estándares, ¿por qué no seguirlos?, en realidad no exige tanto trabajo como puede llegar a parecer, además, como dije arriba, el tiempo nos da la razón, y seguir los estándares estrictamente nos ayuda, y nos ayudará mas en el futuro.

Saludos,
Joan.

PS: Obviamente se podría extender muchísimo la entrada, pero todo se andará.

Hola mundo!

No podría ser de otra manera, mi primera entrada en el blog tenía que ser el "Hola mundo!".
¿Acaso un programador puede empezar de otra manera? ;-)

Datos personales

Palma, Baleares, Spain
Programador, "Músico", Friki, ¿Persona?