Frontend Web Dev

Hace algunas semanas estuve buscando un plugin jQuery con el que poner un “slider” a pantalla completa con imágenes de background para un sitio web que estoy diseñando. Tras una larga búsqueda en la que me centraba en bastantes criterios (ligero, sencillo, actualizado, html, responsive, touchable) encontré varios candidatos para ser incluídos pero ninguno de ellos llegó a convencerme.

Probé más de una decena de sliders sin suerte ya que encontré algunos que no parecen estar muy testeados y otros que no parecen haber sido pensados para usar fácilmente y requerían de una cantidad de parámetros exagerada (debe ser que no se conocen los valores por defecto) o una estructura HTML que no viene a cuento y que parece de la época de FrontPage, pero el mayor problema era la funcionalidad que yo quería encontrar y que no encontré nadie que la implementara, es decir, tener la posibilidad de que el indicador de posición (las bolitas que todos tienen) que marca la slide que se muestra en cada momento en pantalla, pudiera ser sustituido por un bloque de contenido y que además, al seleccionarla navegara al contenido y no a la slide relacionada.

Desde hace ya algunos años, una de las técnicas más usadas en las Hojas de Estilo en Cascada (CSS) para maquetar en sitios web que deban mostrar elementos de tipo bloque en línea es la de establecer su regla “display” con el valor “inline-block”. El uso de “display: inline-block;” nos permite realizar menús, muestras de elementos, etc, sin necesidad de recurrir a elementos flotantes con la regla “float” que ya se encuentra desaconsejada salvo necesidad expresa o la muy mala práctica de maquetación consistente en usar tablas para distribuir el contenido. Así pues, en este artículo os expongo el problema y varias soluciones en mayor o menos medida recomendadas puesto que algunas las considero malas prácticas y otras son algo “raras”, pero sin duda, al final del artículo encontraréis la que a mi parecer es la forma correcta de realizar este tipo de maquetado. Podéis descargaros el website de ejemplo para seguir el artículo desde este enlace.

Es muy común que en nuestras aplicaciones necesitemos abrir popups y, para ello, generalmente se suelen usar plugins JavaScript como jQuery.UI u otros que son algo más pesados de lo que realmente necesitamos. Además, normalmente, los plugins añaden estilos que no nos hacen falta y que debemos sobreescribir con gran esfuerzo para no perder el look&feel de nuestro sitio web.

¿Qué podemos hacer para evitar «problemas» sólo por intentar abrir popups?

El pasado, jueves 16 de octubre, volvimos a la acción desde TenerifeDev con dos sesiones creo que bastante interesantes para los desarrolladores y diseñadores web. En esta ocasión, las sesiones las dimos en las instalaciones de la FEULL (Fundación Empresa de la Universidad de La Laguna) que como siempre, colaboraron activamente con nosotros para poder compartir conocimientos con todos los asistentes, entre los que siempre destaca una alta presencia de estudiantes que se pueden enriquecer con la experiencia que podamos aportar sobre la vida laboral. Este es el resumen de las sesiones. Enjoy!

En este artículo os voy a mostrar un tip muy sencillo.

Escenario

Se puede dar el caso en el que algún día debáis poner una acción en algún sitio web que tenga como requisito poder imprimir el contenido sin necesidad de generar un documento formateado por ejemplo en PDF.

Solución

Para proveer esta característica, lo mejor es recurrir a JavaScript dado que es una acción de cliente y dado que los datos están ya en el navegador, no necesitamos de enviar nada al servidor. Para realizar esta acción, el código que debemos escribir no podría ser más sencillo. Voy a ilustrarlo con un ejemplo haciendo uso de un «link» que ejecute código JavaScript «unobstrusive».

Escenario

En más de una ocasión podréis encontraros con que algún cliente decide tener un botón para copiar un texto al portapapeles (clipboard) de forma automática en un sitio web. Esta tarea se torna extremadamente fácil si estamos usando Internet Explorer puesto que dispone de esa capacidad pero, en el caso de otros navegadores como Chrome, Firefox, Opera,… debemos buscar una alternativa.

Solución

Internet Explorer

Como ya he adelantado, en Internet Explorer es muy sencillo de realizar. Tan sólo habría que usar el objeto “window.clipboardData” para realizar la tarea que deseamos.

Hoy me gustaría compartir una reflexión con todos ustedes acerca de las buenas formas para crear una hoja de estilos en contra punto al uso de hacks e ideas estrambóticas que pueden hacer de una hoja de estilos algo ilegible y que te dan ganas de tirar a la basura.

Uso de hacks

Los hacks en CSS son “trucos” para que determinados navegadores interpreten las hojas de estilo de forma diferente y generalmente se usaban para corregir la mala interpretación que hacían a determinadas propiedades. Se popularizaron durante la etapa en la que la versión del navegador de Microsoft era Internet Explorer 6 (IE6) que, debido a su “errónea” “especial” interpretación del modelo de caja (ancho/alto, padding y margen), hacía del diseño de páginas web una tarea dura. No era extraño ver diseñadores web que renegaban del navegador más popular que debían instalarse programas que renderizaban sus webs en N navegadores diferentes para poder ver las diferencias y así poder ir ajustando la visualización de las mismas de forma menos lenta. Una prueba que dejaba en gran evidencia estos problemas era la nota que obtenían los diferentes navegadores en “Acid Test”.

Escenario:

Supongamos que queremos cargar jQuery sólo cuando lo necesitamos, por ejemplo, si tenemos un Control de usuario, o una librería de funciones que hace uso de jQuery y no queremos depender de si el portal web en el que lo queremos incrustar ya ha realizado la carga de esta librería de javascript.

Solución:

Aunque es algo bastante sencillo, siempre tengo que buscarlo y cada vez que lo hago me encuentro soluciones “estrambóticas” que en vez de facilitar la vida, la complican más aún. Por eso, quería contribuir con la solución más eficaz a esta cuestión.

Escenario:

Estos días he estado realizando una web pública http://www.boPlace.com para una aplicación de Windows Phone 7 que hemos desarrollado Alberto Díaz Martín y yo. Al probarla desde Visual Studio todo funciona perfecto. Se abre el Internet Explorer 9 que es el que tengo asociado y todo se ve correcto.

Ahora viene el problema. Hemos publicado la web desde un servidor interno que, por x motivos relacionados con Proxies, Firewalls,… para acceder al sitio, no puedo usar www.boPlace.com, sino que tengo que hacerlo con la ruta interna y… la cosa se pone fea (la web) porque se ejecuta en el modo de compatibilidad IE7. Como la web usa hojas de estilo que no son compatibles del todo con IE7… se ve muy mal, aunque como la gente que no está muy metida en el mundo de la informática no suele actualizar los navegadores (todavía quedan IE6 por ahí), habrá que hacer que se vea bien. Pero este no es el problema, el problema es… ¿por qué si accedo a la ruta local del sitio web, explorer se pone en modo compatibilidad?