El Cubo de Rubik y la escala Pantone

La escala Pantone es una de las escalas cromáticas más conocidas del mundo, sobre todo por diseñadores, que esta vez ha sido usada de una forma muy original. Se trata de una idea del diseñador industrial argentino Ignacio Pilotto, montando el cubo de rubik usando la escala cromática de Pantone en lugar de los colores planos.

Se trata de una idea sin intenciones comerciales, aunque con ideas así las intenciones son lo de menos al final.

Comercial o no comercial, ¡me pido uno!

Etiquetas: Diseño

Wallpaper: Noviembre

Los fondos del escritorio del pc, o wallpapers, son algo para mi imprescindible. Voy cambiando el aspecto del ordenador de vez en cuando, por aquello de variar y porque en según que épocas necesitas un ambiente más sobrio, más compacto, y a veces colorido y vivaz. A dia de hoy, juzgad vosotros: este es mi fondo de pantalla actual:

Este fondo de pantalla, llamado “My Stash“, se lo debemos a f-l-A-r-k, un artista de fractales estadounidense que publica en DevianArt. Lo encontré en una recopilación, totalmente recomendable, que hicieron en Noupe de Fondos de escritorio creativos en alta resolución sólo para diseñadores. Echadle un vistazo, vale la pena.

Etiquetas: Diseño, wallpaper

¿Código limpio? Sí, por favor.

Para todos aquellos que hemos programado o tocado código de cualquier tipo, debería ser una prioridad mantener el código limpio, además de documentado y comentado debidamente (sobretodo en hojas de estilos esto es más que necesario para estructurar el archivo).

Esta limpieza de código es automática con un buen estilo de programación y diseño siguiendo ciertos consejos, que siendo justos son a menudo específicos para cada lenguaje y tecnología.

En concreto hoy tengo doce consejos básicos para mantener nuestro código HTML y CSS limpio, cortesía de Smashing Magazine. Os traduzco y explico un poco estos consejos:

1. Usar cabecera “Strict DOCTYPE”

Si vas a usar la cabecera DOCTYPE, asegúrate de hacerlo bien. No es necesario discutir si usar HTML 4.0 o XHTML 1.0: ambos ofrecen una versión estricta STRICT que nos asegurará una correción suficientemente honesta en nuestro código.

El DOCTYPE (Document type declaration- DTD) es una cabecera que la W3C recomienda usar para cada documento html. Indica tanto la referencia de como se sirve el documento ( text/html ) además de la versión del lenguaje usado para su implementación (HTML v4.1, v3.0, etc; o bien xHTML v1.0, v1.1, etc).

Existen dos tipos de DOCTYPE: Strict y Transitional. Mientras que los Strict mantienen una corrección absoluta del lenguaje (x)HTML, los Transitional permiten el uso de ciertos elementos del lenguaje ya desfasados. El problema viene aquí: se han venido usando indiscriminadamente los DTD Transitional, cuando estos no garantizan realmente la correción del texto.

Pongamos un ejemplo: uno de los elementos desfasados que los Transitional DTD permiten son las tablas. Pero pensemos con claridad: ¿para que usar tablas, si podemos maquetar en CSS lo mismo de un modo correcto?

Por esto: dejemos de usar DOCTYPE transitional, si podemos usar un DTD Strict.

2. Usemos los caracteres especiales codificados

En la cabecera de sección, lo primero que hacemos debe ser declarar la codificación de los caracteres que usaremos. Es decir, si usamos UTF8, declaremoslo con:

<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >

Del mismo modo si usasemos, por ejemplo, Unicode ISO 10646.

Igual de importante es el hecho de usar los caracteres especiales de un modo estricto. Esto es: si usamos un símbolo “&” (Ampersand se llama en inglés, en realidad una derivación de la palabra francesa “et”, es decir, “y”), deberemos usar no el simbolo por sí mismo, si no “&“. Del mismo modo, el caracter “á” sería “á“. Podemos encontrar una lista bastante completa en ascii.cl, además de un recurso imprescindible: www.ascii-code.com.

Un detalle: si incluimos en nuestro <title> alguno de estos caracteres especiales, declarad el <meta … charset:…> antes del <title>.

3. Indentación adecuada

La indentación es la acción de mover bloques de texto hacia la derecha usando espacios o tabulaciones, lo que comunmente se llama sangrado, para ordenar el código según sentencias.

Ejemplo de lo que no se debe hacer:

Y esto, como debería quedar el código, bien indentado:

Puede parecer para algunos una tontería y para otros algo obvio. El problema de todo esto es que a menudo lo dejamos de lado, tomándolo por algo sin importancia, pero la mejor forma de comprender un código de un vistazo es esta, lo cual le da una gran importancia.

4. Mantén tu CSS y Javascript fuera del archivo principal

A menudo, por rapidez y dejadez dejamos fragmentos de código CSS entre etiquetas <style> y trozos de código Javascript entre <script>. Esto hace que nuestro código quedé con parches fuera de lugar, y corrientemente, carguemos varias veces las mismas funciones o estilos, cuando podriamos cargarlos una sola vez, quedando en caché y acelerando un poco más la carga de nuestras páginas.

Por ello, la práctica más correcta es:

<LINK REL=StyleSheet HREF="style.css" TYPE="text/css" MEDIA=screen>

<script type=”text/javascript” src=”nombre.js“></script>

5. Anida las etiquetas correctamente

Las etiquetas <a> y <h1> (igualmente <h2>, <h3>, etc) suelen usarse unidas; es decir, suele verse un texto al que se aplica al mismo tiempo tanto un <a> como un <h1>. El problema es que a menudo suele verse lo siguiente:

<a href=”./”><h1>Ejemplo</h1></a>

Bien, en este ejemplo, el error es el siguiente: <a> es lo que se llama “inline element“, que quiere decir que es un elemento que solo puede contener texto, mientras que <h1> es un “block element“, es decir, un componente que puede contener y aglomerar otros elementos, no solo texto. Por tanto, incurrimos en un error de base: un <a> no podrá nunca contener un elemento, de modo que la forma claramente correcta sería:

<h1><a href=”./”>Ejemplo</a></h1>

6. Elimina los div innecesarios

Los divs, esos elementos de bloque tambien llamados capas, nos facilitan hasta el extremo la maquetación web unida con CSS. Pero, para ser exactos, a veces tambien abusamos de ellos para agrupar de alguna forma ciertos elementos de forma innecesaria.

Un artículo en CssCreator explica esta tendencia y unas buenas maneras de maquetación de forma detallada. Quizás más adelante traduzca éste y otros artículos.

7. Usa una convención de nombres mejor

Vale, el epígrafe por sí mismo no se entiende, pero es fácilmente entendible. Cuando tenemos que nombrar clases o elementos, necesitamos una convención o regla para nombrar siempre de una determinada manera nuestros elementos, y así siempre poder comprender qué significa cada nombre.

Pero a menudo caemos en un error muy extendido, y es el nombrar las cosas teniendo en cuenta el aspecto que tiene: por tamaño, por color, por tipografía. Pero este aspecto es variable, en un futuro cambiariamos los atributos de la clase y este aspecto variaría y no se correspondería con el nombre que se le ha dado. Por eso siempre hay que darle un nombre que corresponda a su estructura o finalidad dentro de la maquetación, que es algo que no variará.

Por tanto, los nombres que no debemos usar son por ejemplo: roundedBox, boldBoxText, etc. Sin embargo, nombres como sidebar, footer, mainNav, header, etc, serán correctos.

Más:

• CSS coding: semantic approach in naming convention
• CSS Naming Conventions

8. Deja la tipografía para el CSS

Sabemos que siempre debemos dar estilo a nuestro texto mediante css, al igual que la estructura. Pero lo que a veces no sabemos es que incluso el poner todo un texto en mayusculas, (“all caps” o “all capitals”lo llaman en inglés), puede y debe hacerse en CSS mediante el atributo text-transform y el valor uppercase.s

Es decir, en lugar de poner:

<h1>INICIO<h1>

Pondremos:

<h1>INICIO<h1>

y en el CSS:

h1 {

text-transform: uppercase;

}

9. Da una clase o identificador al <body>

Aplicar una clase o una identificación al <body> tiene una utilidad muy amplia en cuanto al uso de distintos estilos de contenido en distintas páginas de un mismo sitio o portal.

De este modo, se haría: <body class=�?blogLayout�?> que aplicaría a todos los div, una clase o indentificación y una serie de atributos.

Más:

• ID Your Body For Greater CSS Control and Specificity
• Case study: Re-using styles with a body class

10. Validación

Debemos mantener nuestros proyectos validados a nivel de código y deberán pasar los test de (x)HTML y de CSS que nos facilita la W3C.

Más:

• Servicio de Validación de Código del W3C
  
• Validación XHTML-CSS

11. Ordena de forma lógica

El código debe ordenarse de una forma, como digo, lógica. ¿Que sentido tendría que en el código el “footer” o pie de página, estuviera declarado antes que una barra lateral “sidebar”? Ninguno. Es por esto que debemos ordenar el código según vaya apareciendo en nuestra maquetación.

12. Haz lo que puedas

Esto es: si no sabes por donde empezar a solucionar estos problemas en páginas ya realizadas, si usas un CMS que te fuerza a tener alguna mala costumbre aplicada al código, etc, no te preocupes. Cuando se trata de aplicar este tipo de consejos a proyectos ya realizados, pensar en esto es mucho mas dificil.

Lo importante es que asumas y aprendas este tipo de consejos y en el futuro lo apliques en tus proyectos. Escribir código limpio es mucho más facil que limpiar uno ya sucio.

Por eso, ¡Cuida tu código, y aprende buenas maneras!

• Basado en el artículo en inglés de SmashingMagazine

Etiquetas: Diseño, Informática, programación

Arte Urbano de Joshua Callaghan

Joshua Callaghan es un artista urbano bastante… llamémosle particular. Primero porque su obra es más realista que otra cosa, nada de grafitis o dibujos; y segundo porque su cometido es convertir objetos… en invisibles:

http://www.joshuacallaghan.com/

Reportaje fotográfico En Telegraph.co.uk .

Etiquetas: Arte, Diseño

¿Y si todo lo que sabes de CSS está equivocado?

Todos aquellos que alguna vez os hayáis dedicado a hacer vuestros pinitos en el mundo del diseño web, o simplemente seáis profesionales de ello, habréis oído, os habrán enseñado, habréis dicho por activa y pasiva, que “usar tablas es una chapuza, se deben usar divs (capas)“. Pero, ¿qué pensaríais si os digo que existe la posibilidad de que hayamos estado equivocados? ¿que todo lo que creemos saber sobre CSS, tablas y divs está equivocado?

El caso, y de ahi el tambaleo a las bases de la maquetación web en CSS, es que parece ser que las tablas vuelven a estar en primera plana debido a las propiedades que CSS incorpora para la creación de estas. Es decir, que ya no serían “tablas HTML”, sino “tablas CSS”.

Queda saber si el problema de los navegadores nos afectaría tanto como hasta ahora (un div es un div mientras a Internet Explorer no le dé por decir lo contrario), ya que por lo pronto Internet Explorer 7 no soporta las tablas CSS, aunque como casi siempre el resto de navegadores mayoritarios sí.

Os dejo igualmente un enlace a un articulo con ejemplos, código y uso de tablas CSS, llamado “Everything you know about CSS is wrong” cortesía de Digital Web Magazine.

PD: Aprovecho la ocasión: si aún usas Internet Explorer, haznos un favor a todos y sobre todo a ti mismo, y bájate Firefox de una vez.

Etiquetas: Actualidad, Diseño