Uno de los elementos más prácticos –en mi opinión– en la barra lateral de este blog es la información meteorológica, de la que voy a hablar hoy.

weather.pngEn este pequeño espacio se resumen la nubosidad, temperatura, humedad, visibilidad, dirección y velocidad del viento, presión atmosférica (en hectopascales, equivalentes a los milibares) y punto de rocío.

El primer paso para tener este panel de información meteorológica en un blog gestionado con WordPress es instalar el plugin WeatherIcon. Dado que el plugin está escrito en PHP su código se puede empotrar en cualquier sitio web programado en este lenguaje con mayor o menos facilidad.

Este plugin proporciona la función WeatherIcon, que genera el código XHTML con las características atmosféricas para el aeropuerto o estación meteorológica correspondiente al código de cuatro letras que recibe por medio del parámetro obligatorio station.

Los códigos de aeropuerto de ICAO incluyen no sólo aeropuertos sino también estaciones meteorológicas, que es lo que nos interesa aquí. Dado que las dos primeras letras identifican el país, la lista completa por código permite buscar fácilmente por país: España, Irlanda y Reino Unido.

Normalmente incuirías en tu blog la información de tu estación meteorológica más cercana, pero en mi caso nunca fue así. Para empezar, en Tenerife tenemos dos aeropuertos y conviene vigilar las condiciones meteorológicas de ambos para hacerse una idea de cómo está el tiempo en la isla. No presenta ningún problema utilizar la función WeatherIcon varias veces con distintos valors del parámetro station, pero si son más de dos o tres pueden ocupar un espacio considerable.

Para mantener a la vista un puñado de estaciones meteorológicas elegí crear un elemento compacto que incluyera un desplegable para cambiar de estación y fijar como estación por defecto la más cercana a mí. Esto planteaba dos problemas: uno de diseño y otro de programación.

El primer problema no fue difícil gracias a que el código XHTML generado por la función WeatherIcon está bien estructurado y es completamente semántico, dejando toda la parte visual bajo el control del estilo definido en la CSS. Para dar una idea de cómo es el código basta mostrarlo sin estilo:

  • Cloud and Visibility OK
  • Temperature: 15°C
  • Humidity: 38.5%
  • Visibility: 10km
  • Wind: WNW at 24 km/h
  • Barometer: 1018 hPa
  • Dew Point: 1°C

La típica lista de elementos <li> que puede mostrarse con todos sus elementos en una línea modificando el estilo de estos elementos. Luego, para deshacerme de las descripciones de los datos las eliminé modificando su atributo display. El icono de nubosidad había que sacarlo de la lista, así que lo hice flotar a un lado. Finalmente quedaba el problema del desbordamiento: no quería que los elementos se salieran del área designada cuando el usuario aumenta el tamaño de la fuente –Ctrl-+ en Firefox–, así que determiné que los elementos desbordados quedaran ocultos, modificando la propiedad overflow. A continuación la parte crucial de la CSS implicada en estos tres puntos, el resto de la CSS son sólo colores, márgenes y tamaños.

#weather {
overflow: hidden;
}
#weather div#weather-actual li {
list-style: none;
display: inline;
}
#weather div#weather-actual li .weather_title {
display: none;
}
#weather div#weather-actual img {
border: none;
float: left;
}

El fondo verde se debe a que uno de los iconos de nubosidad –el de niebla– es totalmente blanco, por lo que si dejaba el fondo en blanco ese icono no se veía y resultaba desconcertante.

Hasta aquí la parte bonita, en la que sólo se trata de modificar cómo se ven las cosas y la suerte me sonrió porque respetar el estándar CSS era suficiente para que funcionara todo igual de bien en todos los navegadores –hasta en Internet Explorer, sorprendentemente.

Para tener varias estaciones meteorológicas disponibles y poder cambiar entre ellas sin recargar la página me hubiera gustado utilizar AJAX, pero aún no he aprendido esa vía y no quería retrasarme más, así que no me quedó más remedio que usar JavaScript y añadir al elemento <select> del desplegable la propiedad onchange="changeStation()" para cambiar el contenido del elemento <div id="weather-actual"> al cambiar la selección.

Como estos elementos están al principio de la barra lateral, implementé la función changeStation al final de la misma para no retrasar la carga de los demás elementos. Esta función recoge el código ICAO e invoca a la función getStationContent para obtener el código XHTML con la lista de elementos con la información meteorológica.

La primera versión de esta función obtenía el código XHTML extrayendo el contenido del elemento <div id="weather-XXXX">, siendo XXXX el código ICAO. Así tenía en el final de la página unos cuantos (17) elementos <div> que no eran visibles gracias a la propiedad visibility: hidden en la CSS. El problema vino cuando descubrí que el Internet Explorer hacía estos elementos invisibles pero no por ello dejaban de ocupar espacio, lo que resultaba en un enorme espacio vacío que no debería estar ahí. Muy molesto.

Como no encontraba manera de asegurarme de que el Internet Esplorer no dejara aquel enorme espacio vacío, decidí que el código XHTML habría de estar empotrado en la función getStationContent, cuyo código sería generado por un código PHP para facilitarme modificar la lista de estaciones meteorológicas. También tuve que modificar ligeramente el plugin WeatherIcon para que no pusiera saltos de línea en el código que generaba.

Un código PHP que escribe una función JavaScript que devuelve código XHTML no es algo fácil de mostrar en un navegador web, ni siquiera las etiquetas <code> y <pre> han podido con ello. pantallazo al canto :-D

code.png

No me gusta esta solución, me hace sentir sucio, pero funciona. Después de todo no es tan brutal como empotrar JavaScript en un HTML empotrado en una consulta SQL empotrada en una página ASP para mostrar vídeos empotrados en elementos OBJECT empotrados en un HTML empotrado en una base de datosWTF? :-D