Revista electrónica. Estudiantes de Postgrado en Filosofía PUCV
Durante la semana pasada, un amigo me comentaba sobre sus primeros pasos para aprender algo de HTML, y con ello vino la inevitable pregunta… ¿y tú cómo aprendiste?, y que debido al poco tiempo que tuvimos para seguir conversando, quedó inconclusa.
Ahora, haciendo memoria y sin tratar de latear a nadie, creo que en verdad se me haría imposible identificar de dónde he aprendido sobre HTML, y mucho menos sobre CSS y PHP, porque en verdad creo que mi única forma de aprender ha sido simplemente haciendo. Seguro, aquellos manuales que hace mil años en la entonces revista(-impresa) Mouse fueron una excelente base, en tiempos en que (si la memoria no me falla) lo más nuevo era HTML 3.2 y Netscape Navigator aún era el rey del mercado.
Y desde entonces (por allá en 1996/97) que nunca paré… mi primer sitio “importante” fue un directorio de enlaces a los sitios de bandas de heavy/speed/power/black metal, todo hecho con Bloc de notas… ¡se imaginarán lo fácil que era mantener ese sitio! ¡Sin siquiera utilizar CSS, tenía que definir los estilos de cada bloque de texto cada vez! Según Wikipedia, recién en 1999 se publicó el primer navegador con un real soporte de CSS, es decir, mayor del 99%… irónicamente, este era MSIE 5 para Mac.
Pero bueno, antes de desviarme… después de ello, vino mi sitio de Pink Floyd que después terminó en la desaparecida Ciudad Futura, y luego, para hacerle compañía, uno de Rolling Stones, era el tiempo de la burbuja .com (la primera, quiero decir), y como era lógico, cuando reventó, me quedé sin host.
Prácticamente todo el resto de la historia está en este blog: lo pueden ver en el primer post, Buscando un espacio para yukei y la muerte del free hosting. Entonces, llegué a Blogger y luego NucleusCMS, Movable Type y finalmente (al parecer, a principios del 2004), WordPress
Y eso ha sido más o menos cómo he aprendido… haciendo… 1997… eso es como un millón de años en tiempo de internet.
Ahora, para terminar y, ojalá, dejar algo un poco más útil que solo decir “se aprende haciendo” (sobre todo considerando que hoy hay muchos más medios para aprender mejor y más rápido), en primer lugar dejo tres enlaces que bien pueden servir para comenzar:
Y con ello, tiro la pelota para quien la quiera tomar: como comentario, meme o como se te ocurra; puedes partir con solo dos preguntas:
Hace muuucho tiempo, este artículo iba a ser una discusión sobre los futuros estándares para HTML: XHTML 2 y HTML 5. Luego, pasó a ser una discusión sobre lo jodido que resulta el parser XML, el que en teoría, debería ser el que debe ser usado al elegir un DOCTYPE XHTML. Ahora, intento resumir algo de ello y apuntar a un tema que hace tiempo me está llamando a escribir algo: los mal-llamados y auto-denominados standardistas. Aquí vale la pena hacer inmediatamente una pausa para aclarar a qué me refiero con esto: históricamente, el movimiento pro-estándares surge en un momento en el que la guerra de los navegadores había llegado a un punto en el que, como medida de lograr ventajas competitivas, cada empresa implementaba mejoras propietarias, incompatibles con los demás productos del mercado. No sólo MSIE propiciaba esto, Netscape también hacía lo suyo.
El movimiento por los estándares tenía, en principio, una gran tarea: asegurar una experiencia común para usuarios de distintos navegadores, y es en ese contexto donde respetar un estándar web encuentra su sentido. La separación del contenido y la presentación, la disminución de los tiempos de carga, la ventaja de escribir menos (y mejor) código han sido quizás los mejores argumentos en esta pelea, que al cabo de largos años ya podríamos dar por ganada —qué mejor evidencia que el interés de los desarrolladores de Internet Explorer en aumentar su conformidad con los estándares… aun con una implementación todavía muy, muy mejorable.
Entonces, como vimos y aceptamos guiar nuestro trabajo por un estándar es bueno, muchos desarrolladores comenzaron a interesarse en desarrollar con estándares… pero nada más. Su nueva insignia de orgullo y admiración no sería “Optimizado para…”, sino HTML válido; validar se convirtió en un fin, y creo que a estas alturas decir que el solo hecho de pasar la prueba del validador de la W3 es cuando menos insuficiente, y en muchos casos, engañoso.
Fue entonces que muchos comenzaron a creerse el cuento de ser standardista, no como aquellos que tuvieron la visión suficiente para pensar en un estándar como una forma de mejorar la experiencia de los usuarios, sino fijándose casi exclusivamente en el validador, y sintiéndose autorizados de apuntar con el dedo a aquellos que no pasaban esta prueba.
Junto con ello, y dado que la separación de contenido y presentación es una de sus máximas, muchos despreciaron a HTML 4 por incluir elementos y atributos representacionales, ¡una verdadera herejía! XHTML 1.0 Transitional tampoco es mucho mejor, puesto que es básicamente lo mismo que HTML 4, por lo que las únicas alternativas dignas parecen ser XHTML 1.0 Strict o XHTML 1.1… y aquí es donde llegamos a la paradoja.
Si ser standardista significa un respeto irrestricto a los estándares de la W3, ¿cómo es que tantos de ellos se han olvidado de servir su contenido como corresponde? Al parecer, simplemente se saltaron ese capítulo o bien, derechamente, lo ignoran. La cuestión es que todos aquellos que lucen orgullosos sus enlaces de XHTML 1.0 Strict, pero sirven su contenido como text/html caen en una estupenda contradicción, y es que servir XHTML como text/html no es solamente erróneo según los mismos estándares por los que juran lealtad, sino que incluso puede ser considerado “dañino”.
Vamos lentamente: cuando conectamos a un servidor y éste nos envía un archivo, junto con él recibimos una indicación que señala qué tipo de documento estamos descargando. Así, cuando descargamos una imagen GIF, se envía la cabecera Content-Type: image/gif, o Content-Type: image/jpeg cuando es un JPG. De acuerdo a esa información (el content type), el cliente decide qué hacer con el archivo; en estos dos ejemplos, y asumiendo que estamos utilizando un navegador gráfico, éste nos mostrará la imagen requerida —como nota aparte: utilizaré content type y media type como sinónimos.
Con las “páginas” (me refiero al X/HTML) pasa lo mismo: el cliente solicita el archivo, recibe la información del content type y la muestra. Sin embargo, entre estos dos pasos ocurre algo muy importante: se selecciona el “parser”.
A ver, a ver… ¿que qué cresta es un parser? Básicamente, es el encargado de interpretar un documento; en este caso, documentos escritos en lenguajes de marcado como XHTML y HTML. Si las cosas fueran como deberían (pretendamos que lo son), cualquier navegador debería ser capaz de parsear un documento HTML como HTML y un documento XHTML como XHTML de acuerdo a la declaración de su media type: text/html o application/xhtml+xml, respectivamente; si las cosas fueran como deberían, tendría que existir una estricta correspondencia entre el tipo de documento, el media type y el parser. Honrando a Murphy (el de la ley, no el de las películas), las cosas no son como deberían.
La correspondencia entre el tipo de documento y el media type pocas veces es efectiva, de hecho, la mayoría de las veces nos encontramos con que los documentos XHTML son servidos como text/html lo cual es permitido (como en May) pero no recomendado en XHTML 1 y derechamente desincentivado (como en Should Not) para XHTML 1.1 en adelante —lo pueden ver mejor explicado en en este documento de la W3 y la definición de “Should Not” en este memo.
¿Y cuál es el problema con servir XHTML como text/html? —se estarán preguntando. La respuesta no muy simple, pero por suerte a algunas personas ya se les ocurrió una forma un poco más digerible de presentarla; intentaré una traducción (por pésima que resulte), aunque de todos modos recomiendo la lectura del artículo completo:
Por qué utilizar
text/htmlpara XHTML está malLo que generalmente pasa a los autores que deciden enviar XHTML como
text/htmles lo siguiente:
- El autor escribe XHTML que hace suposiciones que sólo son válidas para navegadores HTML 4 o tag soup, y no para navegadores XHTML, y lo sirve como
text/html[las suposiciones se listan más abajo en este artículo]- El autor encuentra que todo funciona bien
- El tiempo pasa
- El autor decide servir el mismo contenido como
application/xhtml+xmlporque, después de todo, es XHTML- El autor encuentra que el sitio se estropea horriblemente [las razones se listan más abajo en el artículo]
- El autor culpa a XHTML
Atención ortodoxos, servir XHTML como text/html es simplemente no seguir el estándar —cito: El media type text/html es primariamente para HTML, no para XHTML. En general, este media type NO es conveniente para XHTML
(W3.org: XHTML Media Types, énfasis del original).
Quizás estén pensando “bueno, entonces la solución es simple: servir XHTML como application/xhtml+xml“… pero eso no es tan simple: entonces debería ser interpretado como XML, y esto conlleva a las complicaciones (el “horrible estropeamiento”) inherentes al parser XML. La cuestión es la siguiente:
XML tiene un manejo de errores definido muy precisamente (a diferencia de HTML): cuando el parser encuentra algo inesperado, simplemente se detiene y muestra un error. Esto significa dos cosas: hace que el editar documentos XML sea más cercano a “programar de verdad” (si cometes un pequeño error [el programa] no se compila), y como no se necesita código para el manejo de errores, los parsers se hacen a la vez más rápidos y más fáciles de escribir. Como pueden imaginar, los programadores se sintieron en casa.
Algo así:
Como decía antes, si las cosas fueran como deberían, y XHTML fuera servido como application/xhtml+xml e interpretado como XML, un gran porcentaje de las páginas actuales se verían como la imagen anterior: bastaría que la codificación no correspondiera (por ejemplo, indicar ISO-8859 en vez de UTF-8), que existieran etiquetas anidadas incorrectamente, nombres de elementos en mayúsculas o un ampersand (&) no codificado para que no se viera más que una pantalla amarilla indicando amablemente el error… ¡incluso un trackback de un blog con una codificación distinta bastaría para producir un error!
The advantages of XHTML
When sent as
application/xhtml+xml, XHTML has several advantages:
- XHTML content will be able to be mixed-and-matched with content from other well-known namespaces (in particular, MathML). This is the main advantage for content authors.
- Browsers will immediately catch well-formedness errors (though other errors still won’t be caught).
- Tools interacting with XHTML documents are guaranteed a well-formed document.
However, none of these apply when an XHTML document is sent as text/html, and since authors feel their pages should be readable on the most popular Web browser, which does not support application/xhtml+xml, there is basically no point in using XHTML at the moment.
¿Qué queda entonces? Aun respetando los estándares, una solución sería utilizar XHTML 1.0 Transitional, que puede ser servido como text/html, y en consencia interpretado como HTML… ¡pero ni siquiera el HTML servido como text/html es interpretado como HTML!
Mientras que HTML 4.01 es formalmente un formato de documento basado en SGML, los únicos clientes que realmente tratan al HTML de esta forma son los validadores. Los navegadores, por otra parte, tratan al HTML como si fuera sopa de etiquetas [tag soup]— tratan hacer sentido de, y mostrar, incluso el documento más horriblemente estropeado según su mejor habilidad.
Digital Web Magazine - HTML5, XHTML2, and the Future of the Web
En resumen:
¿Y yo? Uso XHTML como text/html… y no me quita el sueño.
De a poco las nuevas herramientas que Yahoo ha puesto a disposición de quienes desarrollamos proyectos para el web han comenzado a ganar popularidad; esta colección conocida como Yahoo! User Interface Library consta de un montón de herramientas JavaScript y —lo que más me interesa y quisiera comentar acá— una serie de herramientas CSS que podrían ayudarnos a facilitar nuestra vida.
Como quizás sabran, la idea de un framework CSS no es nueva, y de hecho podríamos encontrar uno de los primeros intentos en los hojas diseñadas para “resetear” los estilos predeterminados que los distintos navegadores aplican a cada uno de los elementos de una página. La cuestión es la siguiente: esos estilos predeterminados no son iguales en todos los navegadores, por lo que la solución sería “emparejar hacia abajo”, “limpiando” todos los estilos para luego volver a declararlos mediante tu propia hoja de estilos —es lo que hace Eric Meyer con Reset Reloaded.
Otros han llevado esta idea más lejos, y además de resetear los estilos, proponen una base para conseguir un estilo consistente, como es el caso de Tripoli; o crean un verdadero meta-lenguaje con el que conseguir rápidos y consistentes resultados, como es el propósito de Blueprint —a veces, al costo de disminuir la semántica de las clases utilizadas en el código.
YUI hace todo esto y algo más. Se compone (hasta el momento) de cuatro herramientas:
En lo personal, creo que tiene algunas ventajas que lo convierten en una alternativa bastante atractiva:
Hoy en la tarde veía una nueva comparación entre frameworks de Javascript, y recordaba cómo cada framework del que he tenido conocimiento se promociona como el más rápido… lógicamente, no todos pueden ser “el más rápido”, a menos que todos sean igualmente rápidos, en cuyo caso su velocidad no sería ninguna ventaja, ¿no es así?
De paso, también recordé un artículo de Kyle Neath, en el que reflexionaba sobre el anuncio de lanzamiento de jQuery 1.1.3, tentadoramente titulado jQuery 1.1.3: 800% más rápido, aun 20KB… hasta que surge la pregunta: ¿más rápido que qué?.
Así y todo, y en presencia de una suite de pruebas tan bonita como SlickSpeed, me fue irresistible realizar algunas mediciones en los navegadores que tengo instalados.
El equipo de pruebas, un Intel Core Duo T2250, 1 GB RAM, Windows XP SP2; los navegadores:
La versión de SlickSpeed que utilicé está ubicada en http://extjs.com/playpen/slickspeed/
Y los resultados:
Antes de finalizar, un par de cosas: sé que no son las últimas-últimas versiones de todos los frameworks, la suite de pruebas se puede bajar desde Google Code, y sí, probablemente los resultados variarán si usan otras versiones de SlickSpeed… extrañamente, en la que usan en jQuery éste sale bastante mejor parado; en la de ExtJS, gana ExtJS; en la de mootools gana mootools… el sitio de dojo query no responde, y en el de Prototype no encontré la suite de pruebas.
Probablemente una de los primeros trucos que encontré al comenzar a aprender a hacer páginas “bien” —o sea, con un editor de texto, HTML y CSS, no con Dreamweaver y tablas— es la técnica del image replacement. La idea es simple: reemplazar, por ejemplo, una cabecera por una imagen con CSS, prescindiendo de insertarla con el elemento <img src='lorem-ipsum.jpg' alt='Lorem Ipsum' /> ya que esto produciría en un código más accesible y semánticamente correcto.
HTML:
<h1 title="contrasentido">contrasentido</h1>
CSS:
h1{
display:block;
background:url(img/contrasentido.gif) top no-repeat;
width:402px;
height:55px;
text-indent:-9999em;
}
Las reglas básicas de esta técnica: “indentar” negativamente el texto del elemento en el que queremos realizar el reemplazo lo suficiente para que no aparezca en pantalla y especificar la imagen que deseamos mostrar como fondo. El atributo title en el elemento que será reemplazado sirve para poner los tooltips con los que MSIE solía mostrar, erróneamente, el texto alternativo de las imágenes… en otras palabras, completan la ilusión.
Hasta acá pareciera que todo está bien, sin embargo todas las técnicas de image replacement presentan problemas: algunos causados por comportamientos extraños navegadores poco actualizados (más específicamente, Explorer 5 y versiones antiguas de Opera), otras en escenarios que, si bien pueden resultarnos poco comunes, no vale la pena descartar (como que el usuario tenga desactivada la descarga de imágenes al mismo tiempo que activada la utilización de hojas de estilo), necesidad de agregar etiquetas vacías o poco/ningún valor semántico o de aplicar hacks específicos para algunos navegadores.
Si son de aquellos a quienes nos gusta mantener un código válido y además gusta de insertar videos de en tu blog, seguramente se habrán dado cuenta del horroroso código que algunos proveedores entregan para insertar los videos.
Por ejemplo, veamos el código que entrega YouTube:
<object width="425" height="350">
<param name="movie" value="http://www.youtube.com/v/PsRkU7FV4aw"></param>
<param name="wmode" value="transparent"></param>
<embed src="http://www.youtube.com/v/PsRkU7FV4aw"
type="application/x-shockwave-flash" wmode="transparent"
width="425" height="350">
</embed>
</object>El problema es que el elemento <embed /> no es válido, o más bien, no existe en las especificaciones del W3, sino que es un invento de Netscape (de aquellos tiempos en que su navegador aún era importante). Por otra parte, object sí es válido, pero si insertáramos el código precedente sin ninguna otra modificación que remover el elemento embed, los usuarios de Firefox no verían nada.
La solución: utilizar object pero especificando un atributo fundamental, type="application/x-shockwave-flash". El código válido quedaría de esta forma:
<object width="425" height="350"
type="application/x-shockwave-flash"
data="http://www.youtube.com/v/PsRkU7FV4aw">
<param name="movie" value="http://www.youtube.com/v/PsRkU7FV4aw" />
<param name="wmode" value="transparent" />
</object>Como (casi) siempre, existe una manera más fácil de hacer las cosas, y en este caso como en muchos otros pasa por un plugin para WordPress: con Embedded video with Link podrás insertar videos de YouTube, Google Video y un par de sitios alemanes de alojamiento de videos que no creo que sean muy populares entre ustedes, lectores de este blog 
Una vez instalado, puedes insertar videos de la siguiente forma:
[youtube id-del-video texto-para-el-enlace]
[google id-del-video texto-para-el-enlace]La “id-del-video” es una cadena de caracteres que forma parte de la dirección de cada video:
http://www.youtube.com/watch?v=PDxMQaMqsig
http://video.google.com/videoplay?docid=2331852903610109378El “texto-para-el-enlace” es… adivinen qué. Puede contener espacios.
Acá un ejemplo: [youtube PDxMQaMqsig Sigur Ros: Hoppipolla] genera lo siguiente
Betaless · MultiMEDIA Digital contrasentido
yukei.net by Felipe Lavín Z. is licensed under a Creative Commons Atribución-Compartir Obras Derivadas Igual 2.0 Chile License.
