GeL/T0 – Aprendiendo CSS

Bueno, después de un tiempo de inactividad (creo que Loretahur está peor que yo, si es que esto de apuntarnos a tantas cosas…) volvemos con un post algo más “técnico” para intentar resolver una de las dudas que salieron al principo de este blog.

Y es que no hace mucho Loretahur escribió un post sobre las diversas formas de añadir los estilos a una página web, a partir del cual, entre los comentarios, volvió a resurgir el famoso debate entre @import y links.

Bueno, siempre que salga una duda de usabilidad o de dualidad entre varias opciones, lo mejor sería recurrir al gran oráculo. Los del w3c (no, google no siempre es el gran oráculo) y escuchándolos resulta que lo recomendable para linkar una página de estilos desde una página web es usar el links siempre frente el @import*.

Los del w3c han hablado, nosotros aceptamos.

Con lo cual, todo resuelto. Post acabado.

Lo que pasa es que, como somos buenos estudiantes, y no tenemos por que creer nunca a nadie a pies juntillas, al menos, hasta que nos de razones de peso, pues, ahora si, haciendo uso de google, buscamos las posibles ventajas/desventajas de ambos para comprender porque usar link frente a @import (la mayoría son meramente subjetivas, pero claro, dentro de la accesibilidad web, que no es subjetivo?).

* Ciertos navegadores no aceptan la sentencia @import: Es, por ejemplo el caso de cualquier versión del IExplorer anterior a 4.0. Aunque muchos diseñadores lo suelen utilizar para discriminar navegadores web antiguos, no es una técnica demasiado buena.
* @import, siempre debe ir al principio del código: Ya sea dentro de las etiquetas

o en una hoja externa, @import siempre debería ir al principio, lo cual fija bastante el código (aunque es cierto que solo debería ir dentro de los heads de la web ).
* En contra de lo que se comentaba en el post anterior, para lograr una mejor web semántica, es mejor el uso de link ya que aporta más información al navegador web que debe recibir la información y tratarla. Aparte de que para incluir @import en la página web, debes añadirla mediante las etiquetas

, añadiendo estilos dentro de la página web, algo no muy recomendable. Lo cual nos lleva al siguiente punto.
* Para incluir @import en una hoja, debes crear una sección

dentro del html. Lo cual hace añadir más código del que posiblemente sea necesario.
* @import está pensado para incluirse dentro de las hojas de estilo, su uso es poder enlazar hojas de estilo dentro de hojas de estilo. Para enlazar cualquier archivos externos dentro de html existe el link.
* Técnicamente, @import “embebe” el código enlazado dentro de la página web, sin embargo, mediante los navegadores tratan el código como externo sin introducirlo en la página. (Esto lo leí hace bastante tiempo, actualmente no se si seguirá siendo igual, o no)

Bueno, después de estas razones, creo que deberíamos aceptar las preferencias de la W3C sobre el uso de links. Aunque sin descartar el uso de @import!

* Y como he averiguado eso?? Donde lo han dicho?? Seguro que por algún lado encontraríais un artículo técnico al respecto, pero yo he sido más vago y si miráis el código de w3.org resulta que no hay ningún @import y si muchos

Si el médico antes de operar a su lado pone una mesa con todo el material quirúrgico necesario. Si al ponernos a estudiar, sacamos el boli, el típex, el lápiz, la goma, el subrayador… Entonces, por qué al diseñar webs, nos ponemos delante del bloc de notas y nos quedamos tan anchos??

Así que, continuando con el post de Loretahur sobre libros, ahora vamos a ver que es necesario, y que no, para trabajar con CSS.

Espero que me echéis una mano para completar la lista.

Empezaremos por lo que no es bueno usar. Y esos pequeños errores de newbie.

FrontPage , si, ese maravilloso programa de la factoría Redmond es una de las mayores armas contra el diseño web accesible. No entiende para nada el uso de estilos, css y accesibilidad web, llena todo con incompresibles tablas y acaba generando un código enorme imposible de tratar. Como la mayoría de editores webs WYSWYG, no se debería usar nunca.
Desarrollar usando un solo navegador. Y más si solo desarrollas usando el navegador de la misma gente de Redmon, el IE. Cada navegador interpreta muchos comandos a su manera, de ahí, que si solo trabajas usando un navegador, obligas a que se vea bien solo con un navegador.
Flash, cuanto menos mejor. Y siempre que se ponga tendría que existir una opción sin flash con el mismo contenido. Los que uséis GNU/Linux sabréis a que me refiero. Tener en cuenta, que quitando innecesarias animaciones, el uso de flash puede ser suplido fácilmente con un buen diseño web.

Siempre hay cosas que aunque no son muy recomendables usar, se pueden tolerar mejor.

Dreamweaver: Ese «maravilloso» programa adorado por mil un «desarrolladores web». Al igual que FP, crea bastante código innecesario. Acostumbra, aunque trata algo mejor el tema de las CSS, al uso de tablas y no suele hacer mucho caso al tema de accesibilidad.
Entonces, lo mejor, picar el código a mano, como siempre, como se hace en programación. Pero, no me seáis burros, no uséis el NotePad! Existen versiones bastante superiores (además de ser libres) de editores de texto, siempre podréis probar notepad2 o notepad++ o [g/k]edit o cualquier otro editor de texto con resaltado sintáctico (claro, también vi y emacs).
Evitar los hacks, cuando algo no se puede hacer, el uso de hacks para solucionarlo, a la larga siempre puede dar bastantes dolores de cabeza, y sino, preguntarle a los de los hacks para el IE6 ahora que está el IE7.

Y ahora si, lo que todos deberíamos tener en nuestro equipo:

IDE: Si vas a realizar más de una página de forma esporádica, más vale que te hagas con un buen ide que te ayude a organizarte y ahorrate algo de curro. Algunos, por ejemplo:
- PHPEclipse: Que no es más que el Eclipse de toda la vida con un plugin para desarrollo en PHP, tienes plugins para HTML también, pero vamos, como normalmente lo que hago es picar PHP, pues este es el que uso :-p
- Bluefish
- Screem
- Quanta+
Navegadores: Cuantos más mejor. Firefox/Iceweasel, IE5, IE6, IE7 (y es que hay mucha diferencia entre ellos), Opera, Safari, … en cuantos más navegadores los probéis mejor, aunque en principio con FF y con IE6/7 sería suficiente ya que el resto, en la mayoría de los casos, se asemejan bastante al FF.
Otra forma es comprobarlo en web. Un buen sitio para ellos (y gratis) es browsershots una aplicación online que te permite comprobar el diseño en una amplia serie de navegadores y resoluciones.
Extensiones: Hay mil extensiones útiles para FF, pero la primordial es webdeveloper
Hay mil páginas en internet que pueden ayudar bastante, otras tantas de las que podemos sacar trucos de sus propios diseños y otras de obligada referencia, entre ellas nos encontramos, por ejemplo:
- W3Schools: La mejor guía de referencia en la web. Para FF existe la posibilidad de incorporarlo a su buscador.
- Validadores web de CSS y HTML del W3C.
- La misma web del W3C (también en castellano), sus especificaciones y su guia de referencia rápida del CSS2.
- Validadores de accesibilidad automáticos como T.A.W. Aunque su información no es que sea «ley», si aportan mucha ayuda.
- Páginas sobre colores como Easyrgb y la utilidad de contraste de colores de Juicy Studio. Siempre pueden servir de ayuda a la hora de encontrar colores seguros (y lo digo por experiencia).
- Y como no google! Siempre que tengáis dudas, pasaros por él y también por forosdelweb. Seguramente os resolverá la mayoría de ellas.
Programas de retoque y diseño fotográfico. Aquí, si queréis pagar, podéis usar Adobe Photoshop (la versión más «económica» supera los 200 euros). Pero vamos, yo recomendaría Gimp e Inkscape (aunque no tenga ni la menor idéa de ninguno de los tres 😉 )

Bueno, creo que ya hay bastante material para empezar a diseñar…