aNieto2K Desarrollo web, Wordpress, y alguna cosilla más

Los navegadores web están desarrollados por equipos de personas que intentan acatar las normas que la W3C indica que deben cumplirse para que las páginas web se vean tal y como se ven. Evidentemente cada equipo tiene una visión de las normas y cada visión da como resultado una implementación. Por lo tanto cada equipo de desarrollo obtiene una implementación diferente de una misma normal.

Otros navegadores con más cota de mercado (IE’s) intentan cubrir las muchas necesidades que los usuarios solicitan, algo que lleva a la implementación de funcionalidades no incluidas en las normas especificadas por la W3C.

Otros navegadores con ansias de más cuote de mercado (FF, WebKit,/Safari, Opera,..) implementan nuevas funcionalidades a modo de propuestas para que la gente de la W3C piense en si deberían incluirlas dentro de las normas que definen ese estandar.

Está claro que cada navegador es una aplicación por separado y que la especificación sirve de guia para que estas aplicaciones vayan sobre un mismo rail. Quizas el rail es demasiado ancho y permite que varias aplicaciones tengan implementaciones muy diferentes, lo que nos obliga a los desarrolladores a usar hacks en capas más externas para obtener un resultado similar en todos los navegadores.

Una muestra de esta interpretación, son las diferencias entre la forma de mostrar los padding de ciertos elementos, como podemos ver, las diferencias son mínimas (en algunos casos). Pero muestran claramento la diferencia de visión de una misma idea desde diferentes equipos.

El CSS está destinado a gestionar por completo el aspecto de una aplicación web, ¿pero hasta que punto?.

Las nuevas propuestas presentadas por el equipo de WebKit, recopiladas en CSS3.info. Pueden llevar a un debate interesante por parte de los más entendidos.

• CSS Animation
• CSS Transforms
• CSS Transitions
• CSS Variables

Todas las propuestan, pretenden convertir el lenguaje de maquetación CSS, en un lenguaje cargado de nuevas funcionalidades que enriquecerán  sustancialmente las posibilidades que actualmente ofrece.

Las CSS variables nos salvarán la vida en un futuro, y nos permitirán crear diseños nuevos simplemente reemplazando los valores de algunas de ellas. Las animaciones/transformacones/transiciones nos ahorrarán líneas de código JS para delegar al diseño todo lo relacionado con las animaciones de la aplicación.

¿Que os parece? ¿CSS se está comiendo el terreno de JS? ¿JS podrá destinarse al funcionamiento y no al aspecto?

La gente de WebKit no para de incorporar nuevas funcionalidades a su navegador. Esta vez ha sido el API de selectores que la W3C publicó hace unos meses. Estos selectores nos permitirán completar las posibilidades de las que ahora disponemos para seleccionar uno o más elementos de nuestro DOM. 

Actualmente disponemos de métodos como getElementById, getElementByTagName y el recien integrado en el core, getElementByClassName (de forma nativa) con lo que ya podemos manejarnos perfectamente, pero, ¿nos vamos a contentar con solo estos métodos?. Está claro que no, debemos facilitarnos la vida con querySelector() y querySelectorAll(), podemos conseguirlo. Veamos un ejemplo de su uso.

Ejemplo

document.querySelectorAll(".hot"); // Seleccionar todos los elementos con clase hot

document.querySelector(":hover"); // Seleccionamos el elemento que esté en modo :hover (el ratón sobre él).

document.querySelectorAll("#large:nth-child(even)"); // Ejemplo de como conseguir elementos intercalados (por ejemplo para tablas zebra)

Tests

Desde la propia página de WebKit nos facilitan un test, basado en SlickSpeed de MooTools, en el que podemos testear el funcionamiento de estas funciones nativas (únicamente desde Webkit última versión). 

Viendo los tiempos obtenidos por la versión nativa (columna de la derecha), frente a los frameworks testeados (Ext 2.0, Prototype y jQuery) notamos la diferencia y la mejoría (y necesidad) de que estos métodos se incluyan en el navegador y no tengamos que implementarlos nosotros.

Descargar

Los Favicon, son las imagenes que acompañan al nombre de tu página en las pestañas de Firefox, Safari, Opera,… estos ayudan a conocer una página de un solo golpe de vista, ya que como dicen, «Una imagen vale más que mil palabras». 

El código HTML

Ponerlo en nuestra página web es algo tan sencillo como introducir un tag HTML en nuestro <head />. Tenemos 2 casos:

a) <link rel="icon" href="/favicon.ico" type="image/x-icon" />
b) <link rel="shortcut icon" href="/favicon.ico" type="image/x-icon">

En la mayoría de navegadores basta con usar la opción (a) ya que el rel debe indicar que se trata de un icono, aunque navegadores como Internet Explorer tienen problemas con este rel. Para evitar dicho problema se suele usar la opción (b), que producirá que los navegadores más estandares omitan la palabra «shotcut» y lo traten como si una «icon» se tratara.

Ruta

En el href, indicaremos donde se encuentra la imagen que mostraremos. Podemos usar rutas absolutas o relativas, lo que nos permite un gran grado de personalización en este aspecto, pudiendo tenerlo en un servidor externo o tener varios por servidor.

Interesante: Si llamamos al fichero favicon.ico y lo alojamos en la raiz de nuestro servidor, esta imagen será usada en cualquier sitio del sitio web.

Imagenes

Usaremos una imagen que puede ser de tipo:

• ICO
• GIF
• PNG

Dependiendo del tipo de imagen que usemos deberemos cambiar el type de nuestro tag para informar sobre el tipo de imagen que hemos optado usar y que el navegador va a cargar.

ICO) <link rel="icon" href="/favicon.ico" type="image/vnd.microsoft.icon" /> //M$
ICO) <link rel="icon" href="/favicon.ico" type="image/x-icon" /> //Estandar
GIF) <link rel="icon" href="/favicon.gif" type="image/gif" />
PNG) <link rel="icon" href="/favicon.png" type="image/png" />

Tamaños y Colores

Dependiendo del tipo de imagen que deseemos usar, tendremos que tener en cuenta las posibilidades entre tamaño y colores que podemos utilizar.

ICO

• Tamaño: 16×16 / 32×32 / 64×64 / 128×128
• Colores: 16,256,16 millones
  

GIF

• Tamaño: 16×16
• Colores: 256

PNG

• Tamaño: 16×16
• Colores: Desde 256 a 24-bit.

Jugando con javascript

Dynamic Favicon Library, es una librería desarrollada en Javascript que nos permite interactuar con nuestro favicon, cambiandolo o animandolo para ofrecer un aspecto diferente e innovador.

favicon.change("/icon/active.ico", "new title"); //Cambiamos el favicon con título
favicon.change("/icon/active.ico"); //Cambiamos el favicon
favicon.change(null, "new title"); // Eliminamos le favicon
favicon.animate(["icon1.ico", "icon2.ico", ...]); //Animamos el favicon con un array de imagenes.
favicon.animate(["icon1.ico", "icon2.ico", ...], {delay: 500} ); // Definimos el tiempo espera antes de cambiar las imagenes.
favicon.scrollTitle("new title"); // Hacemos que el título de mueva, estilo marquesina.
favicon.scrollTitle("new title", { delay: 200, gap: "------"} ) // Indicamos el tiempo de espera
favicon.unscroll(); //Eliminamos efectos de scroll
favicon.unanimate(); //Eliminamos efectos de animación.

[Demo][Descargar]

Menuda se ha liado con la última publicación de IEBlog, en la que anuncian un tag <meta /> sacado de la manga para activar el modo «Super Estandar» en su navegador. 

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

Se trata del sustituto del antíguo método para salir del modo Quirks, al que teníamos que jugar con el <!DOCTYPE /> de nuestra página. Si eliminabamos dicho tag, entrabamos en modo Quirks,  osea un modo más permisivo y menos estandar.

Al parecer los chicos de A List Apart, anunciaban la aparición del tag meta X-UA-Compatible, un tag que la gente de Microsoft ha desarrollado sin tener en cuenta al resto de navegadores. Como era de esperar la mecha a echado a arder casi instantáneamente, recordando tiempo del ActiveX() y el document.all, desarrolladores como John Resig, Anne van Kesteren, Gareth Rushgrove o Roc (de mozillazine) que han tachado la iniciativa de inútil y perjudical para el desarrollo web en general. Aunque aún es una propuesta la cosa promete y seguro que este tema va a dar mucho que hablar en los proximos meses.

Personalmente creo que deberíamos asumir que todas las páginas deben ser estandares y nada tener un interruptor para hacer las cosas más fáciles. Está claro que un cambio así podría ser demasiado drástico y hacer añicos la Internet que conocemos, pero lo que no podemos hacer es seguir dejando en manos de los desarrolladores la elección de tener un sitio flexible o estandar.

Nada más levantarme, la primera en la frente!! Al abrir el Google Reader veo esta noticia en Ajaxian, en la que informan que Internet Explorer 8, la versión interna de Microsoft, ha pasado el Acid2 Test. La prueba estrella de WebStandars. 

Navegadores como Opera, Firefox 3.0 ya forman parte de la poco extensa lista de privilegiados capaces de pasar el famoso test con un aprobado. Ahora Internet Explorer, el más alejado a estos en cuanto a validación de estandares, se está abriendo camino en esa dirección. Y esto beneficiará a todo el mundo haciendonos entrar, poco a poco, en un mundo más «estandar».