RSS .92| RSS 2.0| ATOM 0.3
  • Inicio
  • Correo Web
  •  

    Encuentro de desarrolladores web en Barcelona (abril 2008)

    Abril 15, 2008 @ 23:27
    Dizque

    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.


    Automatización: vigila cambios en ficheros y reacciona

    Abril 13, 2008 @ 14:04
    Dizque

    Un buen día, Ale Muñoz dejó caer, como de pasada, la siguiente sentencia:

    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.


    Día 403

    Febrero 16, 2008 @ 21:55
    Dizque

    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.


    Font-family, espacios, comillas y mayúsculas/minúsculas

    Diciembre 9, 2007 @ 12:46
    Dizque

    Leyendo The Principles of Beautiful Typography, en Sitepoint, me reencuentro, en la página 2, con la siguiente inexactitud:

    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?»)


    Posición relativa y scroll en Internet Explorer

    Noviembre 13, 2007 @ 22:09
    Dizque

    Bug vivido hoy en mis propias carnes. Situación: una caja a la que hemos asignado unas dimensiones y un overflow: auto. Dentro de la caja tenemos elementos con posición relativa (¿quizá para disparar hasLayout y resolver otros bugs?). Al hacer scroll, los elementos en posición relativa no se cantean. Ni un pelo.

    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.