O sea, the making of.
Algunas ideas sobre los tipos de letra
La pesadilla de la codificación de las URI
Compiladores/Procesadores de Lenguajes
Metodología de la programación
MoreLab (en DeustoTech)
EPI (Euskarazko Programazio Ingurunea)
[2002-10-20]
Todo empezó en el otoño de 1996. Ya llevaba unos meses trasteando con el nuevo juguete, Internet. Me había llamado mucho la atención eso de que se pudieran tener páginas personales en servidores de organizaciones o instituciones (no me refiero al "alojamiento" que ahora permiten las multinacionales del ramo). Yo iba a la página de una universidad, por ejemplo:
http://www.foouniversity.edu/
y veía que uno que trabajaba allí se había preparado unas páginas en:
http://www.foouniversity.edu/~bart/
y eso a mí me parecía genial: un espacio libre para poner lo que quisieras, y abierto al mundo entero.
Me enteré que esa posibilidad la daba casi automáticamente el hecho de colocar el sitio www.foouniversity.edu en una máquina UNIX o Linux (que justo estaba despegando también) con el servidor web Apache. Entonces, solo hacía falta que bart fuera una cuenta de usuario en esa misma máquina, porque configurando el servidor httpd adecuadamente, la coletilla ~bart/ del URI anterior llevaba al directorio de usuario de dicha cuenta. Se colocaba el típico archivo index.html y venga, a que te conocieran por ahí.
El caso es que, por razones que no vienen al caso, unos cuantos profesores de la Universidad de Deusto teníamos entonces cuenta en la máquina Linux que hacía de servidor web de la Universidad, en la dirección:
http://www.deusto.es/
Y claro, tenía Apache, así que me fui a dormir soñando con mi primera dirección de la telaraña mundial:
http://www.deusto.es/~josuka/
Después de unos días dando la paliza a los administradores (Alberto Cano, que luego dejó la Universidad, y Aitor Ibarra, que afortunadamente sigue soportándonos en líos similares) para configurar Apache, el 6 de noviembre de 1996 me convertí en el primer profesor de la Universidad de Deusto con página personal de Internet. Por cierto, que como no podía estar sin decírselo a nadie, inmediatamente avisé a mis colegas Andoni Eguiluz y Joseba Abaitua, que no perdieron el tiempo y enseguida pusieron sus páginas.
Otro otoño, esta vez de 1999, nos dijeron que la máquina www.deusto.es ya no iba a ser la que nos alojaba también como usuarios. Consecuencia: adiós a nuestra dirección de páginas personales. A los profesores de ESIDE nos buscaron alojamiento en el servidor propio de la Facultad, con lo que el 29 de noviembre de 1999 mi URI pasó a ser la actual dirección:
http://www.eside.deusto.es/profesores/josuka/
que no está mal, pero es notablemente más larga. También cambiaba el servidor de la máquina, porque es el IIS de Microsoft.
Como ves, parece que solo cada tres otoños se enciende la lucecita que indica que mis páginas necesitan una remodelación, y no solamente estética, porque la verdad es que no tocaba los contenidos casi desde entonces. Espero ser esta vez más constante.
[2003-01-09]
El 20 de diciembre de 2002 dejó de existir el URI de los últimos tres años:
http://www.eside.deusto.es/profesores/josuka/
porque han creado un servidor específico para las páginas personales de los profesores de la Universidad. A partir de ahora se me encuentra en:
http://paginaspersonales.deusto.es/josuka/
que ciertamente es algo más simple que el anterior. Pero estos cambios son un poco fastidiosos, espero que esta vez dure años.
[2004-03-24]
La primavera la sangre altera. Nunca más cierto (a pesar de que el tiempo en Bilbao estos días no es precisamente primaveral). El caso es que me ha dado por aportar colorido brutal a las páginas, jubilando el claramente obsoleto fondo que tanto tiempo me había llevado diseñar, y que coloco aquí a modo de reliquia:
Lo más importante es lo que no se ve: también abandono el uso de tablas para aportar estructura a las páginas, utilizando en su lugar las divisiones y las capacidades de las hojas de estilo de colocación flotante de elementos. Sobre este tema, aviso, escribí cosas hace tiempo, más abajo en esta misma página, que ahora pueden ser un tanto contradictorias.
[2002-10-25]
La versión actual de las páginas está codificada con el lenguaje XHTML 1.1, con una presentación basada en hojas de estilo CSS 2. Ambos lenguajes son desarrollados y estandarizados por un organismo llamado The World Wide Web Consortium (W3C), cuya página principal es muy recomendable y permite acceder a todos los aspectos relacionados con la telaraña mundial.
Como probablemente sabes, la filosofía subyacente es hacer que el contenido (la página HTML) sea puramente contenido, mientras que las cuestiones de presentación queden reflejadas solo en la hoja de estilos. De esa manera, por ejemplo, se puede muy fácilmente cambiar la visualización sin necesidad de cambiar el contenido. También es interesante darse cuenta que el conjunto resultante tiene menor tamaño, con lo que las transmisiones de las páginas son más rápidas.
Particularmente, puedes ver en el pie de mis páginas unos iconos que indican que la codificación ha sido correcta, tanto en lo que se refiere al lenguaje de marcado como a la hoja de estilos. Si pinchas en ellos, se realizará la verificación, servicio proporcionado por el propio W3C. Te recomiendo que lo hagas con tus páginas, mediante el verificador de HTML y el verificador de CSS.
En cuanto a los navegadores, se supone precisamente que el uso de lenguajes estándar permite que mis páginas puedan verse con cualquier navegador, pero claro, solamente si está preparado para entender XHTML 1.1 y CSS 2, lo cual no está del todo claro todavía. Por lo menos, Mozilla 1.1 sí lo hace, y me permito decirte que se trata de un gran navegador, sin nada que envidiar a los otros más conocidos.
Sin embargo, este es un tema bastante complejo, que merece la pena desarrollar con más profundidad.
Hay que darse cuenta de lo importante que es utilizar una definición estándar de las tecnologías de Internet, o de programación o de tantas cosas.
¿Cuántos fabricantes de tornillos hay en el mundo mundial? Imagina que no se ponen de acuerdo, no solo entre sí, sino con los fabricantes de roscas (o sea, de los aparatos donde se colocan los tornillos). Un caos. Por tanto, han de establecerse especificaciones consensuadas que todos sigan, de manera que las cosas funcionen y los fabricantes de aparatos sepan cómo hacer las roscas y los fabricantes de tornillos sepan cómo hacer tornillos que puedan usarse alguna vez.
Cuando desarrollas una página telaraña eres el fabricante de tornillos, y el que la quiere ver es el dueño del aparato con roscas, en el cual necesita usar tus tornillos. El que construye el navegador es el fabricante de ese aparato. Por tanto, para que la cosa funcione, hay dos que tienen que ponerse de acuerdo: el fabricante de páginas y el fabricante de navegadores, y fíjate que hay uno que no tiene nada que ver con el tema, que es el usuario (tanto de tornillos como de roscas, tanto de páginas como de navegadores), y que normalmente es el que sale perdiendo siempre. Sobre los fabricantes de navegadores hablaremos en el siguiente apartado, pero está claro que la otra mitad del asunto, el que diseña páginas telaraña tiene la mitad de la responsabilidad: tiene que usar un estándar.
¿Quién establece las especificaciones comunes? Una comisión en la que participen tanto los fabricantes de tornillos como los de roscas. Hay varias organizaciones que se dedican a organizar esas comisiones y desarrollar documentos de especificaciones estándar: ISO es la más conocida, aunque hay otras.
En lo relacionado con la telaraña mundial, el organismo que desarrolla las especificaciones estándar es el W3C. El 23 de octubre de 2002 tiene 447 miembros, que incluyen lo más florido de las nuevas tecnologías, es decir, que por falta de representación no creo que sea. Así que si desarrollas páginas, ya sabes, a pasar por su portal de vez en cuando.
Hace poco, era la consigna preferida de los que querían estar a la última:
Se ve mejor con el navegador X
No, no, y mil veces no. Cuando usas un navegador, aunque no te cueste dinero (eso habría que matizarlo), lo que quieres es que te funcione, que te deje ver todas las páginas (o por lo menos, las que se han construido bien), porque si no, estás perdiendo el tiempo, y eso hoy en día también es muy importante. El que fabrica un navegador tiene la responsabilidad de hacer que la especificación estándar completa se muestre adecuadamente. Hoy en día, eso significa ser capaz de mostrar XHTML 1.1 y CSS 2, porque las recomendaciones definitivas del W3C a este respecto son del 31 de mayo de 2001 y del 12 de mayo de 1998, respectivamente, y creo que ya han pasado (23 de octubre de 2002) unos cuantos meses desde entonces.
¿Por qué el fabricante del navegador tiene una gran responsabilidad en este tema? Porque es fácil cometer dos errores, uno leve y otro grave. El leve consiste en que inadvertidamente muestre mal algún elemento, o que simplemente no lo tenga en cuenta: se trata de un fallo, se supone que se subsana en la siguiente revisión del navegador, y fuera.
El error grave es modificar, con pleno conocimiento de causa, la definición estándar, ya sea variando elementos o añadiendo otros, y encima con el propósito de incorporar supuestas nuevas funcionalidades que darán ventaja a ese navegador sobre los de la competencia. Esto significa el caos otra vez.
Imagina que uno de los fabricantes de aparatos con rosca, con una gran cuota de mercado, decide que sus roscas van a ser especiales, que no van a servir los tornillos que tenías hasta ahora, y que vas a tener que comprar otros. ¡Qué bonito! Todo el sector de fabricación de tornillos a expensas de lo que decida un solo fabricante de roscas.
Vale, el fabricante de roscas dice: "es que el consorcio estandarizador no va tan rápido como yo en el desarrollo de los nuevos super-ultra-tornillos". Yo creo que eso no pasa en el W3C. Sin conocerlo en profundidad, de sus páginas se deduce que hay gran actividad en todos los frentes abiertos. Por ejemplo, están en fase de desarrollo nuevas versiones, tanto del lenguaje de marcado (XHTML 2.0) como de las hojas de estilos (CSS 3), habiendo prevista en este último caso una recomendación definitiva para abril de 2003.
En cualquier caso, aunque los fabricantes de navegadores incorporen nuevas funcionalidades no estándar, aquí vuelve a ser importante la actitud del autor de contenidos para la telaraña, que ha de tratar de no caer en la tentación, sino ceñirse al estándar, que es lo que se supone que mostrarán perfectamente todos los navegadores (suficientemente actualizados, claro).
Bueno, parece que mis opiniones son algo simplistas. En este artículo de Eric Meyer puedes ver una opinión bastante más autorizada que la mía. Por otro lado, me imagino que en The Web Standards Project (WaSP) también se discutirá este asunto; aunque me gustaría conocer su posicionamiento ideológico, no he tenido tiempo de leerlos. Y aquí tienes otra opinión.
El autor de páginas telaraña suele usar aplicaciones WYSIWYG para desarrollar sus contenidos y estilos de presentación. Por supuesto, estas aplicaciones tienen que tener las mismas características que los navegadores en cuanto a cumplimiento de las especificaciones estándar, y no añadir supuestas mejoras propias.
Aquí hay que hacer una mención especial a un tipo de desarrollo que últimamente ha proliferado por ahí, que es el uso de sistemas "dinámicos", tipo FlashPlayer y otros. Estas aplicaciones están bien (bueno, ya veríamos...) para la presentación de elementos muy puntuales de los contenidos, pero opino que no como soporte principal de la estructura completa de un sitio determinado, por muy impactante que pueda resultar. No hay que olvidar el gran tamaño que habitualmente resulta de dichos desarrollos, con lo que eso significa de ralentización de la red y demás.
[2002-10-30]
Los colores de los títulos de nivel 2 y nivel 3 son los siguientes:
Los colores de los enlaces:
Los tres nombres de color (en inglés, claro) pertenecen a la lista de 16 que se admiten en HTML.
Aquí tengo que explicar una cosa. Parece ser ya tradicional que el color del texto de los enlaces sea azul, y todo el mundo está ya acostumbrado a buscar este color para saber dónde pinchar. Si me he permitido modificar este estado de cosas ha sido por una importante razón personal: ¡odio el azul! (¡uy! menos el de mi universidad, claro).
Y en las imágenes, aunque hablaré luego de ellas, el color es RGB#936B6E o 147/107/110. Algunos llaman "carmesí" (crimson) a este color, pero otros le dicen "granate". Lo que sea, a mí me mola.
Los tipos de letra (mucha gente dice "fuentes" porque en inglés es fonts, pero opino que está mal dicho) son importantes para la legibilidad, tanto de texto impreso, como en la telaraña. Hay que elegir un tipo base para el texto común, y usar otros tipos distintos (o variedades de los mismos) para aspectos que se quieran recalcar o diferenciar semánticamente. Pero resulta que este tema es uno de los que mayores problemas de dependencia de la máquina produce en los sistemas informáticos, e Internet no iba a ser menos.
Empecemos por el principio. ¿Qué es un tipo de letra? Si no te suenan las palabras proporcional, monoespaciada, letra romana o serif, letra paloseco o sans-serif, puedes leer esta otra página.
Vale, ahora nos entendemos un poco mejor. Una de mis grandes dudas era (y sigue siendo) si usar una letra paloseco o sans-serif como texto común. Desde luego, si has pasado por la página anterior, ya sabrás que este estilo no es nada recomendable para este propósito en el texto impreso. Pero para la pantalla, quizás ocurra al revés, aunque me gustaría saber si alguien ha hecho alguna vez un estudio de legibilidad a este respecto. De momento, lo voy a dejar así, pero cualquier día me da el viento.
En la hoja de estilos, por lo tanto, he puesto como tipo de letra base (propiedad font-family) la familia genérica sans-serif. Así, te dejo la libertad de que elijas con la configuración de tu navegador la familia concreta de este estilo que más te guste. Hay una que se llama Verdana, que la veo más legible que Helvetica o Arial, pero sufre un ligero problema filosófico (otra adivinanza más).
En cuanto a las variedades, los títulos van en negrita y un tamaño algo mayor, suelo usar el elemento tt de HTML para las palabras informáticas (como las dos anteriores, precisamente), y suelo poner en cursiva palabras o frases que no sean español.
La estructura espacial de las páginas está basada en tablas. Hay una tabla "encabezado", con el título y los enlaces que llamaremos secundarios: a la misma página o páginas dependientes de la actual. La tabla "cuerpo" tiene normalmente dos columnas (salvo la principal, que tiene tres): en la columna izquierda están los enlaces primarios (más o menos equivalente a un mapa, que no deja de ser un índice) y en la derecha los contenidos propiamente dichos. Finalmente, hay una tabla "pie", con la fecha de actualización como elemento más importante.
Los anchos de las columnas se definen con porcentajes, lo que pienso que es importante para que la estructura se observe correctamente con cualquier resolución o aunque la ventana del navegador no esté maximizada. Espero que sea así.
Sin embargo, aquí hay también lío filosófico, faltaría más, así que disponte a leer otro rollo.
Te habrás fijado que el URI de cada una de mis páginas lleva la extensión .asp. No digas nada, a mí también me fastidia un rato. Aparte de que ya te he dicho que, en estos momentos, mi servidor es el que es, te explico la razón de usar ASP.
¿Ves el índice que aparece en la columna de la izquierda? Es el mismo en todas las páginas. Si un día lo cambio porque meto otros enlaces, tendría que editar todas las páginas, seguro que me equivoco, etc. Solución fácil que de momento aplico: el código de esa columna lo pongo suelto en un archivo, y con un programita ASP el servidor lo coloca en cada página según se solicita. Mi religión impide que verbalice el nombre del lenguaje de programación en que está escrito el programita, y el mérito es principalmente de Ander Barbier, que fue quien me ayudó a descubrir el método clave para su funcionamiento.
El formato GIF no debería ser usado a la ligera: aquí te explican las razones. Quedan dos alternativas: el formato JPEG o el formato PNG. Sobre este último formato en particular, consultar esta página, y para información general sobre formatos gráficos, puedes mirar este otro sitio.
Mis ideas preconcebidas (seguro que erróneas) sobre este tema son que JPEG suena a "ligeramente obsoleto", mientras que PNG parece "más moderno". Total, que algunas nuevas figuras, mayormente las de la página sobre los tipos de letra, las he formateado en PNG, y efectivamente han resultado de bastante buena calidad, tamaño irrisorio, etc. Muy bien, me dispongo a hacer lo mismo con ciertas fotos en blanco y negro y color que tengo por ahí, y sorpresa: los PNG ocupan hasta 10 veces más que los JPEG, y eso con igual o peor calidad final. ¿Cómorrr? De momento, se quedan como JPEG, por supuesto, a la espera de que alguien me explique que está pasando.
Pues ya te lo imaginas: el bloc de notas. Así de claro, si no te lo crees, es problema tuyo. Lo importante es que sea una herramienta que, con los caracteres adecuados, permita escribir código XHTML 1.1 correcto, con las especificaciones de estilo CSS 2 adecuadas.
Estas dos últimas cosas prefiero tenerlas bajo mi control, así que escribo yo mismo las etiquetas; realmente, una vez que desarrollas la estructura principal, el etiquetado se reduce a copiar y pegar etiquetas que ya están escritas en otros sitios, y lo verdaderamente laborioso es escribir el contenido. Al final, verifico cada página con los enlaces que se encuentran al pie, y a correr.
El primer tema es, otra vez, más peliagudo, aunque a primera vista parezca trivial. ¿Qué caracteres pueden usarse? Teóricamente, y dejando aparte (por cierto, no me puedo resistir: ¿eres de los que escriben "a parte"? No, si todavía te va a servir esto para algo...) de momento una implementación Unicode multiocteto o UTF-8, lo normal será usar caracteres de un octeto. Lo más aceptado, creo yo, en el mundo occidental es la norma ISO 8859-1, para la cual te señalo, entre otros, los siguientes enlaces:
Bien, entonces el sistema de la computadora tiene que estar preparado para entender códigos de carácter ISO 8859-1 (en principio, supondremos que todos los navegadores lo hacen). Eso significa que la herramienta de edición de textos debe establecer correctamente los códigos que corresponden a cada signo o imagen de carácter. Supuesto esto, solo hay que colocar al principio de cada página HTML lo siguiente:
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1"/>
... otros elementos ...
</head>
Vale, yo tengo ese sistema operativo (mira que te lo he dicho veces), y la pregunta entonces es: ¿soporta ISO 8859-1? Leyendo algunos de los enlaces anteriores, podrás comprobar que ese sistema usa una codificación llamada CP 1252, que no es ISO 8859-1, pero esta vez puede arreglarse: resulta que los artífices de ello decidieron que 32 casillas que estaban supuestamente vacías en ISO 8859-1 (desde x80 hasta x9F) podían usarse para poner un montón de nuevos caracteres (bueno, ni siquiera pusieron 32, solo 26, y últimamente han añadido uno en la posición x80 precisamente). Muy creativos: esos caracteres se pensaron, en ISO 8859-1, como nuevos caracteres de control a añadir a los que van desde x00 hasta x1F, por eso no representan signos visibles.
Por lo tanto, lo que hay que hacer si tienes ese sistema operativo, es no usar bajo ningún concepto los caracteres desde x80 hasta x9F, porque afortunadamente el resto, desde xA0 hasta xFF, sí son los mismos que en ISO 8859-1. De esta manera, no son necesarias muchas de las referencias a entidades de carácter que se usan mucho al escribir en español, es decir, las vocales acentuadas, las eñes, y los signos iniciales de interrogación y exclamación (¡¿por qué todo el mundo se olvida de ponerlos?!), que es uno de los problemas principales si uno usa un editor de texto exclusivamente ASCII. Y eso simplifica mucho escribir, claro.
Puedes ver la hoja de estilo que utilizo para presentar las páginas: josuka.css, donde quedan reflejadas muchas de las cosas que te cuento.
Copyright © 2002-2004 JosuKa Díaz Labrador
Facultad de Ingeniería, Universidad de Deusto, Bilbao, España
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
Última modificación: 2004-03-24. Accesos al sitio: 554827
