Seguro que más de una vez os habéis visto obligados a “adelgazar” un sitio web, reducir las imágenes, eliminar comentarios del código, reducir las peticiones HTTP… Por supuesto, hace tiempo que hemos dejado de hacerlo a ciegas gracias a algunas aplicaciones web que nos han ayudado a descubrir las causas de la lentitud de nuestro sitio con precisión: Pingdom Tools, iWebtool Website Speed Test, Website Analizer…
Lo malo de todos estos sitios es eso, que son sitios web y necesitamos estar conectados para poder hacer nuestros test.
A través de Otro blog más me entero de que Yahoo! ha desarrollado una extensión para Firefox, en concreto para Firebug (una de las extensiones más útiles para desarrolladores web) que nos permitirá realizar estos test cómodamente desde nuestro navegador.
YSlow estudiará minuciosamente nuestros sitios y nos ofrecerá estadísticas y consejos. Por mi parte acabo de llenar la lista de tareas para una temporada (operación bikini en Webmaster Libre…).

YSlow for Firebug: http://developer.yahoo.com/yslow/

A estas alturas todos conocemos a Alexa y su barra pero, hasta ahora sólo podían instalarsela los usuarios de Internet Explorer.
Alexa ha lanzado Sparky, su barra como extensión para Firefox, así que ahora los usuarios del más extendido de los navegadores libres podremos acceder a toda la información recopilada por Alexa: enlaces relacionados, vista de la tendencia de tráfico web, monitor de alcance (reach) y posición en el ranking. A su vez, por supuesto, estaremos colaborando en la recopilación de datos.
Descarga: Sparky, the Alexa Toolbar for Firefox
Como curiosidad, que espero se resuelva pronto, Sparky sólo funciona con las versiones 2.0 a 2.0.0.4 de Firefox así que me he quedado sin probarla ya que hace un rato se me actualizó el navegador a la 2.0.0.5.
Sin duda, una de las partes más incómodas del desarrollo web es cuando toca ir abriendo las páginas en infinidad de navegadores de diversos sistemas operativos. Por mucho que nos esforcemos, hay bugs en todos ellos (algunos más, otros menos pero no hay navegador perfecto). Gérard Talbot ha recopilado un listado de estos bugs en los navegadores más conocidos: Mozilla, Internet Explorer 6, Opera 9 e Internet Explorer 7.

Seguro que le saco mucha utilidad, no va a solucionarme todos los problemas pero seguro que me ayuda a dar antes con ellos.
http://www.gtalbot.org/BrowserBugsSection/
Sin duda, con la salida de Internet Explorer 7 muchos sentimos la necesidad de que todos nuestros usuarios actualicen para poder desplegar nuestro arsenal de estilos avanzados sin necesidad de comentarios condicionales, hacks y trucos varios.
Lamentablemente, la tasa de usuarios de Internet Explorer 6 e incluso inferiores se mantiene estable.
Dean Edwards, cansado de tener que ensuciar su código para hacerlo funcionar en navegadores que no soportan los estándares, creó hace ya un par de años una librería muy interesante en Javascript: IE7.
IE7 se encargará de servir a estos navegadores “no acordes a los estándares” una versión del estilo que puedan interpretar correctamente.
Gracias a IE7 podrás emplear selectores avanzados, PNG transparentes, posicionamiento fijo (sin parpadeos), arregla etiquetas rotas (como abbr) etc.
IE7: http://dean.edwards.name/IE7/
Ya lo hemos comentado antes, la guerra de los navegadores vuelve a ser un tema de discusión. Como ya dije en su momento, yo utilizo Firefox porque para mi, ahora mismo, es la herramienta más cómoda.
A través de Xybernéticos descubro Browserwars, una pequeña encuesta sobre navegadores.

Está claro que los datos de una encuesta de este tipo no son fiables ni “científicos” pero parece que el ganador claramente es Firefox, por lo menos en el corazón de los usuarios. Lo que me resulta extraño es que, visto el movimiento de sus usuarios en los últimos meses, Opera vaya tan por debajo de los demás.
¿Por qué escogéis uno u otro navegador? ¿Nadie usa alguno que no sean “los 3 grandes”?
Browserwar: http://browserwar.info/
Existen múltiples test y validadores para tu código que puedes emplear online, no obstante, si necesitas ir validando múltiples sitios puede ser laborioso ir acudiendo al sitio de cada herramienta.
Si hay una ventaja que hace destacar a Firefox sobre los demás navegadores (sin ánimo de polemizar, otros navegadores también tienen sus herramientas pero se salen de la perspectiva de este blog al no ser software libre) son sus extensiones.
Para todos los desarrolladores web, existen numerosas extensiones que nos ayudarán a validar y verificar nuestro código:
Validar nuestro HTML y CSS
- HTML Validator:
HTML Validator te indicará si hay errores o advertencias de validación en tu código mediante un icono en la barra de estado.
Podrás acceder a los detalles de los errores mirando al código fuente de la página.
Esta extensión está basada en Tidy y OpenSP (SGML Parser).
- Offline Page Validation:
-
Con Offline Page Validation podrás enviar cualquier página que estés visitando al servicio de validación del W3C incluso si son páginas locales, que requieran registro, etc.
- CSS Validator
-
Valida tus hojas de estilo mediante el servicio del W3C
Comprobar la Accesibilidad
- HERA
-
La “HERA-Extension” es una extensión para los navegadores de la familia Mozilla (Netscape, Firefox, Flock, Safari, etc.), que permite revisar online, en un solo clic, la página web que estemos visitando e incluso un marco de esa página (si los tiene), facilitando el uso y acceso a HERA.
- TAW3 en un click
-
TAW3 en un click te permite comprobar la accesibilidad de las páginas que visites, utilizando el servicio TAW3 Online y las reglas WCAG 1.0
- Colour Contrast Analyser
-
Con ella podrás comprobar que el contraste de los colores que has escogido para tu sitio web es adecuado para todos tus posibles visitantes
- Fangs Screenreader Emulator
-
Te mostrará tus páginas de forma similar a como las interpreta un lector de pantalla
- Firefox Accesibility Extension
-
Esta extensión está pensada para ser una ayuda en la navegación de personas discapacitadas pero los desarrolladors podemos utilizarla para comprobar si su desempeño es correcto
Herramientas “todo en uno”
- Webdeveloper Toolbar
-
Entre sus múltiples posibilidades (de las que hablaremos en unos días en profundidad) está la de validar tus sitios locales y los sitios que visites, tanto su html y css, como su accesibilidad…
- Total Validator
-
La extensión Total Validator, de la que ya hablamos por aquí, te permite realizar múltiples validaciones en un solo click
- Checky
-
Valida HTML, XHTML, CSS, RDF, RSS, XML, WAI, Section 508, P3P, Hypervínculos, Metadata y más
Firebug es, sin duda, una de las herramientas más potentes y conocidas para controlar la calidad de nuestro código. No obstante, la curva de aprendizaje para sacarle el máximo partido puede ser un poco pronunciada para algunos. Por eso, aquí os dejo el enlace a una interesantísimo artículo con trucos para Firebug, que nos ofrece generosamente Mojo Seifi

A través de Ajaxian me entero de que ha salido la versión 1.0.3 de Firebug, una actualización recomendada encarecidamente ya que soluciona varios problemas y cubre una vulnerabilidad 0-day.
Podéis actualizaros mediante la actualización automática de vuestro firefox o desde el sitio web Get Firebug.

A raíz de un meneo que comenta la existencia de sitios “solo para Firefox” (de una forma más radical que el too cool for ie) se me ha planteado una duda.
¿Realmente debemos los desarrolladores web tomar partido en estas guerras por el “mercado” de los navegadores?
Está muy bien que todos queramos borrar de la faz de la tierra a este o aquel navegador que nos provoca intensos dolores de cabeza cuando estamos trabajando con una plantilla pero cerrarse en banda a un navegador ¿es la forma más adecuada de plantarle cara?
Por desgracia, el único perjudicado es el webmaster que restringe el uso de su sitio a este o aquel navegador. Seguramente un usuario de Internet Explorer o Firefox no va a cambiar de navegador sólo porque tu así lo quieras (dios nos libre) y, en todo caso, conseguirás que acceder a tu sitio web le suponga un fastidio al tener que abrir “el otro navegador”.
Por otro lado, destrozar las hojas de estilo con hacks para solucionar este o aquel problema o, incluso, tener que recurrir al javascript para emular ciertas funcionalidades, es un exceso. Al final acabamos todos a expensas de las decisiones de uno, que hace y deshace como mejor le conviene.
Yo he optado, en el caso de este blog, por la “resistencia pacífica”: en lo estructural, el blog se ve bien en todos los navegadores, en el estilo los usuarios de Internet Explorer 6 se llevan una versión “sin refinar” (png sin transparencia, formularios sin hover…).
Supongo que, dependiendo del tipo de sitio, se puede uno arriesgar a olvidarse de ciertos navegadores pero ¿cual consideráis que es la postura más adecuada para un webmaster en la “guerra de navegadores”?
Como ya sabréis, Internet Explorer no se lleva demasiado bien con la etiqueta <q> La ignora completamente y, por tanto, perdemos las comillas de las citas. Siempre podemos incluir las comillas manualmente ¿no?
Pero, claro, las etiquetas aportan significado semántico, no deberíamos tener que prescindir de ninguna por caprichos de un navegador.
Como ya vimos con el caso de los png, existen unos archivos llamados behaviors (comportamientos) que nos permiten proveer de estas funcionalidades a Internet Explorer.
Para utilizarla, la descargamos de Will code 4 beer: fixQuotes_en.htc y lo llamamos con un poco de CSS que dará a Internet Explorer las instrucciones pertinentes.
- <style type="text/css">
- q { behavior:url(fixQuotes_en.htc); }
- </style>
Atento porque utilizará las reglas de entrecomillado inglesas, para utilizar otras edita el archivo htc, para saber como visita el artículo original: Fixing the Quote Tag in Internet Explorer