Hace mucho tiempo leí este artículo y si lo dejé marcado para traducirlo en algún momento es porque realmente vale la pena. Además, recordé haberle prometido a Gato y Doliaku colaborar con PuroCSS. Intenté ingresar al sitio pero no pude, pero de todas formas publico acá.

Notas de traducción

• El artículo fue traducido con el permiso expreso y por escrito (en un e-mail) de su autor: Emil Stenström
• No se me ocurre cómo traducir la palabra layout y que quede más o menos decente
• Artículo Original: Levels of CSS knowledge

La traducción

Como ya se habrán dado cuenta estoy muy a favor de los estándares web. Los estándares actuales comúnmente aceptados son: (X)HTML para la estructura de una página, CSS para el diseño y Javascript para los comportamientos. HTML es bastante conocido ahora, ha estado presente desde los comienzos de la web y hay tutoriales para comenzar por todos lados. CSS está comenzado a tomar velocidad, las grandes compañías están cambiando sus sitios a layouts basados en CSS y los círculos de desarrollo web de la blogósfera influyen a cada vez más gente.

Cuando se promueven los estándares web, como muchos de nosotros hacemos, se conversa con mucha gente. Si se lo promueve en una sala de chat en vivo como #CSS en EFNet se hace más claro todavía: existen muchos niveles de conocimiento de CSS allí afuera. Este artículo enumerará algunos de esos niveles así como una evaluación de cómo cada uno de estos tipos de desarrolladores afectarán la web. Aquí vamos:

Nivel 0: “¿CSS? ¿Qué juego multijugador es ese?”

Esta gente probablemente jamás ha hecho una página web en su vida. Si lo hicieran, sería puro HTML y no comprenderían lo que estaban haciendo. Recibimos algunas de estas personas en #CSS, no porque quieran comenzar a aprender sino porque creen haber llegado a otro canal, normalmente buscando CS:S (Counter Strike: Source). No hay que preocuparse por esta gente ya que probablemente no hagan muchas páginas web reduciendo al mínimo el daño que puedan causar.

Nivel 1: “Si, a veces lo uso para sacar el subrayado a los vínculos”

A diferencia del Nivel 0, la gente en este nivel de hecho sabe HTML básico. Probablemente lo aprendieron hace 5 años al menos e hicieron un par de sitios simples. Utilizan muy poco CSS, sólamente cuando necesitan hacer cosas simples y sólo aquellas que no se puede hacer con HTML como remover subrayados o setear la altura de una línea (¡Ni siquiera intenten hacerlo con HTML!). Si bien este grupo podría proveer algunos sitios con código realmente malo, rara vez tienen uno de importancia con muchas visitas. Esto significa que tampoco provocarán mucho daño.

Nivel 2: “No, no me gustan los divs; es mucho más sencillo trabajar con tablas”

En lugar de sólo jugar con HTML, como aquellos de Nivel 1, algunos continuaron la travesía. Se especializaron en tablas HTML y las utilizaron para hacer que las cosas se vieran como ellos querían. En algún punto antes de finalizar la maestría en HTML dejaron de buscar nuevas formas de trabajar. Escucharon sobre algunos que “utilizaban divs para diseñar sus páginas” e inclusive se tomaron un tiempo en día para intentar aprender qué era eso de lo que tanto se decía. Después de unas horas de no conseguirlo se rindieron y volvieron a la tierra familiar de layouts con tablas, y allí se quedaron. Muchos conocen la sintáxis de CSS y algunas veces inclusive un poco más pero creen que es demasiado complicado y mal soportado para reemplazar las tablas.

¡Cuidado! Esta es gente peligrosa, algunos incluso webmasters de sitios de grandes corporaciones. Como están en el ambiente desde hace tiempo muchos son líderes de los departamentos a los que pertenecen. Este es el grupo más importante al que debemos evangelizar, y si lo hacemos realmente será de gran importancia para la web. Concentra en esta gente todos tus ejércitos estándar.

Nivel 3: “Si, escuché que es bueno, pero no puedo usarlo por…”

Si bien aquellos en este grupo aún no utilizan CSS para posicionar elementos, conocen un poco de CSS y a lo mejor escucharon buenas cosas al respecto. Han intentado hacer layouts simples y a algunos inclusive les gustó cómo se siente trabajar con CSS. El problema es que existe algo que los detiene. A lo mejor tienen un jefe de Nivel 2, a lo mejor su sitio web necesita visualizarse en Netscape 4, pueden existir muchas razones distintas, pero siempre hay algo en el camino.

Esta gente necesita saber que, si bien CSS no funciona en todos lados, eso no es el fin del mundo. Viejos navegadores continuarán recibiendo todo el contenido, sólo el puro contenido. En lugar de a ellos, se llegará a una nueva audiencia con beneficios de accesibilidad y usabilidad, navegadores más nuevos tendrán una mejor experiencia y el sitio podría volverse más sencillo de modificar (lo que conllevará más contenido). Dile éso a la gente de este grupo. Si no se tiene suerte, no son ellos los que toman las decisiones; pero en ese caso, sus influencias en los jefes de Nivel 2 valdrán la pena.

Nivel 4: “¿CSS? ¡Oh! Si, utilizo divs para todos mis layouts”

No es raro que esta gente sólo utilice divs en sus sitios. Cada parte de sus páginas tiene un div, frecuentemente con un id detalladamente ideado (#linearojaarriba o inclusive #f5_c7 donde f es fila y c columna), y la posición de sus divs son absolutas cuidadas al pixel. El resultado se ve bien, e inclusive valida como XHTML 1.1 pero no se han percatado que perdieron la mayoría de los beneficios de CSS. Estas páginas son terribles cuando tienen que ser interpretadas por un lector de pantallas. Igual con algunos navegadores viejos que no soportan CSS, no conseguirán el contenido… recibirán un bloque enorme de texto. Cuando se utilizan malos ids y nombres de clase se pierde la posibilidad de cambiar el layour: si se quiere cambiar una línea roja por una negra se necesitaráb cambiar todos los documentos HTML (que pueden ser cientos). No caigas en la trampa de decirles que son estúpidos o que busquen “css” en google, saben que son inteligentes y, como si fuese poco, aprendieron CSS de google. Diles exactamente qué es lo que puede mejorarse en sus sitios. Diles cuáles son los beneficios. Mantente tranquilo y diles el porqué.

La gente de Nivel 4 producen sitios que son relativamente malos. El daño es reducido sin embargo, ya que están abiertos a nuevas ideas. Después de todo, no fue hace mucho tiempo que consiguieron aprender y comenzar a usar CSS.

Alguna de las razones por las que la gente piensa de esta forma es por lo que los editores WYSIWYG están haciendo. La mayoría de dichos editores producen código terrible sólo con divs; pero estoy escuchando que hay mejoras graduales en este tema. Eso es bueno y esperemos que ayude a la gente de Nivel 4 crecer hacia los siguientes niveles.

Nivel 5: “Uso CSS para los diseños, es mejor que las tablas porque…”

Luego de mucho leer, hablar con gente y pensar, la mayoría llega a nivel 5. Este es el punto en el que se puede utilizar CSS y saber porqué es mejor. Alguna gente en este nivel tiene problemas menores en los sitios que desarrolla pero no es nada serio. Cuando se les pregunta pueden defender su postura de separar la estructura del diseño y decir que es buena y han trabajado lo suficiente con CSS como para saber los inconvenientes más usuales. Adivino que la mayoría de los lectores de este artículo pertenecen a este nivel y creo que yo lo soy también. Pero esto no es todo lo que podemos lograr…

Nivel 6: “¿Qué versión de CSS? Sí, ¿no leíste mi libro sobre… ?”

Para algunos, el conocer cómo y porqué no es suficiente. Esta gente apunta a mejorar el uso de CSS y publican excelentes artículos sobre nuevas formas de utilizarlo. Están constantemente revisando las necesidades básicas que CSS debe cubrir y atacan problemas desde nuevos ángulos, resultando por lo general en grandes artículos. Algunos inclusive han leído la especificación CSS de la W3C completa y seguramente saben qué porciones de ella están soportadas por cada navegador. Son lo que todo novato quiere ser y hacen grandes cosas en la web con su influencia. Muchos trabajan con el Proyecto de Estándares Web. Si alguna vez encuentras un error en sus sitios, seguramente hay una razón para el mismo. Pregúntales y te dirán cuál.

La respuesta empieza medio filosófica: la blogósfera se alimenta constantemente de memes que están dando vueltas por todos lados. Por fin creo que una vez inventaron uno que valía la pena. La idea de todo esto es fomentar los estándares. Mostrarle a tu público cuán accesible es tu sitio aún sin una hoja de estilos, el HTML pelado y desnudo.

¿Para qué?

Esto puede parecer inútil a algunos. Otros dirán que con Flash estas cosas no pasan. Pero yo les digo que así como lo ven es como lo van a ver en una Lynx corriendo en una XT con linux en disquette, en un Opera, Firefox, IE, en el navegador de un celular, una palm o lo que se les ocurra. Y el usuario va a poder usarlo tranquilamente por más que no tenga la última tecnología o no la quiera usar. Lo que es más, una persona con problemas de visión seguramente no ve cuán lindo queda tu sitio con colorcitos; lo prefiere así para que su programa se lo lea en voz alta.

Esto también demuestra para qué se hizo CSS. El HTML no es un lenguaje de presentación, sólo le da una base a Internet para poder inter-relacionarse. Todo el resto de arriba son adornos.

Si está hecho con estándares: cualquiera lo va a poder usar.

La locura es obra de Dustin Díaz. Es sólo un día al año, el 5 de Abril, en el que estamos seguros que todos nuestros usuarios van a estar viendo nuestro sitio igualito sin importar si lo están imprimiendo, si perdieron la visión, en su gadget favorito o en un proyector.

Demostremos que el contenido sigue siendo lo importante

¿Cómo?

Hay varias formas, todo depende. La más sencilla es simplemente comentar la línea de la hoja de estilos. Sin embargo vas a necesitar hacer esto todos los años (si tu locura da para tanto). Para eso existen otras soluciones:

WordPress

En el archivo headers.php (que se encuentra en el directorio wp-content/themes/nombre_del_theme/) tienen que cambiar la línea:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />

por el código:

<?php
$DustinsNakedDay_isToday = (date('md')=='0405');
$DustinsNakedDay_allPages = true; // false for just the home page
$DustinsNakedDay_getNaked = ($DustinsNakedDay_isToday && (is_home() || $DustinsNakedDay_allPages));
if(!$DustinsNakedDay_getNaked) { ?>
<link rel="stylesheet" href="" type="text/css" media="screen" />
<?php } ?>

Simple PHP

Agregás el código siguiente y luego utilizás la función como guarda de un if que incluye el código de tus hojas de estilo:

<?php
function is_naked_day() {
$start = date('U', mktime(-12,0,0,04,05,date('Y')));
$end = date('U', mktime(36,0,0,04,05,date('Y')));
$z = date('Z') * -1;
$now = time() + $z;
if ( $now >= $start && $now <= $end ) {
return true;
}
else {
return false;
}
}
?>

Nótese que esta función devolverá que es el día de desnudos si en algún lugar del mundo todavía es 5 de Abril.

El que se quiera prender, bienvenido sea. El que no, allá él.

Notas de traducción

• El artículo fue traducido sin el consentimiento explícito del autor por lo que puede ser modificado y/o eliminado eventualmente (se le informó al autor de la misma sinembargo)
• Los vínculos fueron mantenidos del artículo original por lo que seguramente estarán en inglés
• Las notas de traducción fueron agregadas entre corchetes (“[" y "]“)
• Via: Two Mad Geeks
• Artículo Original: 55 reasons to design in XHTML/CSS

La traducción

1. Obtienes links desde sitios de muestra como zengarden, stylegala, cssimport y cssbeauty
2. No necesitas gastar más ideas en decidir los estilos del código del documento (mayúsculas o minúsculas, comillas o no en los atributos)
3. No necesitas desperdiciar tiempo pensando en qué etiquetas deberían cerrarse y cuáles podrían (o deberían) dejarse sin cerrar
4. “Ayudas” a los buscadores para que entreguen contenidos más relevantes al utilizar código semántico
5. Puedes ahorrar en costos de ancho de banda y los visitantes las verán más rápido al hacer páginas más livianas
6. Será más sencillo actualizar a XHTML 2.0 que nos proveerá de más herramientas semánticas
7. Con suficiente práctica, la codificación de una página se torna mucho más sencilla y rápida que cualquier grupo de tags table/tr/td
8. Cuando la codificación es más rápida, puedes dedicar más tiempo en pensar acerca de la experiencia de usuario
9. Pensar acerca de la semántica de un documento te ayuda a tomar decisiones sobre el diseño y la arquitectura de la información
10. Puedes hacer un sitio modelo rápidamente para probrar la arquitectura de la información y agregar lo estético más adelante sólo con pequeños cambios de código
11. Se puede hacer el diseño luego de que la mayor parte de la base está hecha con ayuda del cliente (o jefe) para pensar de forma realista cuánto trabajo queda aún por hacer
12. Es posible poner links directos al contenido de tus páginas (comparado con Flash)
13. Los botones del navegador como el tamaño del texto y atrás/adelante funcionan (comparado con Flash)
14. Rediseños y alineaciones en todo el sitio son más simples
15. Es más simple hacer cambios de último momento a los diseños
16. El código limpio facilita o vuelve innecesario la construcción de un CMS completo
17. El código limpio facilita el que se agregue más gente al proyecto
18. Se puede hacer la base casi totalmente independiente del diseño final, por parte de dos personas completamente diferentes
19. Se cuentan con muchas formas de jugar con el código intentando optimizarlo para los buscadores sin afectar la cara visible
20. Tienes control total de los formatos de impresión de tus páginas
21. Tus sitios son automáticamente accesibles por toda clase de navegadores
22. La promoción de los estándares web te ayudará con tu trabajo futuro, sin necesidad de codificar distinto para cada navegador
23. Con todos los elementos cerrados, el código es más limpio
24. Código bien formado asegura que el sitio funcione en más navegadores
25. Código bien formado ayudará a los programadores de navegadores dándole más tiempo para desarrollar funcionalidades útiles en lugar de motores que muestren y entiendan código roto
26. Tus sitios funcionarán en navegadores futuros
27. Tus sitios funcionarán en dispositivos móviles (y otros nuevos)
28. Aprenderás las bases de XML, que sirve para muchas otras cosas
29. Los archivos CSS son guardados en la caché del navegador para agilizar la carga y minimizar el uso de ancho de banda
30. Tus documentos serán fácilmente conversibles desde hacia otro formato utilizando XSLT
31. El pensar semánticamente te hace pensar más acerca del contenido
32. Aprender semántica te hace aprecial la organización y escribir tus otros documentos (inclusive e-mails) de forma más organizada
33. Puedes escribir nuevas tecnologías en tu CV o portfolio
34. Los navegadores modernos visualizan más rápido un documento válido
35. Te sentirás mejor contigo mismo al hacer sitios “de la forma correcta
36. Ellos lo hacen: Dan Cederholm, Jeffrey Zeldman, Jason Santa Maria, Shaun Inman, Cameron Moll, Douglas Bowman, Dave Shea…
37. Pertenecerás a un “movimiento”, haciendo buenos contactos, etc.
38. Aprenderás a apreciar nuevsos navegadores que provocan competencia y, después, mejores navegadores
39. No existe más la etiqueta blink
40. La codificación estricta te enseña a ver más rápido los errores
41. Puedes intentar hacer dinero escribiendo un libro acerca de esto
42. Hay más oportunidades de trabajo si conoces estas nuevas formas
43. Aprendes a entender mejor cómo funciona un navegador
44. Puedes usar hacks y técnicas con nombres cool como “seamos buenos con Opera”
45. Pueden comenzar a importarte los meta-datos, tipos de documento y tipos de caracteres
46. Con más gente produciendo páginas más livianas, la cantidad de datos moviéndose en toda la red será menor y todas las conexiones serán más rápidas
47. XHTML tiene un nombre más cool que HTML
48. Existe más gente pensando sobre las ventajas, desventajas y trucos de código de XHTML, lo que produce una base de aprendizaje más grande
49. Puedes utilizar, básicamente, la misma plantilla de código para muchos sitios diferentes
50. Aprender a leer y escribir [código] rápidamente posibilita el uso de herramientas más económicas (notepad)
51. Google sabe que:
    • 4,380,000 xhtml better than html > 4,370,000 html better than xhtml [en español ambas búsquedas devuelve 1.010.000 resultados]
    • 206 “xhtml is better than html” > 87 “html is better than xhtml” [en español es 1 a 0 sólamente]
    • 2,130,000 xhtml sucks < 10,300,000 html sucks
52. Cuando todos los navegadores comiencen a entender el MIME-type (xml) correctamente, no hará falta convertir todos los sitios de HTML sólo para ajustarse al MIME correcto
53. Meintras más gente utilice XHTML, nos aseguramos que en el futuro IE necesitará entender el MIME-type correcto
54. La accesibilidad es reforzada al requerir atributos Alt para las imágenes
55. Simplemente no hay tantas razones para utilizar HTML o completamente Flash en su lugar

No podía creer que mi adorado Firefox no pasara la prueba. Así que la busqué e intenté renderizarla. No está tan mal como he visto en algunos navegadores; pero deja que desear. Para mi consuelo encontré la explicación de que Acid2 fue desarrollado en un momento en el que Firefox no se podía concentrar en este test pero que estaría prometido para la versión 3 del navegador ya que significaría modificaciones importantes al motor de renderización: Gecko… o algo así.

No conforme con esto decidí investigar un poco más y nada mejor para eso que la explicación del test en sí. La información está toda en inglés así que me dispuse a traducir la introducción de la explicación del test.

Notas de Traducción

• El artículo no fue traducido completo por falta de tiempo. Es muy largo. Sin embargo, si a muchos les interesa puedo hacer un esfuercito por traducirlo completo.
• Por lo que entiendo esta autorización está autorizada. La parte ‘legal’ en el sitio original condena cualquier uso o abuso con fines que no sean “la educación y/o la promoción de los estándares en todas la formas de desarrollo disponible en la web”. Si alguien piensa que es una malinterpretación de lo que dice que me lo haga saber mediante comentarios y vemos qué hacemos
• Los comentarios de traducción se encuentran entre corchetes (“[" y "]“)
• Los enlaces se mantuvieron como en el artículo original por lo que seguramente los llevarán a un sitio en inglés
• Necesito saber si a alguien se le ocurre cómo traducir “data URLs” y “layout”. Los comentarios están para eso
• Artículo original: Acid2: The Guided Tour

La traducción

Acid2 es una página de prueba para navegadores web publicada por The Web Standards Project (WaSP: Poyecto de Estándares Web). Fue escrita para ayudar a los desarrolladores de navegadores a asegurarse que sus productos soporten conrrectamente las funcionalidades que los diseñadores web querrían que utilizaran. Esas funcionalidades son parte de los estándares existentes pero que no han sido soportadas conjuntamente por los navegadores populares. Acid2 intenta cambiar esto desafiando a los navegadores a renderizar Acid2 correctamente antes de su distribución.

Acid2 es una página web compleja. Utiliza funcionalidades que no son usadas comúnmente debido a falta de soporte y agrupa demasiadas pruebas en una sola página. El objetivo fue simplificar a los usuarios y desarrolladores si un navegador pasa la prueba. Si lo hace, una cara felíz [a la derecha de este texto en el original] aparecerá. Si algo está mal, la cara se verá distorsionada y/o parcialmente roja.

El propósito de este documento es explicar cómo funciona Acid2. El código tras Acid2 es peculiar en su intento de, en una sóla página, probar muchas funcionalidades diferentes. No pensamos ni recomendamos que páginas web normales sean escritas de esta manera, pero es adecuado para una página de prueba. A primera vista, el código fuente es complicado de comprender. Esta guía asume una compresión técnica de HTML, CSS y PNG.

Nota: Acid2 utiliza data URLs [URLs de datos] extensivamente. Para permitir a desarrolladores que aún no soporten data URLs se publicó una versión de Acid2 sin data URLs.

¿Qué estamos probando?

Acid2 prueba funcionalidades que han sido pedidas por diseñadores web. Todo lo que Acid2 prueba está especificado en algún estándar web, pero no todos los estándares web han sido probados. Acid2 no garantiza conformidad con ninguna especificación. Luego pensarlo cuidadosamente, seleccionamos y probamos funcionalidades que consideramos más importantes para el futuro de la web. Si bien Acid2 fue inspirado por el anuncio de IE7 de parte de Microsoft, no está orientado a ningún navegador específico. Creemos que Acid2 revelará problemas en todos los navegadores actuales.

Acid2 asume un soporte básico para HTML4, CSS1, PNG y data URLs. Los primeros tres items de la lista son incluídos por razones obvias: son la columna vertebral de los contenidos web estándar. Las data URLs son descriptas en HTML4 pero son poco utilizadas debido a falta de soporte. Creemos que las data URLs son convenientes y útiles para los diseñadores web y fáciles de agregar a los navegadores. Lo que es más, Acid2 asume que el navegador utiliza una hoja de estilos por defecto con valores comunes. Por ejemplo, se asume que todos los elementos ‘div’ poseen ‘display: block’. Finalmente, la prueba asume una densidad de píxels de 96 ppi [píxeles por pulgada] como indica el Last Call Working Draft [Esbozo de Trabajo de Última Llamada: término referente a uno de los pasos para poder desarrollar un estándar web] de CSS 2.1. Para los navegadores que soporten aumento de tipos [fuentes] también se asume un aumento por defecto del 100%. La lista a continuación provee de algunas de las funcionalidades más importantes que son probadas:

• PNGs transparentes: Los ojos están codificados como PNGs transparentes.
• El elemento object: los ojos de la cara están agregados como un elemento object. La posibilidad de utilizar object (que puede tener contenido alternativo) es uno de los pedidos más antiguos de los diseñadores web.
• Posicionamiento absoluto, relativo y fijo: la capacidad de posicionar elementos precisamente es importante para layouts avanzados.
• Modelo de cajas: el test Acid original se enfocaba en el modelo de cajas de CSS. Acid2 continúa con esta tradición probando ‘height’, ‘width’, ‘max-width’, ‘min-width’, ‘max-height’ y ‘min-height’
• Tablas CSS: No hay nada de malo con layouts con tablas. Es un modelo poderoso que tiene sentido en pantallas más grandes. Sin embargo, la codificación de una tabla es propensa a errores ya que ata el contenido a la pantalla. Por ello, la capacidad de especificar layouts con tablas en CSS es importante.
• Márgenes: CSS define algoritmos precisos para el cálculo de los márgenes alrededor de los elementos.
• Contenido generado: la capacidad de añadir decoraciones y anotaciones a páginas web sin modificar el código es algo pedido desde hace tiempo por los autores.
• Parseo de CSS: Acid2 incluye un número de líneas de código CSS erróneo que deberían de ser ignoradas por un navegador que pase el test.
• Orden de dinujo: se prueba que contenido solapado sea dibujado en el orden correcto. Esto no es una funcionalidad en sí pero requiere de otras funcionalidades para funcionar correctamente.
• Efectos de hover [cuando el mouse pasa por sobre un elemento]: Uno de los elementos de la cara cambia de color cuando se pasa el cursor sobre él. ¿Cuál es?

Nótese que Acid2 es renderizado de modo estándar. Esto es, la página de prueba incluye un tipo de documento (DOCTYPE) que indica que el navegador debería tratar la página acorde a los estándares. Los desarrolladores que no deseen hacer cambios en su forma de renderizar documentos antiguos pueden continuar con su comportamiento en lo que se llama ‘modo peculiar’.

¿Qué es lo que debe aparecer?

Acid2, cuando es renderizado correctamente, consiste de una línea de texto (“Hello World” [Hola Mundo]) y una grilla cuadrada compuesta por 14×14 cuadrados contenida en un bloque en el que se puede observar una cara sonriente. Cada cuadrado es de 12px de alto por 12px de ancho. La cara tiene un fondo amarillo con un borde negro.