Cómo construir una buena relación entre CSS y JavaScript

Más o menos, la mayoría de los desarrolladores web tienen claro la relación que debe existir entre HTML y CSS: se tienen que separar al máximo para intentar reducir el acoplamiento al máximo.

Sin embargo, cuando se plantea la relación entre CSS y JavaScript, muchas veces se olvida lo anterior y se escribe CSS en el código JavaScript.

En el artículo Building A Relationship Between CSS and JavaScript de Smashing Magazine nos explican algunas formas de lograrlo y la importancia de ello.

Las nuevas características de JavaScript

Impresionante y aterrador todo lo que trae la próxima versión de EcmaScript, el lenguaje de script en el que se basa JavaScript. Se puede decir que es un lenguaje totalmente nuevo. Así que, ya se sabe, habrá que volver al colegio para aprenderlo.

ECMAScript 6 is la próxima versión de este lenguaje de script que es considerado el estándar. A la nueva versión también se la conoce como “Harmony” o “ES.next”.

En la wiki oficial se puede encontrar información sobre la nueva especificación. Pero yo te recomiendo la lectura de algún artículo que te puede ayudar a digerir los cambios, como por ejemplo:

Preprocesamiento de CSS

El preprocesamiento de CSS es una característica que se ha puesto de moda durante el último año y que se espera que se incorpore como una característica propia de CSS en una de las próximas versiones.

El preprocesamiento permite trabajar con constantes, variables, expresiones y hasta funciones en el código CSS, para hacerlo más mantenible y fácil de escribir. Básicamente, es dotar a CSS de características cercanas a un lenguaje de programación.

Hasta ahora conocía el sistema LESS, que como muy bien indica su nombre, tiene el propósito de ayudarte a escribir menos código.

Ahora, gracias al artículo Preprocess THIS!, he descubierto el sistema Sass. Según nos cuentan:

Sass is a meta-language on top of CSS that’s used to describe the style of a document cleanly and structurally, with more power than flat CSS allows. Sass both provides a simpler, more elegant syntax for CSS and implements various features that are useful for creating manageable stylesheets.

En HTML te puedes inventar tus propias etiquetas

Pero es una estupidez que no sirve para mucho.

El otro día, a raíz de mi artículo ¿Cuándo se usa article, section, aside o un simple div?, comenté en Twitter que se está trabajando en añadir una etiqueta nueva a HTML, <main>: main element An HTML5 extension specification.

¡¿Cómo?!

¿Por qué no? Recordemos que se espera que la especificación de HTML5 estará terminada en el año 2014, hasta entonces, muchas cosas pueden pasar.

Además, comenté que esa etiqueta se puede usar ya sin problemas, es más, se puede usar cualquier etiqueta que nos inventemos.

¡¿Cómo?!

Pues sí, como lo oyes.

Pero, ¡¿cómo puede ser?! ¡¿Por qué?!

Algún día lo explicaré, pero la respuesta rápida es porque hay mucho burro haciendo páginas web.

Pues no me lo creo.

Pues toma, un ejemplo:

El HTML:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Una página con etiquetas no válidas</title>
<link href="estilos.css" rel="stylesheet" />
</head>
<body>
<h1>Un título</h1>
<main>
<h7>El contenido principal</h7>
<p>
Este texto está en un párrafo, que está en un elemento llamado &lt;main&gt;
que no existe, por ahora, en HTML5.
</p>
<p>
Curioso, <question>¿verdad?</question>
</p>
</main>
</body>
</html>

El CSS:

main {
 display: block;
 border: 2px dotted black;
}
h7 {
 border-bottom: 1px solid black;
 font-variant: small-caps;
}
question {
 font-style: italic;
}

Así se ve en Google Chorme 22:

Así se ve en Mozilla Firefox 17:

¡Y hasta funciona en Internet Explorer 9!:

Si no ayuda, no lo pongas

Before adding a design element to your site, ask yourself: Does it simplify the user’s task? Does it add value to the user? If the answer is “no”, eliminate it.

Traducción:

Antes de añadir un elemento de diseño a tu sitio, pregúntate: ¿Se simplificará la tarea del usuario? ¿Añade valor al usuario? Si la respuesta es “no”, eliminalo.

Prioritizing Web Usability. Jakob Nielsen, Hoa Loranger. New Riders, 2006.

Lecciones aprendidas de los errores cometidos en PHP y JavaScript por un programador

Los errores son algo que me fascinan, por el poder que tienen (las consecuencias de un único error en un programa pueden ser desastrosas) y por lo mucho que se puede aprender de ellos.

En este blog tengo una colección de entradas dedicadas a los errores.

El artículo My Favorite Programming Mistakes es una interesante recopilación de los errores más interesantes que un programador (el que escribe el artículo) ha cometido en JavaScript y PHP. Vale la pena leerlo, seguro que muchos habremos cometido errores parecidos más de una vez.

Uno de los primeros artículos sobre diseño adaptable

El artículo Responsive Web Design, del 25 de mayo de 2010 y publicado en A List Apart es quizás uno de los primeros artículos que utilizó el termino responsive web design. Recordemos que en español se puede decir diseño adaptable o adaptativo, pero “diseño responsivo” queda fatal.

En este artículo podemos leer:

Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design, but it also requires a different way of thinking. Rather than quarantining our content into disparate, device-specific experiences, we can use media queries to progressively enhance our work within different viewing contexts. That’s not to say there isn’t a business case for separate sites geared toward specific devices; for example, if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach.