En el post Todos los IE en una misma casa os presentábamos un programa con el que podíamos ver la apariencia de nuestras páginas en diferentes versiones de Internet Explorer.
Pues Julen me pasa la referencia de una página desde la que podemos hacer lo mismo pero sin necesidad de tener nada instalado: IE NetRenderer. Desde aquí nos permiten comprobar cómo nuestras páginas son “renderizadas” por Internet Explorer 7, 6 ó 5.5.
Ventajas del servicio:
* Todo se hace on-line, sin tener que depender de ningún software (sólo de nuestra conexión 😉 ).
* En la parte superior de la captura que hacen de nuestra web, nos ponen unas marcas indicándonos hasta dónde llegaría la visualización dependiendo de la configuración de pantalla del usuario (800×600 ó 1024X768).
* Nos permiten comprobar las diferencias de visualización entre IE 7 e IE6. Aquí podéis ver un ejemplo de este blog (pinchar sobre la imagen):
Desventajas del servicio:
* No nos muestran toda la web (nos quedaremos sin saber cómo queda la parte inferior)
* Sólo podemos probar con ese navegador… No estaría mal poder hacerlo también con Firefox, Safari, Opera, Konqueror, etc. (por pedir, que no quede 😉 )
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
Seguimos con aquello de que, dependiendo del navegador, las hojas de estilo se verán de forma diferente.
Para comprender mejor este “fenómeno” es recomendable la siguiente lectura en el blog de Damián en el que nos explica que cada navegador tiene una hoja de estilos por defecto. Es decir, que si nosotros no definimos ciertas propiedades, esas tomarán el valor que tenga esa hoja. Y claro está, cada navegador tiene valores diferentes (para hacernos la vida un poco “más fácil”…).
Al comenzar un nuevo sitio, y al aplicar los primeros estilos a un documento XHTML, los parámetros que guían la forma en que se muestran las páginas no son los mismos. Es decir, no es cierto que todos los parámetros de una hoja de estilos estén en los mismos valores en todos los navegadores, ni siquiera están todos en 0. Cada navegador tiene unos ciertos valores, que pueden variar de manera especial, dependiendo del navegador y del sistema.
Durante muchos posts hemos reiterado la importancia, a la hora de diseñar una web, de comprobar que se visualiza bien en la mayoría de navegadores.
Echando un vistazo a esta gráfica de nuestras estadísticas, podemos comprobar, que entre los navegadores que usan nuestros lectores hay de todo un poco:
Por tanto, deberíamos cuidar a todos con el mismo mimo.
El problema viene cuando, gracias a las actualizaciones automáticas de nuestro querido Windows XP, nuestro nuevo navegador pasa a ser el Internet Explorer 7. Ahora ya no podremos comprobar cómo se ven las páginas en el IE6 (y os puedo prometer que la interpretación del CSS es muy distinta).
Pues gracias a MultipleIEs podremos tener instaladas diferentes versiones del IE (3.0, 4.01, 5.01, 5.5, 6.0) sin que se peguen entre ellas.
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
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 browsershotsuna 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:
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…
Como últimamente una no hace más que procrastinar, me he agenciado un fichaje para este blog. Se trata de Ángel Luis a.ka. GeL/T0. Y quien mejor que él mismo para presentarse.
Hi, my name is Ángel Luis, I’m from…
Soy un ubetense que se ha recorrido medio España para acabar en Madrid. Por las mañanas soy un simple currito contratado como desarrollador de php, en una empresa de ingeniería civil, donde hasta hace unos años, el bic naranja era lo máximo en tecnología.
Por las tardes paso a ser un simple estudiante de matemáticas de la UCM, que hasta hace unos años pasaba bastante desapercibido; que alegría que dan las asociaciones de usuarios. Y ahora se pelea cada año por intentar acabar la carrera interminable.
Siempre he sido muy curioso, me ha encantado la informática desde que llegó el primer 8086 a mi casa, me gusta saber de todo un poco y trastear con todo. Y me ha venido de perlas, ya que entré a mi empresa sin tener mucha idea de CSS, pero bueno, eso era cosa del diseñador web, hasta que decidió largarse, y como suelen decir, «a la fuerza ahorcan», ahora se podría decir que a parte de desarrollar en php, también hago mis pinitos con el css.
Mis conocimientos sobre CSS son muy escasos, aunque intento que cada día la cosa vaya a más, de ahí que me quiera unir a este blog, para intentar sacar algo de provecho y echar un cable a Loretahur en todo lo que pueda.
Que cuantos más mejor!
Pues eso. Ya contamos con un nuevo profesor y aprendiz de CSS. Bienvenido Angelito 😉
