Adaptar el tamaño de una web a pantallas grandes con un simple zoom vía CSS

Mirad, lo que os voy a contar no es la más optima de las soluciones, pero sí es un recurso que en algún momento os puede ahorrar trabajo para salir del paso.

Hoy por hoy, todo es optimización para dispositivos móviles, de hecho la web va camino de tener que orientarse casi exclusivamente para ese tipo de pantallas, dejando las de sobremesa en un segundo lugar, ¿os suena eso del «mobile first«? Pero siempre está ese cliente puñetero o ese usuario final exigente al que le da por ver vuestro trabajo en su televisor HD y os dice con su voz más odiosa: «Pues en mi pantalla se ve todo muy pequeño y con mucho fondo por los lados…» ¿¡En serio!? ¿Quién ve las webs de artículos de lectura en sus televisores? La gente. La gente ve cualquier cosa en cualquier tipo de dispositivo porque para eso somos muchos, con demasiado tiempo y con multitud de formas de enfrentarnos a la misma sencilla y pequeña página web.

Lo ideal, en estos casos, sería ponerse a diseñar una nueva disposición para que nuestra web encajara también en pantallas «enormes» al igual que ya lo hace en las de las tabletas y las de los móviles… o, por qué no, contar con una ordenación de parrilla o cuadrícula al más puro estilo Pinterest, de manera que los elementos se agrupen de uno en uno, dos, tres o veinte dependiendo de cada pantalla. Pero muchas veces este tipo de presentación no es compatible con lo que necesitamos o con lo que nos han pedido y, si somos un poco rastreros, a ese usuario de antes le hubiéramos contestado: «¿Es que no sabes usar el zoom de tu navegador?» ¡Eureka!, ¿y si obligamos a la página a hacer zoom aunque el inútil de turno no sepa? Pues dicho y hecho.

Imagen que compara la vista entre la web sin zoom y con zoom
Continuar leyendo «Adaptar el tamaño de una web a pantallas grandes con un simple zoom vía CSS»

Validación de formularios del lado del cliente: JavaScript Vs HTML5

Imaginad que estáis desarrollando vuestro website modernísimo de la muerte y, por tanto, decidís hacerlo en HTML5. Llegáis a la parte del formulario de contacto, lo validáis con HTML5 y, probando en Safari (porque todos los guays de ahora programan en Mac y tienen Safari y prueban las cosas ahí también), os horrorizáis al ver que Safari suda de vuestra verificación y manda los formularios vacíos o mal completados. Aaaaaamigos, ¡bienvenidos una vez mas al maravilloso mundo de: ¿por qué me dediqué yo a esto con lo feliz que sería haciendo otra cosa?!

Veamos cómo funcionan las validaciones del lado del cliente, es decir, en el dispositivo del usuario que interactúa con nuestra web, no en el servidor donde ésta está alojada (verificaciones estas otras que son también necesarias y deseables pero de las que no hablo en esta ocasión).

Por un lado tenemos la forma de toda la vida de verificar que, cuando alguien nos manda un formulario, al menos haya algo escrito en él: El JavaScript (está también muy de moda la verificación JQuery, pero a fin de cuentas…). Por otro lado, tenemos la forma más reciente propuesta por HTML5. A saber:

 

Ventajas y desventajas de la verificación con JavaScript

A favor

  1. Personalizable
    • En casuística (que para eso la programas)
    • En diseño (para poner colorines y mensajes de alerta)
  2. Mayor compatibilidad con navegadores (casi todos los modernos y no tan modernos)

En contra

  1. Algunos usuarios pueden tener el JS deshabilitado (lo hacen por fastidiar, ¡lo sabemos!)
  2. Hay que programar cada verificación (y eso es un engorro)

 

Ventajas y desventajas de la verificación con HTML5

A favor

  1. Validación nativa, es decir:
    • Rápida para el desarrollador, pues no requiere programar las verificaciones, basta con decir: oye, esto es obligatorio (required)
    • Rápida y segura para el usuario, su navegador lo hace todo, sin complementos
  2. Mayor precisión semántica:
    • De la generalidad del campo de tipo texto, pasamos a poder especificar si se trata de un email, una url, una fecha…
  3. Ideal para dispositivos móviles:
    • Algunos terminales mostrarán distintos tipos de teclado según los datos que se tengan que introducir (números para fechas, @ para emails, .com para urls…)

En contra

  1. Escasamente personalizable:
    • En cuanto a diseño de los errores/alertas (los navegadores se lo guisan, los navegadores se lo comen)
    • En cuanto al control de determinados comportamientos de la validación (ver caso con textarea explicado más abajo)
  2. Menor compatibilidad con navegadores, habiendo casos sangrantes:
    • (a 2014) Safari, aunque reconoce los input types de HTML5, no reconoce el atributo required y, por tanto, envía los formularios sin validar (¡alegría! NO.)

Continuar leyendo «Validación de formularios del lado del cliente: JavaScript Vs HTML5»

Trabajando con CSS: Considera evitar el uso de @import

Hace unos meses explicaba por este mismo blog cómo organizar la apariencia de una web con hojas de estilo en cascada y, aunque aparentemente, la organización que comentaba quedaba ideal de la muerte (así como todo muy clarito y bien ordenado) al final resulta que es una solución de la muerte, para nada ideal.

El problema está en que, en aquella ocasión, yo hacía hincapié en que era mucho más práctico tener una única llamada a la hoja de estilo en la cabecera de la web cargando los demás CSS dentro de otro y abusando de las posibilidades que brinda @import  como solución limpia y ordenada. Pero en la práctica este caso penaliza el rendimiento de la web y, por lo tanto, se desaconseja su uso.

Captura web de los resultados obtenidos con la propiedad import
Resultados de velocidad de carga obtenidos con la versión que emplea @import

Depurando código

Rehago pues la plantilla web creada para explicar aquello y compongo una nueva llamando a una única hoja de estilo desde la cabecera de la página web. Podéis husmear en sus entresijos, que para eso está: DEMO en vivo y DESCARGA de los archivos.

Como podéis ver en las capturas de pantalla que ilustran esta entrada, la versión que utiliza el recurso @import obtiene peores resultados en el test que Google pone a disposición de los desarrolladores (y cualquiera con interés) que esta nueva versión que no lo usa. Esto se debe al tiempo que tardan los exploradores en interpretar las distintas llamadas: aquellas hechas mediante @import se leen una a una, mientras que las integradas en el <head> de la web pueden ser descargadas a la vez. Google lo explica mejor, pero en inglés.

Captura web de los resultados obtenidos con PageSpeed sin import
Resultados de velocidad de carga obtenidos con la versión que NO emplea @import

Continuar leyendo «Trabajando con CSS: Considera evitar el uso de @import»