• http://html5.esbudellat.net/
• http://html5.scriptia.net/
• http://html5.mcdave.net/
• http://html5.ascarida.net/
• http://html5.striptm.com/
• http://html5.webposible.com/
• http://www.albertofortes.com/html5/

Tenemos fecha para el encuentro de desarrolladores web de abril. Será el jueves 17 de abril a las 19:30h. Y sitio: el Bar Billar H.D.P., en Gracia.

Como en otras ocasiones, cabe la posibilidad de que recordemos colocar un cubo de Rubik sobre la mesa para que quien quiera encontrarnos lo tenga fácil.

Trabajar menos, en mi opinión, es una obligación moral de todo el que use ordenadores

Cuando lo leí me sentí tocado. Fin del prólogo.

El otro día, mientras preparaba unas hojas de estilo XSL, me descubrí atrapado en una especie de bucle inoperante. Viene a ser el siguiente:

1. edito un fichero;
2. lo guardo;
3. me voy a la terminal;
4. lanzo un comando (un make o similar);
5. me voy al navegador;
6. compruebo el resultado del comando refrescando el navegador;
7. me voy al editor;
8. volvemos a empezar.

Un rollo, vamos. Púseme a buscar opciones para la automatización del proceso. Estaba claro que lo que tenía que hacer era observar los cambios en determinados ficheros y realizar alguna acción en tal caso. Exactamente lo que hace stakeout (lo encontrarás en Staking Out File Changes). Si te decides, como yo, a usar la versión ruby:

• Copia el script de la página enlazada
• Crea un fichero stakeout.rb, hazlo ejecutable y colócalo dentro de tu path.

El uso es sencillísimo. El programa recibe como parámetros el comando a ejecutar y los ficheros a observar. Para crear la lista de ficheros observados podemos utilizar sintaxis glob. Un caso:

choan$ stakeout.rb ./process.rb *.xsl template.html process.rb
=> template.html changed, running ./process.rb
=> done

Cuando nos hartemos de trabajar, podemos matar el proceso a golpe de ctrl + C.

Reducimos pues, el proceso, en unos cuantos pasos. Aleluya.

Ya hemos lanzado 403day.org, el sitio oficial de la campaña. Allí podréis encontrar versiones mejoradas del plugin para Wordpress, de la receta .htaccess y el nuevo módulo para Drupal.

En el último encuentro de desarrolladores web de Barcelona, hablamos de prohibir el acceso a nuestros sitios a Internet Explorer el día 4 de marzo (humanos: el mensaje de acceso denegado que devuelve el servidor utiliza el código 403).

Y oye, que algunos lo vamos a hacer. Arnau ofrece una receta .htaccess de la idea; por mi parte os presento la idea en forma de plugin para Wordpress. Descargar, instalar, activar y olvidarse: únicamente entrará en acción el día 4 de marzo. De cada año.

Para acompañar el plato, estamos preparando hemos preparado 403day.org, donde explicaremos explicamos por qué el dominio de mercado de un navegador de mala calidad es peor que emborracharse con tequila barato.

Remember that any font family names that include spaces must be quoted, either using single (’) or double (”) quotes.

Confusión para las masas. Veamos que dice la recomendación (candidata) de CSS 2.1:

If an unquoted font family name contains parentheses, brackets, and/or braces, they must still be escaped per CSS grammar rules. Similarly, quotation marks (both single and double), semicolons, exclamation marks, commas, and leading slashes within unquoted font family names must be escaped. Font names containing any such characters or whitespace should be quoted:

Compárese must con should. No match! Debe no es lo mismo que debería.

A continuación, se describe el algoritmo para obtener el nombre de la familia tipográfica en los casos en que no aparece entrecomillado:

If quoting is omitted, any whitespace characters before and after the font name are ignored and any sequence of whitespace characters inside the font name is converted to a single space. Font family names that happen to be the same as a keyword value (e.g. ‘initial’, ‘inherit’, ‘default’, ’serif’, ’sans-serif’, ‘monospace’, ‘fantasy’, and ‘cursive’) must be quoted to prevent confusion with the keywords with the same names. UAs must not consider these keywords as matching the ‘<family-name>’ type.

Es decir, para la gran mayoría de los casos, es completamente innecesario entrecomillar el nombre de la fuente: con font-family: Trebuchet MS, sans-serif obtenemos el mismo resultado que font-family: "Trebuchet MS", sans-serif.

Concluyendo: no es necesario (salvo en casos raros y extremos descritos en la especificación) entrecomillar los nombres de tipografías que contienen espacios. Y decir lo contrario, amigos, es confundir. Colleja para Jason Beaird.

Sensibilidad a mayúsculas y minúsculas (me pregunto por la)

Mientras pensaba en escribir esta notita, y reflexionando sobre mi manera de escribir hojas de estilo, he caído en la cuenta de que además de no utilizar comillas, siempre escribo los nombres de tipografías en minúsculas. Tal que:

body {
  font-family: trebuchet ms, sans-serif;
}

Y me he preguntado si tal irresponsable actitud –consúltese Font Name Case Testing para comprobar si es fuente de problemas– concuerda o no con la recomendación. En la sección de tipografía, no hay nada al respecto. Es en Characters and case donde se dice que

All CSS style sheets are case-insensitive, except for parts that are not under the control of CSS. For example, the case-sensitivity of values of the HTML attributes “id” and “class”, of font names, and of URIs lies outside the scope of this specification. Note in particular that element names are case-insensitive in HTML, but case-sensitive in XML.

Entonces, ¿qué? (Léase este «¿qué?» como «y vosotros, ¿cómo lo hacéis? ¿Os habéis encontrado algún problema?»)

En fin, algo tan sencillo como esto:

#container {
    overflow: auto;
    width: 600px;
    height: 200px;
}

.relative {
    position: relative;
}

No funciona correctamente en Internet Explorer. Y no solo en la versión 6. El bug se reproduce también en la versión 7 de la cosa.

La «solución» consiste en colocar el elemento contenedor en posición relativa:

#container {
    overflow: auto;
    width: 600px;
    height: 200px;
    position: relative;
}

.relative {
    position: relative;
}

Evidentemente –y no sé si decir por fortuna o por desgracia–, no soy el único que se ha topado con este problema. Jonathan Snook lo describe y soluciona en position:relative and overflow in Internet Explorer. Stu Nicholls reutiliza el bug (osado él) como feature en Emulating position fixed for Internet Explorer.

En fin, uno más para el libro.

Se acabaron las excusas. Pasó el verano, empezó el curso y ya es hora de celebrar otro encuentro de desarrolladores web.

Será el jueves 25 de octubre a las 19:30h, en el Cafè del Teatre, en Gracia.

Nos vemos.

Afortunadamente, los chicos de Microsoft incluyeron, a partir de la versión 5 de Internet Explorer, un método sencillo —e incluso aceptable— para detectar la versión del navegador y suministrarle contenidos apropiados a su edad mental.

La sintaxis utiliza comentarios que solo son reconocidos por IE:

<!-- Esto es un comentario HTML tradicional -->

<!--[if IE]> 
    Solo Internet Explorer ve este contenido. 
    Para el resto de los navegadores, es un 
    comentario.
<![endif]-->

Así pues, podemos utilizar este tipo de comentarios para alimentar a la bestia negra con una hoja de estilos ad hoc.

<!--[if IE]> 
    <link rel="stylesheet" type="text/css"
    href="/hoja/de/estilos/para/IE.css" />
<![endif]-->

No solo eso, también podemos destinar código únicamente a versiones concretas. Ya se ha escrito mil veces sobre el tema, así que no me extenderé. Los interesados podéis acudir a Comentarios condicionales para IE, en Diseñorama, o Sintaxi dels comentaris condicionals en a.css.

Solo para «los otros»

Y ahora, vayamos con el tema que me ha motivado a escribir esta notita: ¿qué hacer cuando queremos ocultar algo a Internet Explorer sin hacerlo invisible al resto de navegadores? Según Microsoft, usaremos lo que ellos llaman Downlevel-revealed Conditional Comments:

<![if !IE]>
    <p>Gracias por no utilizar una patata 
    para navegar por mi web.</p>
<![endif]>

Pero por desgracia, la sintaxis propuesto no es válida. Ni como HTML, ni como árbitro de tercera. En cambio, utilizando esta otra

<!--[if !IE]>-->
    <p>Gracias por no utilizar una patata 
    para navegar por mi web.</p>
<!--<![endif]-->

nuestro documento sigue siendo válido. Bravi!

Amigos míos: dejen por un día de trabajar hasta las mil y acudan sin falta al próximo encuentro de desarrolladores web de junio.

Como de costumbre, nos dividiremos en dos bandos:

1. El de los que discuten sobre marcado semántico mientras toman cerveza tras cerveza.
2. El de los que toman cerveza tras cerveza mientras discuten sobre marcado semántico.

Si es la primera vez que acudes, nos podrás reconocer fácilmente: sobre la mesa habrá un cubo de Rubik (o por las barbas).

La cita es el jueves 28 de junio a las 19:30h, en el Cafè del Teatre, en Gracia.

Como bien podéis comprobar los que visitáis el sitio y guardáis memoria de su aspecto anterior, ya hemos lanzado el rediseño. Confíamos en que nuestra nueva imagen aporte mejoras en la utilización de Dizque.

Muchas gracias a todos por vuestros comentarios.

Echadme una mano, primos: estoy preparando un rediseño de Dizque y me gustaría conocer la opinión de los lectores sobre lo que les gusta y no les gusta del diseño actual (abandonad por un momento vuestro lector de feeds y pasaros por el sitio, porfaplis). Concretamente tengo dudas respecto a:

¿Qué es esto?

En todas las páginas del sitio se muestra un creativo texto explicando –aunque muy a medias– qué es Dizque. Hay quien me dice que le sobra, hay quien me dice que es necesario. En general, creo a los lectores habituales les sobra mientras que a los lectores casuales les supone una ayuda (o eso supongo). En el boceto del nuevo diseño, he desplazado este bloque a la zona inferior derecha. ¿Opiniones?

Publicidad

Actualmente muestro algunos bloques que molestan más de lo que, queridos míos, os merecéis. Si bien no voy a renunciar a los pingües beneficios que obtengo de Adsense, soy plenamente consciente de que los habituales no hacéis ni un puto clic. Y los geeks no habituales tampoco. Así que… estoy considerando mostrar la publicidad únicamente a nuevas visitas y a aquellas que provengan de buscadores (al estilo buhonejo). ¿Opiniones?

Archivo

¿Aporta algo una lista de meses que abarca desde junio de 2007 a febrero de 2005? Creo que no. ¿Qué os parece si me la cepillo?

Feeds de Mundo Du y Scriptia

Me temo que no le aportan nada a nadie. ¿Algún inconveniente en que los elimine?

Enlaces casi diarios

Dado que es la sección que se actualiza con mayor frecuencia, estoy pensando en darle más importancia. ¿La seguís? (Tened en cuenta que estos contenidos no aparecen en el feed general).

Enlaces (blogs y amiguetes, Choan estuvo aquí, etc.)

A no ser que salga algún defensor de este bloque, dadlo por muerto. (Quizá podría trasladarlo a una página propia.)

En fin, estas son algunas de mis dudas. Hay otras cosas de las que no dudo:

1. En la próxima versión, la home no mostrará diez anotaciones completas: sólo una. Eso sí, tendré (tendremos) una lista de los últimos posts publicados y (novedad) una lista de los artículos que mi mismidad considere más interesantes
2. Abandono el esquema de color de variantes del café. Me voy a blanco, negro, gris, colorau y azul.
3. Mantengo el logo del gato.

Bueno, pues lo dicho: cualquier opinión (siempre que no resulte ofensiva para su santidad) será bienvenida.