css

Flexbox, las nuevas interfaces flexibles de CSS3

Flexbox es la palabreja con la que se denomina al flexible box layout, que podríamos traducir como maquetación de cajas flexibles. ¿Y qué se esconde tras esto? Ni más ni menos que una nueva forma de maquetar interfaces mediantes CSS3.

Sombras y degradados en CSS3

Esta vez no voy a hablar de nada nuevo. Muchos diseñadores y maquetadores web están ya incluyendo estos efectos a sus trabajos. Sin embargo, para mí son nuevos :) Los he utilizado con anterioridad pero muy brevemente, y sin tener muy claro qué hacían y por qué exactamente. Si quieres ir directo a los ejemplos, los tienes aquí. ¡Al lío!

10 errores comunes de programadores web novatos

Hace poco comentaba que en SitePoint habían publicado una lista de los 10 errores comunes de diseñadores web novatos. Pues recientemente publicaron un nuevo artículo, pero esta vez sobre los programadores web. Aquí el resumen:

  1. Ignorar los estándares web. Destacan el uso incorrecto del DOCTYPE, uso de etiquetas antiguas de HTML, o no validar el código.
  2. Delegar en software WYSIWYG. Muy acertadamente indican que, con este tipo de software uno se centra en la visualización, y no en la estructura.
  3. Descuidar aspectos semánticos. El ejemplo que ponen es impagable: El programador novato, si quiere escribir un titular, lo pondrá encerrado en la etiqueta <h1>. Pero posteriormente es posible que “involucione”, y lo diseñe con divs anidados y estilos CSS.
  4. Nombres de clases de estilos. ¿Qué tal una clase como “columna-izquierda-50px”? ¿Y si en un futuro el ancho cambia?
  5. Prueba de navegadores tardía. Invitan al programador novato a revisar su página en varios navegadores desde el primer momento, y no dejarlo para el final. Personalmente, en este punto no estoy de acuerdo; Siempre he preferido desarrollar para una plataforma, y al final, corregir errores de las demás.
  6. Ignorar la portabilidad. Destacan enlaces a rutas absolutas, conexiones a bases de datos sin centralizar, o realizar suposiciones sobre el entorno de ejecución.
  7. Descuidar el ancho de banda. Poco más que añadir… En local un fichero de unos megas es irrelevante, no así en Internet.
  8. Pésima accesibilidad. No consiste sólo en seguir unas reglas mecánicas de código, sino en tener en cuenta aspectos funcionales como poder consultar la web sin javascript, sin flash, en un móvil, o sin ratón.
  9. Despreciar al SEO. Me encanta la definición que hacen del SEO: Es una mezcla de psicoanálisis, complejidad técnica, y misteriosas artes oscuras. En cualquier caso, indican que el desarrollador novato, dejará el SEO para el departamento de marketing una vez lanzada la página. Para entonces, ya será demasiado tarde.
  10. Actualizaciones erróneas. Destacan la práctica de muchos programadores web de tener durante horas una página web en mantenimiento, cuando suele ser una tarea que no debería llevar más de unos minutos. En este punto tampoco estoy de acuerdo. Muchas actualizaciones tan sólo consisten en añadir documentos html, imágenes, y actualizar hojas de estilo y javascript. Sin embargo, hay aplicaciones web que requieren mucho más que eso a la hora de actualizar, por ejemplo cuando cambiamos la estructura de una base de datos, y se deben reestablecer todos los índices.
  11. Como bonus, dejan una lista de otros 20 errores.

En general, este artículo me ha parecido bastante más pobre que el anterior. Sobre todo, por lo mucho que se centra en la capa de presentación HTML, que dista mucho de ser coto exclusivo de los programadores web. En ningún punto se ha mencionado ni una sola práctica o error relacionada con la programación (Salvo el punto 6, donde sugieren no incluir hard coded la conexión a base de datos).

10 errores comunes de diseñadores web novatos

Hoy me he encontrado en SitePoint un curioso artículo titulado “10 Common Mistakes Made by Novice Web Designers“. Me ha parecido muy interesante, pues aunque no soy diseñador propiamente dicho, pero sí he cometido muchos de esos errores.

Y esta es la lista:

  1. No tener en cuenta la forma de visualizar del navegador. Cada navegador funciona a una resolución, y ésta normalmente no es la misma que los bocetos hechos en Photoshop. ¿Cómo se comporta la página al cambiar de tamaño?
  2. Forzar a altos y anchos fijos. ¿Qué ocurre si el texto que hay dentro es anormalmente extenso o anormalmente corto?
  3. Presuponer sobre la experiencia del usuario. Hay muchas resoluciones y muchos dispositivos a tener en cuenta.
  4. Sub-pixels en bocetos. Un boceto a 300 ppp no se verá igual en un monitor a 72 ppp.
  5. Desconocimiento de las pilas de fuentes. No todas las fuentes funcionan en todos los sistemas, ni siempre se ven igual.
  6. No tener en cuenta el desarrollo. Nos ponen el ejemplo de títulos ricos en diseño que sólo se pueden conseguir con imágenes. Es algo asumible cuando hay 5 o 50 páginas, ¿pero y si hay 500? ¿O 5000?
  7. Olvidar en los enlaces. Los links son el hilo conductor de la web, y hay que diferenciarlos bien del resto del contenido.
  8. No tener en cuenta animaciones o efectos. Esto no se puede reflejar en un diseño en photoshop.
  9. Controles de formularios extraños o inaccesibles. Nos explican que los formularios son sosos, pero que sin embargo los navegadores saben renderizarlos y los usuarios los entienden.
  10. Poca apreciación por las tecnologías. HTML y Flash no son lo mismo :)

En mi opinión, las más importantes a tener en cuenta (O al menos las que más problemas me han dado) son la 2, 4, 6, 8 y 10 (Curioso, justo los pares).

Facturas en CSS

Vía css-tricks veo un sencillo método para crear facturas sólo con CSS. ¿Y por qué usar este método en lugar de un software específico? Bueno, gracias a esto sólo necesitas el navegador para poder crear tus facturas. Y qué demonios, es muy ilustrativo el ejemplo. ¡Qué de cosas se pueden hacer con textarea! Además, es fácil de imprimir, y pasarlo a PDF es algo trivial.

Ver demo

Botones súper increíbles con CSS3 y RGBA

CSS3 ya está aquí, y ha llegado para quedarse. Gracias a él, podemos crear increíbles efectos en navegadores modernos (Teniendo en cuenta un enfoque de graceful degradation). En éste artículo voy a mostrar cómo, desde ZURB, han creado unos botones CSS que realmente son súper increíbles. Accede a la página del artículo para ver demostraciones en vivo.

Botón en ancla »

Botón en ancla 2 »

La magia está en el CSS:

.button{
   background:#222 url(/wp-content/uploads/2009/12/alert-overlay.png) repeat-x 0 0;
   display:inline-block;
   padding:5px 15px 6px;
   color:#fff !important;
   font-size:13px;
   font-weight:bold;
   line-height:1;
   text-decoration:none;
   -moz-border-radius:5px;
   -webkit-border-radius:5px;
   -moz-box-shadow:0 1px 3px rgba(0,0,0,0.25);
   -webkit-box-shadow:0 1px 3px rgba(0,0,0,0.25);
   text-shadow:0 -1px 1px rgba(0,0,0,0.25);
   border-bottom:1px solid rgba(0,0,0,0.25);
   position:relative;
   cursor:pointer;
   overflow:visible;
   width:auto
}

button::-moz-focus-inner{
   border:0;
   padding:0
}

.button:hover{
   background-color: #111111;
   color: white
}

.button:active{
   top:1px
}

Una sombra a la caja, otra al texto, un borde redondeado, y de fondo una imagen png que realiza el degradado (Se puede realizar también con CSS en Webkit). Una pasada hacer todo esto sólo con CSS, ¿no?

¡Pero espera! ¡Ahí no queda la cosa! ¿Qué ocurriría si cambiásemos el color de fondo sobre el que está el botón? La sombra se vería “rara”, al igual que el color del borde.

super-awesome-buttons-fixed

Y lo mismo ocurriría con la sombra del texto si cambiásemos el color de relleno del propio botón. ¿Cómo se soluciona? Ahora es cuando llega al rescate la A de RGBA :) Por ejemplo, en la sombra de la caja, lo hemos definido como:

rgba(0,0,0,0.25)

Es decir, color negro al 25% de transparencia. De ese modo, la sombra siempre “lucirá” del mismo modo usemos el color que usemos.

Espero que os haya gustado tanto como a mí.

Vía Smashin Magazine,

Escribe mejor CSS con lesscss

Vía SitePoint descrubo una joya :) Se trata de una herramienta programada en Ruby que permite escribir código CSS de forma más efectiva: LESS. En palabras de sus creadores, LESS extiende CSS añadiendo variables, mezclas, operaciones y anidamiento de reglas.

Por ejemplo, podemos definir una variable que contiene un color en notación HTML, y desde ahí se definen estilos con ese color. De esta forma, si mañana lo cambiamos, sólo tendremos que actualizar esa variable.

El anidamiento mejora enormemente la legibilidad del código. Si a eso le sumamos las operaciones que podemos realizar, como por ejemplo multiplicaciones, el resultado es sensacional.

Prometo usarlo :)

Cómo escribir un archivo CSS

A veces trucos sencillitos nos ayudan mucho en el día a día de la maquetación web. En este minipost voy a intentar convenceros de que es mejor escribir todas definiciones de una clase en una sola línea, en lugar de en varias.

Partamos de un ejemplo cualquiera. Tenemos un estilo CSS para un párrafo que utiliza la clase “foo”:

p.foo {
   border: 1px solid red;
   background-color:#EEE;
   font-size: 12px;
   padding: 20px;
   width: 300px;
   float: right;
}

Si digo que es más cómodo ponerlo todo en una línea muchos pensaréis “no… Es incómodo y queda mal estructurado”:

p.foo { border: 1px solid red; background-color:#EEE; font-size: 12px; padding: 20px; width: 300px; float: right; }

Pues después de mucho tiempo funcionando con este tipo de sintaxis he de decir que es muchísimo más cómodo trabajar con estilos en una sola línea, que tabulados y multilínea. El motivo a continuación :)

Normalmente una página web cualquiera puede tener más de 50 clases de estilos como la que he puesto en el ejemplo de arriba. Sin embargo prácticamente nunca se tienen más de 10 estilos dentro de una clase. De ese modo, cuando tenemos que modificar algo en nuestra hoja tenemos primero que localizar el lugar en el que se encuentra aquéllo que queremos actualizar.

El grueso de nuestra búsqueda está en localizar la clase, ya que tenemos más de 50, y no el estilo, ya que rara vez sobrepasan los 10. Echémos números.

Vamos a suponer 70 clases, con una media de 6 estilos. Si nuestra hoja utiliza el primer método tendrá 9 líneas por clase (Añadimos una línea en blanco entre ellas), por lo que el fichero resultante tendría la friolera de 630 líneas!

Ahora lo codificamos con el segundo método. Una linea por clase, y en total… 70 líneas. Eso es un gran ahorro en búsqueda!

Dicho de otra forma. En lugar de buscar entre 630 “campos”, tendremos que buscar entre 70 y entre 6. Esto en algoritmia se llama optimización :)