__Ni fijo, ni líquido. Elástico
La eterna discusión sobre qué tipo de diagramación (layout, maquetación) es mejor para cierto tipo de páginas debería quedar al fin zanjada.
La mejor solución para los diseños donde lo primordial es el texto está entre nosotros.
En un principio, existían dos tipos de diagramación. Estos tipos estaban diferenciados en el tipo de unidades que se usaban para definir los anchos de los elementos. Por un lado estaba el ancho fijo, basado en píxeles, y por otro el ancho variable, basado en porcentajes. Ésto daba como resultado: páginas de anchos inamovibles el primero y páginas que se acomodaban al ancho de la ventana del navegador el segundo.
En una época, el ancho fijo fue el preferido por los diseñadores web no porque fuera mejor que el ancho variable sino porque era más fácil de manejar y controlar el resultado (especialmente usando programas de tipo WYSIWYG). Obviamente, cuando un diseñador web decide “controlar el resultado”, si no atiende a ciertos cuidados, es muy probable que lo haga en detrimento de las preferencias del usuario que usará su página. Una mala costumbre de aquella época era, además de poner anchos fijos a los elementos, definir tamaños fijos (también en píxeles) a la tipografía. Resultado: una gran pérdida en la accesibilidad de las páginas (que sumada a la costumbre de maquetar con mil tablas anidadas y mil grafiquitos sin más utilidad que “embellecer” la página daba como resultado un verdadero calvario para todo usuario con algún tipo de discapacidad visual).
Los anchos variables estaban reservados a “los que sabían” porque eran más dificiles de predecir y, a la vez, lograr un diseño vistoso que no se “rompiera” cuando se pasaba de verlo en una pantalla de 640*480 a una de 1024*768 era demasiado complicado y desgastante para la mayoría, además existía (y aún existe) el mito de que es un sistema más usable y/o accesible, lo cual no es cierto. ¿Qué ganaba el usuario? personalmente, siempre creí que nada, salvo tener menos espacios libres en la pantalla (si a ésto se le puede llamar “ganancia”). Además, esta práctica se complementaba casi siempre con tamaños de tipografía fijos, lo cual tampoco ayudaba al resultado final. Leer textos largos en pantallas cada vez más grande se hacía cada vez más complicado. ¿Por qué? porque no es lo mismo el 80% de 800px que el 80% de 1280px y saltar de una línea a la siguiente (sin tener que buscar cuál es la siguiente) no es tan fácil como podría parecer en un primer momento.
Cualquiera que se haya dedicado en algún momento de su vida al diseño gráfico editorial sabrá que existen, o al menos habrá escuchado hablar de, ciertas normas o convenciones. Una de ellas define lo que se considera el ancho óptimo de una línea de texto para ser leído en bloque. Éste es de entre 30 em y 35 em. La unidad de medida de este ancho es el “em”. Un “em” mide exactamente el ancho de la letra “M” mayúscula de una tipografía dada y a un tamaño dado. Efectivamente, según esta definición un “em” no mide físicamente siempre lo mismo. ¿Por qué se usa esta medida? porque el ancho óptimo para la lectura dependerá, necesariamente, del tipo de letra que se use y, más necesariamente aún, del tamaño de ésta.
Aplicando el ancho óptimo a la web
Aquí empieza lo bueno. Las hojas de estilo admiten el uso de “em” como unidad de medida, lo cual nos permite escribir textos definiendo un tamaño de tipografía relativo sin depender de impredecibles porcentajes. La ventaja número uno es que el tamaño es relativo a la tipografía que se use y no al ancho de la ventana del usuario. La ventaja número dos es que, felizmente, usar “em” como unidad para tamaños de tipografía permite que el usuario pueda variar el tamaño desde el control de tamaño de letra de su navegador preferido.
Una práctica que se usa últimamente es usar anchos fijos (px) para definir los bloques de una página y “em” para el tamaño de la tipografía. Ésto permite al usuario ver el texto en el tamaño que prefiera, eso es bueno… pero… el problema es que alguien necesite ampliar la tipografía dos o más veces y el ancho del contenedor quede como estaba originalmente. Nuestro ancho óptimo de línea da por lo suelos.
Ahora bien, ¿qué sucedería si usásemos “em” como unidad de medida para los anchos de los elementos también? Obtendríamos lo que se conoce como diagramación elástica donde todo lo que se defina basado en “em” dependerá del tamaño de letra que el usuario use.
Obviamente, no todo son rosas en este camino. IE da problemas para manejar distintos tamaños (especialmente cuando se hereda un tamaño definido por un elemento “padre”). Afortunadamente, hay una solución muy simple a este problema. Basta con definir un tamaño de letra basado en porcentaje al BODY de la página. Además, “hilando fino” hay que marcar que, al posicionar con float, IE de Mac necesita que se defina el ancho de al menos uno de los bloques un poco más pequeño de lo que la lógica matemática podría decir. Cosas de la vida.
Un poco de código
Un ejemplo muy básico sería algo como:
CSS para pegar dentro del HEAD.
<style type="text/css">
body {
font-size: 100%;
}
h1 {
text-size: 2.5em;
}
#contenido {
text-size: .85em;
width: 30em;
background-color: #f0f0f0;
}
</style>
HTML para pegar dentro del BODY.
<h1>Mi demo</h1>
<div id=”contenido”>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Sed nec est sit amet wisi ultricies aliquam. Nulla mollis sodales diam. Duis enim purus, gravida at, varius sed, egestas sit amet, ligula. Sed est neque, ultricies ut, fermentum id, congue sed, magna. Ut sed velit. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Etiam placerat orci a ipsum. Morbi sed augue vitae arcu porta consectetuer. Sed sit amet quam et elit nonummy elementum. Suspendisse auctor leo ut wisi. Pellentesque vehicula venenatis lorem. Pellentesque tincidunt dolor at urna rutrum egestas.</p>
</div>
Como se puede ver en el ejemplo, el concepto es muy simple y una vez comprendido no es demasiado distinto del uso de píxeles para definir anchos.
También tenemos un ejemplo más complejo, con una diagramación a dos columnas con encabezado y pié. Éste ejemplo puede ser alineado a la izquierda o centrado en la ventana y puede tener la columna de extras a la izquierda o la derecha mediante un intercambiador de estilos que está en la misma columna. Nótese que el XHTML no cambia en nada, solo cambian los estilos (que están brevemente comentados en el mismo CSS). Vamos, que ya no hay excusas para no usarlo
Algunas conclusiones
La realidad es que una vez que se entiende el funcionamiento de este sistema, puede usarse muy fácilmente, aunque con algunas limitaciones. El principal problema viene de la mano del uso de imágenes de fondo en los bloques de la página. No es que no se puedan usar, sino que hay que tener en cuenta algunas cosas a la hora de pensar cómo implementarlas, como por ejemplo que al achicarse un bloque éstas se cortarán y que al agrandarlo éstas no lo seguirán. Hay también algo que sí se puede aprovechar y es que se puede definir el tamaño de una imagen con “em” para el width y el height con lo cual lograremos que las imágenes así definidas se agranden o se achiquen junto con el diseño (un efecto muy simpático, a la vez que útil para una persona con problemas de visión que debe agrandar todo para verlo).
De cualquier manera y desde mi punto de vista, es (al menos hoy en día) la mejor solución para páginas y sitios web en los que lo más importante es el texto ya que permite: por un lado manejar muy facilmente un bloque de texto asegurando que su ancho es el óptimo para una lectura cómoda y eficaz; y por otro brindar una accesibilidad bastante mejorada al común de los sitios ya que es el usuario quien decide en qué tamaño desea leer nuestro contenido.
En la actualidad, 100px.com esta casi basado en una diagramación elástica. El “casi” responde a la limitación de las imágenes de fondo. En el caso de este sitio, la columna de extras no tiene el ancho definido con “em” sino que responde a un ancho fijo ya que debía tener el fondo azul con sombra y esquinas redondeadas. Si bien pudo haberse solucionado usando un truco con varios DIV anidados con sendas imágenes en cada esquina, se decidió dejar el ancho fijo para no complicar el documento XHTML innecesariamente.
Para leer más (en inglés)
- Text Sizing (en The Noodle Incident) por Owen Briggs: 264 metódicas capturas de pantalla para analizar el comportamiento de las tipografías en distintos navegadores y plataformas.
- Elastic Lawn (en el CSS Zen Garden) por Patrick Grifiths: al extremo… con imágenes de fondo y todo
Enero 12th, 2005 at 15:40
Buena explicación. Una media solución (solo para usuarios de navegadores modernos) seria el metodo Ingo Chao para crear columnas de color sin depender de una imagen de fondo. (http://www.satzansatz.de/cssd/columnswapping.html)
Un ejemplo practico, mi propio weblog.
Enero 13th, 2005 at 10:40
[…] Divagando cositas (#)
A raiz del último artículo publicado ayer (”Ni fijo, ni líquido. Elástico“) estuve pensando algunas […]
Enero 13th, 2005 at 12:17
Un tema sumamente interesante. Probaré a ponerlo en práctica a ver que tal.
Enero 13th, 2005 at 13:54
Diagramación elástica
Bajo ese nombre tan raro hay en la web de Nicolás Fantino un muy muy buen artículo sobre maquetación con CSS y XHTML donde los anchos de los bloques o divisiones se fijan en em en lugar de los píxeles o porcentajes acostumbrados, haciendo así que…
Enero 15th, 2005 at 1:01
Breves de diseño…
Seguimos con la saga de notas relacionadas al diseño. I Hate Design. Interesante weblog sobre el mal diseño. Visto en Duopixel. Intesivstation Pixel art y CSS fundidos en un sitio muy bueno. Visto en Domestik Alien. Guías de Identidad Corporativa…
Enero 15th, 2005 at 1:03
Breves de diseño…
Seguimos con la saga de notas relacionadas al diseño. I Hate Design. Interesante weblog sobre el mal diseño. Visto en Duopixel. Intesivstation Pixel art y CSS fundidos en un sitio muy bueno. Visto en Domestik Alien. Guías de Identidad Corporativa…
Enero 15th, 2005 at 3:55
se me ocurren dos limitaciones, una estética y una ideológica:
1.- Obtener columnas del mismo tamaño en un diseño elástico (o elástico/liquido para el caso) es practicamente imposible. De hecho no es posible con CSS pero se puede simular con la técnica famosa esa de FauxColumns , pero esa tecnica no la he podido aplicar con diseños elásticos.
2.- En teoría los bloques de construcción de CSS deberían ser posicionados. Para eso se crearon las propiedades position en CSS, los floats son para otra cosa, no para maquetar sitios. Diseños elàsticos con posicionamiento? Algo complicado! aunque si no eres muy purista este punto no es muy importante.
Excelente artículo!
Enero 17th, 2005 at 13:57
Are: muchas gracias por la data. Aún no he tenido tiempo de sentarme a ver de qué se trata, pero intentaré hacerlo a la brevedad… por lo pronto, se me ocurrió un divague que, agregado a la especificación de CSS 3, nos permitiría extender el diseño web un trecho (o al menos eso creo). Habrá que seguir dándole vueltas, a ver que sale.
Sosa: mea culpa, el problema cuando trabajas casi siempre con páginas dinámicas en las que cambia constantemente el largo del contenido es que te olvidas de cosas como las columnas de un mismo largo, que para un Zen Garden o un sitio estático (que hace mil que no hago) quedan bárbaras
Igualmente, con un diseño elástico puedes hacer algo igual que con el Faux Columns si no te chiflan las sombritas en los bordes exteriores (solo aplicable a diseños elásticos de 2 columnas). Todo es cuestión de hacer un fondo muy ancho (unos 3000px estaría bien) y medir los anchos de tus columnas. Por ejemplo, la de “extras” mide 15em y la de “contenido” 35em, por lo que sabemos que “extras” mide el 30% del total. Entonces, en el grafiquito, dibujas el fondo de “extras” al 30% de 3000 (900px), el resto será el ancho de “contenido”. Luego, aplicas el fondo a un
DIV“contenedor” de “extras” y “contenido” solo que en lugar de posicionar el fondo al 50% del ancho lo pones al 30% y listo. Si luego quieres las sombritas exteriores sería cuestión de englobar el “contenedor” con dos “supercontenedores” con las sombitas de un lado y del otro.Respecto al posicionamiento, puedes hacer páginas elásticas con posicionamento tanto relativo como absoluto o mixto sin mayores inconvenientes. Todo está en pensar dónde (anchos, márgenes, paddings) vas a aplicar “em” y dónde no. Disiento contigo en el tema de los floats. De movida, la propiedad
floathace que algo “flote” hacia algún lado respecto a otra cosa; eso, a mi entender, es posicionar algo y puede (y por qué no, debe) ser usado para maquetar. ¿Qué sería de los sitios donde el contenido cambia todo el tiempo sin los posicionamientos relativos, los floats y clears? eso, o yo no te entendí¡Muchas gracias por aportar a la discusión!
Enero 20th, 2005 at 16:36
El divague que tuviste con los SVG yo los replantearia ya que SVG por si mismo ya usa CSS por lo tanto más bien lo que tendria que ser es una estructura visual en SVG con un contenido semántico XHTML (hay que madurar esa idea)
Enero 21st, 2005 at 11:47
Are, no entiendo exactamente a qué te refieres, pero por lo que entiendo planteas armar la estructura visual sobre SVG con el contenido en XHTML.
Yendo “a los papeles”, SVG es un XML puro y duro por lo que se puede hacer lo que tú dices (por ejemplo, requiere el plugin para visualizar SVG). Pero mi planteo se centra en darle, en principio, el uso de “gráfico estándar” que normalmente tiene (no olvidemos que su MIME Type es
image/svg+xml) para no pedir “peras al olmo”. Creo que para empezar a acercarnos a un aprovechamiento del formato lo primero que hay que lograr es que los navegadores le den soporte “de fábrica”, sin plugins, ni extras. ¿Por qué? porque es un formato gráfico como cualquier otro, además es abierto y estándar y, por ende, nada les impide desarrollar lo que fuera necesario para verlo como a cualquier PNG. De hecho, ¿para que nos sirve el soporte para BMP? ¿quién usaría un BMP donde puede usar un PNG o un JPEG de la décima parte del peso? quiero creer que nadie. Preferiría que nos dieran soporte para un formato vectorial (sería pionero) sin necesidad deobject, con un simpleimg. Y eso sería solo el principio, lo que tú planteas es super potente (aunque todavía no se haya explorado demasiado), pero creo que antes sería necesario un tratamiento menos profundo, que permitiera un uso cotidiano aplicado sobreimgo comobackgrounden CSS, para lograr instalar la tecnología en “el mercado”.Enero 27th, 2005 at 13:31
Un error de IExplorer…
¿Qué les parece? Imágen de error creada con Error Message Generator Conocido gracias a Superporcel :-)…
Enero 29th, 2005 at 4:48
Week-log.109
El Breve recorrido sobre los post de esta semana que me llamaron la atenci
Enero 29th, 2005 at 13:58
Por supuesto primero tendira que estar implementado el SVG nativamente en todos los navegadores de uso corriente. Una vez hecho tu opció de tratarlo como imagen incrustada o la mia de tratarlo como interficie seria practicamente indiferente
Hice alguna prueba con un Firefox con SVG nativo (un proyecto un poco inestable aun) y funcionaba bastante bien
Por otro lado, estoy haciendo un nuevo weblog maquetando de una forma que seria mucho mas sencillo que el metodo Ingo Chao consiguiendo un diseño elastico. Para IE hay que olvidarse.
Hoy mismo ES viable hacer un diseño elastico si uno se toma la molestia de hacer un diseño para IE que no lo sea.
Marzo 17th, 2005 at 13:45
Hola Nicolas, es la primera vez que entro en tu sitio y realmente me parece muy bueno, se ve que tratas los temas a un nivel muy alto.
Yo soy programador, pero me interesa tambien la parte grafica, sobre todo el tema de HTML y CSS, asi que ya me pongo esta pagina en mis favoritos.
Saludos desde Milan.
Abril 26th, 2005 at 21:51
Un artículo sobre el mismo tema en english:
http://www.456bereastreet.com/archive/200504/fixed_or_fluid_width_elastic.html
Abril 28th, 2005 at 4:36
Redise
Abril 28th, 2005 at 5:23
Según la información que ofrece Opera acerca la versión 8 de su navegador…
Voy a comenzar a hacer pruebas
Abril 28th, 2005 at 9:13
No se si ya lo habras leido, pero en clagnut salio el complemento casi perfecto para este articulo.
Aqui te lo dejo.
Junio 14th, 2005 at 5:27
He leído tu post (excelente) y he estado leyendo también en otros sitios sobre diseño elástico, pero me quedan algunas dudas sin respuesta sobre el uso de ems para maquetear una página: al usar píxeles, sabemos que porción de pantalla estaremos ocupando en una determinada resolución, por ejemplo, si creamos un contenedor de 700px, sabremos que tanto espacio quedará libre en una pantalla de 800px de resolución, y podemos estar absolutamente seguros de que la gente con resolución de 640*480 tendrá que hacer scroll para poder ver toda la página. Sin embargo, con ems no sucede lo mismo, ya que al depender del tamaño que el usuario ha fijado para sus fuentes, variará en cada computador en que se vea, y por lo tanto, no podremos saber si un ancho de (por ejemplo) 75em se verá completo o el usuario tendrá que hacer scroll. ¿Existen un tope de ems que sea como un estándar al momento de determinar el ancho de una página en distintas resoluciones, navegadores o tamaños de letra comunes? (espero se haya entendido la pregunta)
Septiembre 9th, 2005 at 22:44
Me ha parecido bastante interesante el artículo y estoy de acuerdo en la mayoría de los puntos.
Solamente creo que recomendaría usar navegadores que sean en general funcionales para el usuario.
(si, salvo IE; pensamos en lo mismo).-
Enero 17th, 2006 at 20:55
te queriamos invitar a partiricpar de nuestro proyecto, una galeria, recursos y tutoriales, noticias, etc sobre los estandares webs, css, xml, ajax, etc…
se pueden ir registrando y sugeriendo sitios para la galeria…
www.purocss.com
Febrero 14th, 2006 at 11:46
Me parece una idea estupenda la de los tamaños elasticos.
He estado haciendo pruebas con iexplorer y firefox de la pagina:
“diagramación a dos columnas con encabezado y pié.”
Resulta que con iexplorer a 800×600 y eligiendo el tamaño de texto MAYOR salta el scroll horizontal. ¿Esto es normal o deberia de seguirse ajustando a esta resolucion?
Marzo 5th, 2006 at 23:59
Creo que la única ventaja de este sistema es que permite que se mantenga un ancho constante de bloques de texto adecuado para la legibilidad, pero tiene el inconveniente de que al final se acaba haciendo necesario el uso de la barra de desplazamiento horizontal cuando se amplía demasiado. Se supone que esto hay que evitarlo.
En mi opinión es mejor el ancho fijo o incluso el líquido cuando las líneas de texto no son demasiado largas.
Mayo 31st, 2006 at 16:35
Ya tienes este articulo en ikkaro
www.shinkitune.com/ikkaro
Diciembre 9th, 2006 at 2:38
permiteme referenciar tu articulo
salkudines y muy buen post
Liam