Angel Custodio



Este es el lugar en el que escribo iré escribiendo todo aquello que pienso, siento y creo, sin tapujos ni adornos... a veces incluso
obviando la diplomacia, pero siempre con respeto e intentando aportar algo útil a todo aquello a lo que me refiera.

Simplemente se trata de cómo veo yo las cosas. Bienvenido.
 
follow me @ancude
Estás en el archivo del tag: CSS

  • Crimen #1: Labels que no están relacionadas con su input en un formulario
  • Crimen #2: Logo que no enlaza con la página principal de la web
  • Crimen #3: No especificar un color para enlaces visitados
  • Crimen #4: No indicar el campo activo de un formulario
  • Crimen #5: Dejar una imagen sin descripción alternativa
  • Crimen #6: Dejar una imagen de fondo sin color de fondo
  • Crimen #7: Utilizar párrafos de texto demasiado extensos
  • Crimen #8: Subrayar texto que no es un enlace
  • Crimen #9: “Haz click aquí”
  • Crimen #10: Utilizar texto justificado

Esto es lo que señala Chris Spooner en Line25 y que pasaré a comentar seguidamente ya que no estoy del todo de acuerdo, algunos puntos (creo) necesitan matizarse.

El punto #2 ya es relativo de por sí.
Quizá tenemos el logotipo en la página, casi seguro, pero si indicamos específicamente que hay un enlace que sirve para volver a la página principal, el logotipo no tiene por qué servir también como enlace para esa misma acción. Nunca estará de más, obviamente.


Como todo buen maquetador sabe, hay ciertos programas que se pasan los estándares por el forro el pito del sereno. En consecuencia, nos obligan a utilizar esas líneas de código que hacen milagros donde había imposibles llamadas hacks.

Un hack no es más que una manera de introducir código de algún tipo (CSS en este caso), de tal manera que se consigue su carga en un determinado programa, en este caso, en un determinado navegador.

Es por todos conocidos que la familia Internet Explorer interpreta con bastante ligereza lo que una web debe mostrar en realidad; que si yo interpreto los paddings y margins como me da la gana, que si el border también suma para el ancho total, que si esta propiedad no la conozco… etc. Multitudes de fallos por una estrategia errónea de Microsoft que ha ido arrastrando durante años, pero eso es otro tema.

Al grano.
IE8 es un buen navegador en comparación con su predecesor IE7 y exageradamente superior a su ancestro IE6. Respeta bastante bien la mayoría de estándares, pero también tiene “sus cosas”, las cuales vamos a solucionar con las siguientes líneas de código en el CSS.

1) *:first-child+html elemento { propiedad: valor; }
2) elemento { propiedad /*\**/: valor\9 }

¿Qué estamos haciendo con esas líneas?
Si buscamos por Google, veremos que el 2º hack corre por internet como el milagro antigrasa de IE8, pero no es así. Ese código lo interpreta también IE7, por lo que habrá que re-hackear de tal manera que IE7 interprete “otra cosa”.

La solución está en el first-child. Lo pongamos donde lo pongamos será lo que interprete IE7 sin tener el cuenta el hack de los asteriscos. Digamos que actúa como un !important.

Obviamente, esto no valida ni de broma, pero es otra solución si como a mí no os gusta nada llenar el código de condicionales comprobando la versión de IE.

Aunque existe otra forma más la cual no he podido comprobar si valida.
El código que os pongo a continuación no va sobre el CSS si no directamente sobre el archivo XHTML que estéis maquetando y hace algo más “bestia” pero bastante efectivo y que ahorra tiempo, sudor y lágrimas.

<meta http-equiv=”X-UA-Compatible” content=”IE=7″ />

Con ese meta que pondremos dentro del head, haremos que IE8 entre en el Compatibility Mode y renderice la web como IE7. Con esto conseguiremos poder reducir el número de hacks ya que no hará falta tener en cuenta a IE8 a la hora de maquetar. De todas formas, no es la vía más recomendable por ser algo drástica. Sólo debería usarse en el supuesto de que tengamos la web perfectamente adaptada a IE7 y suponga demasiado tiempo su arreglo.

La mejor solución; utilizar Firefox, Safari, Opera o Chrome.


Me llega al correo un estudio rápido acerca de cómo los usuarios reaccionan ante la velocidad de carga de una página web.

La verdad es que encuentro los resultados bastante fieles a la realidad o por lo menos a tal y como actúo yo hoy en día por la red. No es tampoco muy normal encontrarse una web que tarde más de 3 segundos en cargar (por ejemplo) con las conexiones de hoy en día. Es muy complicado a no ser que contenga elementos de mucho peso, esté desarrollada en Flex, la base de datos sea descomunal… etc.

Aquí tenéis los resultados.

  • El 47% de los visitantes esperan que una página cargue en dos segundos o menos
  • El 40% abandonan una página si tarda más de 3 segundos en cargar
  • El 52% de los compradores online opinan que la velocidad de una página es muy importante de cara a la lealtad con la misma
  • El 14% empezaría a comprar en otra página si ésta tarda en cargar. El 23% dejarían de realizar la compra
  • El 64% de los compradores online insatisfechos con la visita a una tienda online visitarán otras tiendas para las próximas compras

La optimización de las websites para mejorar la velocidad de carga de las mismas es el pan de cada día en los departamentos de diseño/maquetación. Hay soluciones muy concurridas como la eficiente técnica de utilizar sprites, la cual aligera la petición de imágenes al servidor uniéndolas y “llamándolas” desde CSS mediante posiciones.

Uno de los grandes que utilizan esta técnica es YouTube.
Aquí podéis ver la imagen generada que utilizan para todo el site.

Enlace | Sobre sprites en CSS Tricks


página 1/11