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

We believe that the easiest way to change people’s behaviour for the better is by making it fun to do. We call it “The Fun Theory”.

Piano Stairs

The world’s deepest bin



twitter-decision-flowchart-spanish

Flowchart original por David Bradley @ http://bit.ly/flow-chart


WebKit es un motor de renderizado open source que utilizan diversos navegadores para mostrar, según sus características y compatibilidad con el motor, una web de una forma en concreto. Además, se caracteriza por un desarrollo constante y sobretodo por su respeto a los estándares web.

Pese a esto, no todos los navegadores soportan el 100% de las funcionalidades que WebKit permite, así que si hilamos realmente fino al desarrollar una aplicación/página web, deberemos tener en cuenta esta lista de porcentaje de compatibilidad entre navegadores y el mencionado motor.

webkitcompattests

Podemos consultar una lista más detallada de las funciones compatibles con cada navegador en la página de Quirksmode.org dedicada a WebKit. En la misma, incluyen una tabla comparativa en la que se van otorgando puntos a los diferentes navegadores según sus características y/o buenhacer en diferentes “disciplinas”.

Vía | aNieto2K
Fuente | Ajaxian


Leía esta mañana en El Mundo un artículo en el que se informaba de las sanciones que establecerá la Comisión Federal de Comercio de Estados Unidos a bloggers que no informen adecuadamente de su relación con empresas/anunciantes de las que hable en su web.
Éstas podrían llegar a ser de hasta $11.000 si no se informa de manera clara y evidente la relación blogger/anunciante.

El artículo es el siguiente;
“Multa a los bloggers que no informen de su relación con los anunciantes”.

Mi compañero de Cava&Twitts, Marc Cortés, no tardaba en expresar su opinión acerca de lo que le parece correcto y lo que no de esta medida. Así que yo no voy a ser menos :P

Dejando de lado lo que pueda afectar al consumidor, el cual creo que es suficientemente inteligente como para saber qué comprar y qué no sin la opinión de un periodista o un blogger, creo que lo que nos estamos dejando por el camino es la vieja aspiración del blogger a convertirse en la alternativa anárquica del periodista.


  1. Accesibilidad significa tener dos versiones de un sitio web
  2. La accesibilidad web es asunto de diseñadores y programadores
  3. Las páginas web accesibles son feas y aburridas
  4. Los usuarios deben visualizar el sitio tal y como lo diseñó su autor
  5. La accesibilidad web es solo para ciegos
  6. La accesibilidad web significa no usar Flash
  7. Las herramientas automáticas determinan el nivel de accesibilidad
  8. Las versiones de solo-texto son suficientes para garantizar la accesibilidad
  9. Para qué hacer un sitio web accesible si las personas con discapacidad no son mi target
  10. Hacer un sitio web accesible es costoso

Enlace directo (Slideshare)
Autor | Mario Carvajal @astromario www.astrolabio.com.co
Vía | Sonia García


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.