Avisar de contenido inadecuado

Consejos en Pixelovers

Expand

Javascript y jQuery: Consejos y Buenas Practicas (Parte II)

Hace unas semanas iniciamos una serie de 2 posts para hablar de lo que consideramos que son unas buenas practicas para desarrollar codigo Javascript con la libreria jQuery.

http://stc.obolog.net/multimedia/fotos/309000/308801/308801-209198.jpg

Con este post cerramos la serie y profundizamos un poco más en el tema

En el primer post de esta serie comentamos algunas generalidades que nos pueden servir de base a la hora de desarrollar un código JS eficiente. En este segundo post hablaremos de como solucionar de forma eficiente problemas concretos que nos solemos encontrar en nuestros desarrollos.

Asi que, ahi vamos...

Expand

Javascript y jQuery: Consejos y Buenas Practicas (Parte I)

jQuery es una de las librerias mas utilizadas por los desarrolladores FrontEnd por su versatilidad y facilidad de uso. En Pixelovers somos autenticos fans de esta libreria.

http://stc.obolog.net/multimedia/fotos/309000/308801/308801-209198.jpg

Es por esto que queremos compartir con vosotros lo que consideramos que son unas buenas practicas a la hora de programar codigo Javascript ayudandonos de la libreria jQuery.

El objetivo de este compendio de buenas practicas es conseguir un codigo Javascript lo mas limpio, claro y eficiente posible.

Los tips que aqui incluimos estan sacados de nuestra propia experiencia y de conclusiones interesantes que hemos ido encontrando por la red y que hemos acoplado a nuestro repertorio.

Como son muchos los puntos tratados y para no cargar el post con demasiada informacion vamos a dividir este compendio en 2 partes.

En esta primera parte hablaremos de normas generales a seguir que te ayudaran a crear un codigo mas claro y eficiente. En un segundo post hablaremos de como solucionar de forma eficiente problemas concretos que nos solemos encontrar en nuestros desarrollos.

Y una vez dicho esto, vamos al lio...

Consideraciones Generales

  • Aprenderse bien la librería. Para utilizar siempre la solución mas optimizada posible. No está de mas tener a mano una chuleta de jQuery como comentabamos en otro post hace unas semanas o ir directamente a la documentacion oficial de jQuery
  • Utilizar librerias consolidadas, versatiles, con soporte y con proyecto de futuro. Por ejemplo jQuery como librería principal y jQuery Tools y jQuery UI como liberias adicionales de efectos
  • Trabajar en archivos separados. Mejor crear JS's diferentes para cada funcionalidad separable de nuestro site y luego utilizar algun sistema que junte todos estos JS's en uno final (comprimido y ofuscado)
  • Javascript no intrusivo. Nunca depender de JS en la medida de lo posible. Si está desactivado el javascript o falla, que la pagina muestre un aspecto normal. Javascript es una mejora, no un sistema de seguridad.
  • Optimiza el codigo haciendo pruebas de rendimiento. Con Firebug podemos medir el tiempo que tarda una funcion (o trozo de codigo) en ejecutarse:
    			
    	console.time('native');  
    	var l = array.length;
    		for (var i=0;i<l; i++) {
            array[i] = i;  
    	}  
    	console.timeEnd('native');  
    			 
    		
  • Comprimir el codigo al final. Al comprimir el codigo el archivo JS que tendrá que bajarse el usuario será de menor tamaño, aunque hay que valorar el rendimiento final ya que por el contrario el navegador tendrá que realizar el proceso adicional de descomprimir el codigo antes de ejecutarlo.Para comprimir el codigo disponemos de herramientas, tipo YUI Compressor aunque hay muchas mas
  • El marcado semantico y accesible viene primero. No adaptar el marcado para facilitar el JS sino que sea el JS el que se adapte al marcado. Con ID’s, herencia, y clases podemos acceder a cualquier elemento y asignarle funcionalidades

    Marcado horrible:

    			
    	<table>
    	    <tr>
    	    	<td onclick="doSomething();">First Option</td>
    	        <td>First option description</td>
    		</tr>
    		<tr>
    			<td onclick="doSomething();">Second Option</td>
    			<td>Second option description</td>
    		</tr>		
    	</table>
    			

    Marcado malo:

    	
            <dl>
    		<dt onclick="doSomething();">First Option</dt>
    		<dd>First option description</dd>
    		<dt onclick="doSomething();">Second Option</dt>
    		<dd>Second option description</dd>
    	</dl>
    		

    Buen marcado:

    			
    	<dl id="OptionList">
    	    <dt>First Option</dt>
    	    <dd>First option description</dd>
    	    <dt>Second Option</dt>
    	    <dd>Second option description</dd>
    	</dl>
    			
    
  • Encapsular lo maximo posible el codigo. Esto significa agrupar todas las funciones comunes dentro de una funcion padre, asi acotamos el contexto de cada funcionalidad (objeto si hace falta)

    Ejemplo:

    			
    	var mySite = new Object();
    	
    	mySite = {
    		
    		var1 : 1,
    		var2 : 2,
    		valorCalculado,
    		
    		init : function() {
    			// aqui hago varias cosas
    			this.valorCalculado = "hola";
    			this.funcionalidad1();
    		},
    		
    		funcionalidad1 : function() {
    			// aqui desarrollo una funcionalidad concreta
    		
    		}
    	}
    	
    	// desde fuera (o desde otro objeto) puedo llamar a las funciones de este objecto
    	mySite.funcionalidad1();
    					
    
  • Elimina consultas innecesarias. Podemos ahorrarnos la llamada al $(document).ready() lanzando el <script> justo antes de cerrar el tag </body> lo que nos asegura que todos los elementos que podemos necesitar están ya cargados en el árbol DOM.

    Menos eficiente:

    			
    	$(document).ready(function(){
    		mylib.article.init();
    	});
    			
    

    Mas eficiente:

    			
    		<script type="text/javascript>
            	  mylib.article.init();
    		</script>
    	</body>
    			
    
  • “Eval is evil” Evitar el uso de eval. Problemas de seguridad. Mas info de por qué puede ser un problema aqui. Una posible alternativa al uso de EVAL puede ser JSON.parse o JSONP

Y hasta aqui la primera parte del asunto...

¿Que te han parecido los puntos aqui comentados? ¿Estas de acuerdo? ¿Algun punto que creas que falta en esta lista?

Enlaces y más

Expand

Reset CSS para HTML5

Ya os hablamos en CSS: Consejos y buenas prácticas sobre la importancia de resetear las propiedades CSS para eliminar diferencias entre navegadores desde el principio. Pues ahora os traemos de la mano de html5doctor.com un nuevo reset CSS adaptado a HTML5. Incluye las nuevas etiquetas y elimina las que ya no están permitidas en este lenguaje de marcado.


/*
html5doctor.com Reset Stylesheet
v1.4
2009-07-27
Author: Richard Clark - http://richclarkdesign.com
*/

html, body, div, span, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
abbr, address, cite, code,
del, dfn, em, img, ins, kbd, q, samp,
small, strong, sub, sup, var,
b, i,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, dialog, figure, footer, header,
hgroup, menu, nav, section,
time, mark, audio, video {
margin:0;
padding:0;
border:0;
outline:0;
font-size:100%;
vertical-align:baseline;
background:transparent;
}
body {
line-height:1;
}

article, aside, dialog, figure, footer, header,
hgroup, nav, section {
display:block;
}

nav ul {
list-style:none;
}

blockquote, q {
quotes:none;
}

blockquote:before, blockquote:after,
q:before, q:after {
content:'';
content:none;
}

a {
margin:0;
padding:0;
border:0;
font-size:100%;
vertical-align:baseline;
background:transparent;
}

ins {
background-color:#ff9;
color:#000;
text-decoration:none;
}

mark {
background-color:#ff9;
color:#000;
font-style:italic;
font-weight:bold;
}

del {
text-decoration: line-through;
}

abbr[title], dfn[title] {
border-bottom:1px dotted #000;
cursor:help;
}

table {
border-collapse:collapse;
border-spacing:0;
}

hr {
display:block;
height:1px;
border:0;
border-top:1px solid #cccccc;
margin:1em 0;
padding:0;
}

input, select {
vertical-align:middle;
}

Puedes descargar el código del proyecto html5resetcss en google code.

Expand

10 errores comunes al diseñar los formularios de registro

Sergio Ortega nos hace reflexionar sobre 10 errores que se cometen comúnmente en un punto crítico de cualquier web que funcione sobre un sistema de usuarios: el formulario de registro. Aprovechando esta lista, vamos a realizar un examen de conciencia para ver si estamos haciendo las cosas mínimamente bien en OboLog.

  1. Tener que realizar el registro nada más empezar para poder acceder a la información más simple.
    Bueno, primer punto superado. En OboLog no es necesario registrarse más que para poder tener un blog propio, para personalizar la portada con tus contactos, o para dejar de ver publicidad en los blogs (¡el tuyo y el de los demás!). 

  2. Solicitar el registro demasiado pronto.
    Lo dicho: el usuario puede navegar por la web de forma anónima sin que se le solicite el registro.

  3. Registro OboLogNo exponer o plantear los beneficios del registro.
    En la barra lateral del formulario de registro se enumeran las ventajas de ser usuario registrado.

  4. Ocultar el botón de registro.
    Uhm... quizás deberíamos cambiar los links de registro por botones de registro...

  5. No facilitar un enlace o botón a “Nueva cuenta” o “¿Olvidaste tu contraseña?”.
    Lo tenemos, no problem.

  6. No proporcionar la oportunidad de registrarse en los momentos clave.
    Incluímos enlaces a registro en el formulario de contacto y en el momento en qué un usuario trata de añadir un contacto. Quizás tendríamos que revisar más a fondo el mapa de acciones posibles de los usuarios anónimos.

  7. Solicitar demasiada información cuando nos registramos.
    Usuario, mail y nombre del blog. Más simple imposible.

  8. No indicar a los usuarios cómo vas a usar su información.
    En las condiciones de uso del servicio viene todo explicado con detalle.

  9. Utilizar lenguaje inapropiado o conceptos poco significativos para definir cada campo del registro.
    La simplicidad del formulario impide que entremos en tecnicismos.

  10. No aclarar el sentido de ciertas opciones y las consecuencias de algunas respuestas.
    No aplica.

Bueno, parece que pasamos el "examen" con algún punto a mejorar. Habrá que ponerse las pilas. Wink Y tú, ¿te animas a pasarle el examen a tu web?
Expand

Los mejores frameworks CSS (y porqué no los uso)

La intención de un framework es principalmente ahorrar tiempo y minimizar el riesgo de errores en el desarrollo de aplicaciones. Los frameworks nos evitan, sobretodo en los momentos iniciales del desarrollo de una aplicación, repetir código para construir la base y nos permiten conseguir ciertas funcionalidades o módulos genéricos de forma más rápida y sencilla. Así como hay frameworks para PHP (CakePHP, CodeIgniter, The Zend Framework...) o para Javascript (como no... JQuery), también existen varios frameworks para CSS. Veamos en qué consisten.

¿Qué es un framework CSS?

Igual que sus parientes orientados a lenguajes de servidor o cliente, el objetivo de un framework CSS será ahorrarnos realizar las tareas básicas al trabajar con hojas de estilo. Normalmente los frameworks CSS se componen de uno o varios archivos con declaraciones predefinidas que incluyen:

  • CSS Reset: Ya hablamos de las ventajas de resetear los estilos al empezar a trabajar la maquetación de una página, en nuestra lista de consejos y buenas prácticas para CSS.  Resetear los estilos nos permitirá homogeneinzar, a priori, las posibles diferencias de visualización entre navegadores, unificando las propiedades básicas de los elementos: márgenes, paddings, tamaños, formatos, etc.
  • 51249-44848.jpgLayout:  Una parte de los frameworks va dirigida a una de las tareas más árduas a la hora de maquetar cualquier diseño: conseguir un determinado layout, más o menos complejo, que sea, además de óptimo, "cross-browser", e.d. compatible con todos los navegadores. Suelen disponer de múltiples opciones combinables para conseguir layouts complejos: múltiples columnas, anchos fijos, elásticos, líquidos...
  • Tipografías: Una gestión genérica de las tipografías que se usarán en la página. De nuevo, no sólo se trata de aplicar un uso inteligente de fuentes y tamaños, si no de unos altos de línea, márgenes, paddings... consistentes, que ayuden a  mantener un correcto ritmo vertical en la página.

Ventajas de usar un framework CSS

  • Permite agilizar el desarrollo, sobretodo en sus momentos iniciales.
  • Te ahorra las habituales batallitas entre navegadores para conseguir que tus layouts sean "cross-browser".
  • Partes de una base normalizada / homogeneizada sobre la que desarrollar un trabajo adicional.
  • Si el framework CSS está bien documentado, agiliza el trabajo en un equipo relativamente grande.

Entonces... !¿Porqué no los uso?!

Eso me gustaría saber... No, es broma. De verdad que, aunque en el caso de frameworks de desarrollo para lenguajes como PHP o Javascript me parece una ventaja a la que sacar partido, creo que en el caso de las hojas de estilo, las ventajas no son suficientemente potentes como para superar el peso de las desventajas, que para mi son:

  • Curva de aprendizaje. Algunos frameworks son realmente complejos, y es necesaria bastante dedicación  y pruebas para llegar a controlarlos bien, conocer y usar todo su potencial.
  • Puede afectar negativamente a la semántica de tu marcado HTML. La mayoría de los frameworks contienen definiciones demasiado genéricas que además han sido pensadas y nombradas pensando únicamente en la apariencia que tendrán. Y si recordamos, uno de los consejos en el artículo que citábamos antes era "Sé descriptivo en los nombres y huye de usar aquellos que se refieran a la apariencia de los elementos." Meeec. Va a ser que un contenedor llamado "big-square-at-the-left" no va a resultar muy práctico si dentro de unos meses debemos cambiar el layout de nuestra página. ¿No habíamos quedado que la ventaja principal de las hojas de estilo era separar contenido y presentación?
  • Gran parte del código nunca será utilizado. Los frameworks intentan prever todas las situaciones y contienen muchas definiciones genéricas que posiblemente nunca lleguemos a utilizar. Esta desventaja sería en realidad aplicable también a otro tipo de frameworks. Con la diferencia que un framework PHP por ejemplo, el cliente no debe descargar TODO el framework para que la aplicación funcione: se ejecuta en el servidor. El CSS en cambio sí debe descargarse al navegador, con lo que debemos cuidar su extensión si no queremos afectar negativamente al rendimiento.
  • Por último, y posiblemente la más importante al menos para mi, es que usar un framework CSS te corta las alas a la hora de aprender, de entender cómo funcionan realmente las hojas de estilo. Muchas de las cosas que sé ahora las aprendí mientras me rompía los cuernos tratando de solucionar absurdos bugs de render de Explorer, o de conseguir flotar aquella caja rebelde, o buscando el motivo por el cual la cascada se iba a tomar viento al definir tal o cuál color. En mi opinión, condiciona excesivamente el trabajo del desarrollador.

Lista de frameworks CSS

De todas formas, te animo a que conozcas y pruebes algunos de estos frameworks ( quizás entonces entiendas mis motivos... o pienses que estoy loco )

Conclusión 

Aunque no recomiende su uso, sí que hay algunas ideas que subyacen al trabajo con frameworks con las que comulgo, y te invito efusivamente a seguir, como son:

  • El reseteo de los estilos al principio de tus CSS.
  • La creación de una librería de "helpers" o snippets de código y declaraciones CSS que te sirvan como referencia para resolver situaciones comunes.
  • Definir y mantener una estructura y una sintaxis del documento CSS que sea consistente, y aplicarla siempre en todos tus proyectos.

Otros artículos interesantes que inspiraron este post

Expand

CSS: Consejos y buenas prácticas

11635-12987.jpgJusto esta semana pasada empezamos en la oficina una fase de revisión de marcado y de css de una web bastante grande, y en la que participaremos varios desarrolladores. Ésto nos ha obligado a acordar algunas convenciones a la hora de trabajar, en cuanto a codificación, estructura, nomenclatura... y a plasmarlas por escrito para que todo el equipo, ahora y en el futuro, pueda consultarlas en un documento de referencia.

En esa guía, además, hemos tratado de incluir algunas recomendaciones de "buenas prácticas" entre las que voy a tratar de resumir algunas de ellas, las más importantes a mi entender.

Consideraciones previas

  • Asegúrate de definir siempre un DOCTYPE, ¡y úsalo!
    De otra forma, el navegador entrará en el Quirk Mode, aumentando el tiempo de renderizado y provocando algunos desajustes en cuanto a la interpretación de ciertas propiedades CSS.
  • Evita usar estilos incrustados o elementos presentacionales en tu marcado.
    Reserva etiquetas <strong> y <em> para aquellos textos que realmente requieran ser enfatizados, y nada de estilos incrustados con styles dentro de tu código HTML. Los estilos SIEMPRE separados del contenido.
  • Valida tu código a medida que codifiques.
    Te evitarás muchos dolores de cabeza al final del proceso. Gran parte de problemas de renderizado son consecuencia de marcado no válido.De igual forma, asegúrate de que esa propiedad tan molona de CSS que estás usando sea estándar y no exclusiva para IE.
  • Resetea las propiedades CSS para eliminar diferencias entre navegadores desde el principio.
    Es muy buena idea empezar tu hoja de estilos general con una serie de declaraciones que reseteen propiedades como los margin, los padding y los border de los elementos más comunes. Echa un vistazo al reset.css que ofrece la librería de Yahoo o al artículo de Daniel que lo comenta más a fondo.
  • Usa el navegador más moderno y con mejor soporte de los estándares durante el desarrollo y el testeo, antes de probarlo en los navegadores "problemáticos", y no al revés.
    Puede que no sigas esta norma y no tengas ningún problema, pero si testeas primero en IE6 tienes muchas probabilidades de terminar con un CSS lleno de hacks, o peor, de terminar metiendo "hacks" para los navegadores que sí cumplen los estándares. Tu objetivo tiene que ser conseguir el código y el CSS más limpio y cross-browser posible y, créeme, la mejor manera de conseguirlo es ésta.
  • Usa el menor número de archivos posible. Es mejor un sólo archivo de 30Kb que 3 archivos de 10Kb.
    Piensa que para cada uno de los archivos estáticos enlazados desde un documento HTML ( CSS, Javascript, imágenes, etc... ), éste debe realizar una conexión HTTP y lanzar una petición, con sus correspondientes cabeceras, cookies si las hubiere... todo suma y al final, tanto en tamaño como en tiempo de descarga, penalizarás al usuario.

Estructura, nomenclatura y otras yerbas

  • Sea cual sea, trata de ser consistente en el idioma usado cuando codifiques, tanto en los nombres como en los comentarios.
    Esto toma especial importancia en grandes equipos o con personas de diferentes procedencias.
  • Usa siempre minúsculas y guiones o guiones bajos para separar palabras.
    Algunos navegadores antiguos han demostrado tener problemas con mayúsculas-minúsculas, así que ve a los seguro.
  • Sé descriptivo en los nombres y huye de usar aquellos que se refieran a la apariencia de los elementos.
    Mejor usar un #main-product que un #m-prod, y nada de clases del tipo .centered, .red... O te encontrarás con que cuando toque cambiar el color o la alineación de contenidos, tendrás que ir modificando las clases de cada elemento... ¡¿Dónde están entonces las ventajas de gestionar el diseño desde una hoja de estilos?!
  • Trata de sacar partido de la cascada
    Evita crear demasiadas instancias siempre que no sean imprescindibles. Por ejemplo
    #main_table { width:100% }
    #main_table th { font-weight:bold; text-align:center }
    #main_table td { text-align:right; font-size:1.5em }

    es mejor que
    #main_table { width:100% }
    .cell_header { font-weight:bold; text-align:center }
    .cell_contents { text-align:right; font-size:1.5em }

    Además, los nombres pueden ayudar a ubicar un elemento dentro de la jerarquía de capas. Por ejemplo, posiblemente sea mucho más práctico usar #header_logo que no #logo a secas.
  • Usa criterios consistentes para organizar las declaraciones de estilos dentro de tu CSS.
    Puedes decidir enunciar las declaraciones según su orden de aparición dentro del código, o agruparlas por el tipo de elemento al que se refieren ( listados, titulares, imágenes... ) Sea cual sea, que éste sea constante, o te vas a volver loco cuando la hoja de estilos adquiera un tamaño importante...
  • Trata de comprimir lo más posible el archivo resultante.
    Ésto lo puedes conseguir no sólo eliminando espacios y saltos de linea sobrantes en tu hoja de estilos mediante alguno de los compresores gratuítos disponibles en internet, si no configurando tu Apache para que sirva comprimidos los archivos determinados tipos de archivos ( HTML, Javascript, CSS ). Piensa que algunos archivos estáticos se enlazan desde todas ( o casi ) las páginas de tu site. Puedes ahorrarte mucho tráfico con esto.
  • Evita usar comillas alrededor de las llamadas a imágenes.
    Todos los navegadores lo entenderán correctamente. Con comillas, en cambio, tendrás problemas en IE para Mac. Pudiendo tenerlos a todos contentos... ¿porqué no hacerlo?

Consideraciones adicionales

  • En el 90% de los casos, la solución más sencilla será la que menos problemas dé entre navegadores.  KISS.
    11635-12988.jpg Normalmente podrás usar varias combinaciones para conseguir el mismo efecto visual. Trata de encontrar la combinación más simple de elementos y propiedades. Mezcla paddings en el contenedor e hijos, margins e indentaciones negativos, y suma algunos posicionamientos absolutos en elementos anidados y tendrás los ingredientes perfectos para un bonito... caos.
  • Los hacks son la última solución.
    Invierte hoy 30 minutos más en encontrar la alternativa cross-browser y ahórrate horas la semana que viene tratando de modificar tu hoja de estilos.
  • Una mala y una buena noticia: ¿La mala? No te asustes, pero sí, algunos navegadores tienen bugs de render, sin explicación ni justificación alguna. ¿La buena? En sitios como PositionIsEverything han identificado muchas de ellas y pueden ahorrarte algunos quebraderos de cabeza. Un simple e inocuo position:relative; o un zoom:1; solucionan muchos de estos bugs.
  • En la línea de lo que comentábamos al principio respecto a la cantidad de archivos CSS a enlazar desde tu página, hay algunas técnicas que pueden ayudarte a reducir la cantidad de archivos de imagen que uses para construir tu página: CSS Sliding Doors & CSS Sprites. Hacer más con menos, keep in mind.
  • La guinda del pastel: no te olvides de preparar una hoja de estilos para impresión. Hace unos días dábamos algunos consejos desde Pixelovers al respecto en Hojas de estilo para impresión.
  • Puedes usar parámetros en la llamada a tu CSS para mantener el control sobre la caché del navegador, y decidir cuándo debe expirar tu hoja de estilos o forzar a tus usuarios a descargarla de nuevo en su siguiente visita.

Conclusiones

Para empezar, concluyo que finalmente el artículo ha salido algo más largo de lo que había previsto, pero había algunos puntos que no quería que quedaran en el tintero, así que espero disculpes mis excesos. Smile

Sin duda, elaborar una guia de estilo a modo de referencia es una práctica recomendable, cuando tengas que enfrentarte un proyecto de dimensiones considerables, y con más motivo si van a ser varios diseñadores / desarrolladores los que "metan mano" al código. Aún y codificando correctamente, cumpliendo estándares y produciendo código válido, semántico, etc... cada uno tiene sus costumbres y su manera de hacer, y mezclar formas de trabajar sin cierto orden en un mismo proyecto puede resultar algo problemático para mantener la web en un futuro. Definir una referencia de estilo, estructura y/o nomenclatura puede reducir, y mucho, esos problemas en equipos grandes.

¿Y tú, cómo trabajas? ¿Coinciden estas recomendaciones con las que incluirías tú en tu HOW-TO? 

Enlaces y más

Expand

Cómo evitar problemas con la cache del navegador

En esta ocasión veremos como evitar un problema con el que seguro os habréis topado en más de una ocasión: El navegador no detecta un cambio que hemos realizado en un archivos estático ( CSS / Javascript / imagen ) y usa la copia cacheada en disco, impidiendo que la web muestre los estilos correctos, actualizados, o lanzando un error Javascript por el uso de una función no existente, hasta que forzamos una actualización con Ctrl-F5.

El caché de los navegadores actúa en el 90% de las ocasiones como nuestro aliado. Permite que determinados archivos estáticos se carguen una única vez por usuario, y se lean desde el disco en sucesivas visitas, reduciendo drásticamente los tiempos de carga.

De todas formas, el caché también puede jugar en nuestra contra en determinadas ocasiones: Si hemos realizado modificaciones a un archivo estático en un intervalo corto de tiempo, y además estas modificaciones han hecho variar muy poco el tamaño de nuestro archivo, es muy probable que el navegador no detecte que existe una nueva versión, y en vez de descargar el fichero más actual, haga uso de la copia que guarda en el disco para montar la página.

Como apuntábamos al principio, las consecuencias de esto suelen ser desastrosas: webs descuadradas o errores javascript por culpa de funciones que "deberían estar", pero que el navegador no ha cargado. Y, claro , el Ctrl-F5 sirve para mostrar la página al compañero de mesa o para tranquilizar al jefe que ha pegado un bote en la silla al ver el resultado, pero el usuario no tiene ni idea... va a verlo todo descuadrado hasta que expire la caché o le dé por forzar la recarga ( cosa poco probable ).

La solución a este problema es sencillamente añadir un parámetro a la llamada que hagamos al archivo estático. Los hay que optan por usar una fecha, y otros simplemente un valor numérico. Yo soy de estos últimos: como suelo usar Subversion para el control de versiones, lo que hago es actualizar el valor con el nº de versión correspondiente. De esta forma puedo saber, además, cuándo se hizo la última modificacion "sensible" a la hoja de estilos, echando un vistazo al showlog.

<link rel="stylesheet" type="text/css" href="/css/estilos.css?id=393" />

Cada vez que cambiamos el parámetro que hemos añadido a la llamada al CSS ( o Javascript, o imagen... ), lo que estamos haciendo es forzar al navegador a descargar de nuevo el archivo, retomando de esta forma el control sobre cuándo cachear y cuándo no.