soy Kseso y esto EsCSS

El pequeño y sucio secreto del Responsive Web Design

Traducción al español del artículo de John Albin Wilkins publicado en palantir.net sobre el problema del redondeo del px en diseños basados en porcentajes. Incluye solucciones.

El pequeño y sucio secreto del Responsive Web Design

✎ 18
COLABORACIÓN AUTOR INVITADO

Lo que sigue es una modesta traducción del artículo de John Albin Wilkins publicado el 16 de Julio de 2012 en palantir.net: "Responsive Design’s Dirty Little Secret" sobre el problema del redondeo del px en los diseños basados en porcentajes.
Además de la parte expositiva y explicativa inicial, el autor incluye alguna solucción.
De entrada mis disculpas por los fallos o errores tanto en la traducción como interpretación de los conceptos expuestos. Si encuentras alguno déjame tu propuesta en los comentarios. Gracias.

Responsive Design’s Dirty Little Secret

La verdad es que los diseños fluidos (fluid grids) están rotos. Bueno ... tal vez sólo un poco agrietados. El Responsive Web design, como Ethan Marcotte lo define, no es más que una rejilla adaptable, imágenes adaptables y consultas de los medios (media queries). Sin embargo, las "fluid grids" tiene un pequeño y sucio secreto: los errores de redondeo. Al diseñar nuestras columnas en porcentajes, los navegadores tienen que traducir eso en píxeles del dispositivo real para que quepa en la ventana gráfica. Y Chrome, Safari, otros navegadores WebKit, Opera y los sospechosos habituales (IE 6 y 7) todos producen "errores".

Puse los errores entre comillas, porque en realidad el problema tiene que ver con la especificación CSS. No especifica cómo los desarrolladores de navegadores deben lidiar con porcentajes que contienen precisión decimal. Por ejemplo, con una grilla de 6 columnas, cada columna es 100% ÷ 6 = 16,666667% de ancho. En 1000 píxeles de ancho del visor (cifra escogida convenientemente para hacer nuestros cálculos más fácil), son 166,66667 px por columna. Dado que la especificación no proporciona directrices, los desarrolladores de navegadores son libres de hacer sus propias reglas. Si un navegador lo hace al píxel más cercano, en nuestro ejemplo, queremos llegar a 167 píxeles. Pero 167 x 6 = 1.002 píxeles, tendríamos que ya no hay espacio para las 6 columnas en la grilla. Por otra parte, si un navegador redondea a 166 píxeles por columna, tendríamos 4 px menos.

IE 6 y 7 tomaron la primera estrategia, lo que significaba a menudo diseños rotos completamente: el último elemento se queda sin espacio y se coloca en la siguiente fila. Este fracaso es leyenda. Cambiando la estrategia más tarde, los navegadores Webkit calculan todos los valores y luego se redondea hacia abajo al entero más cercano, por lo tanto, evitando la posibilidad de rotura de diseño. Opera, por otro lado, simplemente toma el valor 16.666667% de nuestra hoja de estilo, se redondea hacia abajo al 16% y luego hace los cálculos para llegar a 160 píxeles por columna, un total de 6 píxeles menos de lo que te esperas. Antes de empezar a insultar a los desarrolladores de Opera, recuerda una vez más que la especificación no CSS proporciona ninguna regla de "la forma correcta" de hacer nada de esto.

¿Aún podría empeorar?

Desafortunadamente, si usted utiliza porcentajes en los márgenes y paddings, el problema es aún peor. La mayoría de los métodos de diseño en CSS flotan los artículos uno al lado del otro. Lo que significa que el posicionamiento exacto de un elemento de la cuadrícula depende de todos los cálculos realizados en los elementos anteriores a él en la fila. Si usted tiene una estructura de 12 columnas con margin y padding en %, significa que la columna nº 12 en una fila depende de los cálculos margin-left, padding-left, width, padding-right y margin-right de las 11 columnas anteriores . Añadir el margen izquierdo de la columna 12 misma y salen 56 oportunidades de errores de redondeo, para determinar el de píxel donde colocar la columna 12. En otras palabras, la columna 12 en teoría podría estar 56 píxeles a la izquierda de donde debería estar. No es de extrañar, ya he visto a desarrolladores front-end manifestarse en Twitter .

Teniendo en cuenta este hecho un poco chocante, no es de extrañar que muchos de los ejemplos de diseño en media queries no usen un "wrap", caja contenedora, que podría hacer esta la falla obvia en algunos navegadores.

Para explorar estos errores usted mismo, usted puede ver la página de demostración 10-columna que expone los errores de redondeo en distintos navegadores.

¿Qué @#~$%% podemos hacer?

En primer lugar, permítanme dirigirme a todos los defensores del "adaptive Web design" que están saltando arriba y abajo gritando: "¡Lo sé! ¡Lo sé!" Sí, utilizando un enfoque de diseño adaptativo en vez de un "responsive" es una obvia solución temporal. El diseño web adaptable no utiliza una grilla fluida, por lo que es completamente inmune a los errores de redondeo de la "fluid grid". En cambio los diseños "adaptive" recogen una serie de anchos específicos (viewport) que declaran, y lss viewports no suelen coincidir exactamente con los anchos resultantes al obtener el diseño en pixel-fijos para el diseño más pequeño siguiente con el que el diseño es compatible. No voy a entrar en el debate de "adaptative" frente "responsive", sólo quería mencionar que el diseño adaptativo es una solución alternativa perfectamente válida.

La mejor solución

Se dará cuenta de que no he incluido a Firefox en la lista de navegadores con problemas de redondeo. Firefox implementa una solución bastante innovador llamada renderizado del sub-pixel (sub-pixel rendering). En lugar de hacer todo el redondeo a píxeles enteros y permitiendo los errores en el total, Firefox mantiene los valores de sub-píxel (decimales) para todas las propiedades CSS y cuando el posicionamiento de un elemento depende de las propiedades de los elementos anteriores, los valores de subpíxel se utilizarán en los cálculos. El efecto es mucho más agradable y en línea con las expectativas de los diseñadores.

IE8 introdujo el renderizado del sub-pixel posiblemente como respuesta a lo mal que manejan los diseños con su propuesta ex "round up" en Internet Explorer 7 y versiones anteriores. WebKit y Opera, con su estrategia de redondeo, aún no han adoptado el renderizado de sub-pixel.

Una opción es que usted podría esperar a que todos los proveedores de navegadores apliquen la solución de renderizado sub-pixel, pero hemos estado esperando por más de 4 años para que eso suceda. Estoy deseando que llegue el arreglo, pero no voy a esperar a que sea. Afortunadamente, hay tres soluciones que puede implementar hoy.

Espera ... ¿qué pasa con FlexBox de CSS3?

Ya que utilizaremos porcentajes para implementar un diseño "responsive" con FlexBox, será susceptible a los errores de redondeo. Flexbox no es la panacea del diseño.

Quite algunos de sus valores porcentuales de su diseño

En primer lugar, lo admito, trabajar con porcentajes a los canales (márgenes) y el relleno es sólo una diversión para los más "anal-retentive". Nuestros tamaños de fuente no están basando su variación en el tamaño de la ventana (por lo general) y, a fin de lograr un correcto sentido de la estética, nuestras canales (espacios de separación) debe ser proporcional al tamaño del texto. Tener canales que se expanden como el tamaño de la ventana aumenta significa que tenemos que añadir un pequeño batallón de puntos para obligar a los canales a comportarse.

Pero hay una propiedad CSS poco conocida llamada box-sizing: border-box. El dueño de Palantir, Patrick Grady, me mostró esta propiedad el verano pasado y me cambió la vida. En el modelo de caja de CSS2, el relleno y los bordes son externos a la anchura de un elemento. Esto significaba que si ponemos el ancho de un elemento a un porcentaje del ancho de su padre, nos vemos obligados a utilizar también los porcentajes para los márgenes y el relleno de ese elemento. De lo contrario, las matemáticas no van a funcionar. 4 columnas a 20%, más canales de 30px nunca puede ser igual a 100%.

Con border-box, se cambia el modelo de caja de ese elemento para que el relleno y el borde interno formen parte ahora de su anchura. Esto significa que ya no están obligados a utilizar porcentajes y ahora se puede utilizar un valor fijo, un rem, em o un valor en píxel para el relleno (que yo recomendaría proporcional a su contenido, por ejemplo, font-size). El compromiso es que usted tiene que utilizar el padding en sus canales en lugar de los márgenes. Pero presiento que la ventaja de que sus separaciones sean proporcionales a su contenido supera la desventaja de necesitar un elemento contenedor (wrapper) cuando desee que el borde de una cajasea alinee a una línea de la cuadrícula. El anterior se necesita todo el tiempo, este último sólo ocasionalmente.

Por lo tanto, cuando se utiliza border-box, ya no hay errores de redondeo de los márgenes (porque has dejado de usarlos para las separaciones) y de relleno. Sin embargo, todavía hay errores de redondeo en las anchuras. Pero hemos reducido el error de redondeo teórico sobre nuestras 12 columnas de 56 píxeles a 11 píxeles. Mejor, pero el resultado sigue siendo sensible para la mayoría de los usuarios.

No permita los errores de redondeo en el cálculo

El verdadero problema de los errores de redondeo es que dificulta el hacer el diseño. Con el fin de calcular el margen izquierdo de un elemento de la grilla, tenemos que sumar todos los valores de sus elementos hermanos de la cuadrícula. ¿Qué pasaría si pudiesemos especificar el borde izquierdo directamente? En otras palabras, podría simplemente especificar la distancia desde el borde izquierdo interior del contenedor primario, mientras que todavía se permite que el elemento afecte al flujo del resto del documento?

Resulta que sí se puede. He estado usando una técnica desde alrededor de 2004, que permite cajas flotadas relativas ("container-relative floats"). También es el mecanismo de distribución principal que se utiliza en el tema Zen Drupal, que tiene más de 700.000 descargas, por lo que, aunque en un principio puede parecer demasiado pretencioso, está ampliamente probada y es sólida.

La receta básica para conseguir contenedores relativos flotados ("container-relative floats") es aplicar este CSS a cada elemento hijos de la rejilla:

float: left; margin-right: -100%;

Luego, para cada elemento de la cuadrícula (grid), basta con especificar la distancia exacta que quieres del borde izquierdo del contenedor, utilizando margin-left.

Aquí está un ejemplo rápido de este "100% negativo"

item1 { float: left; width: 40%; /* 2 columns in a 5 column grid */ margin-left: 0; margin-right: -100%; } .item2 { float: left; width: 40%; margin-left: 40%; margin-right: -100%; } .item3 { float: left; width: 20%; /* 1 column in a 5 column grid */ margin-left: 80%; margin-right: -100%; }

Tenga en cuenta que también se puede colocar un elemento de la cuadrícula con respecto al borde derecho del contenedor por flotando hacia la derecha y con un margen positivo a la derecha y un margen de -100%-izquierda.)

¿Cómo funciona esto? En primer lugar, recordar que los márgenes basados ​​en porcentajes están referidos al ancho del bloque de contención , por lo que "-100%" significa que estamos utilizando el ancho del contenedor. Recordar a continuación que el margen derecho de los elementos flotantes afecta a otros objetos flotando a su lado. Si el uso fuera utilizar margin-right: 10px-, los flotados adyacentes serían en relación a este borde derecho menos 10 píxeles. Lógicamente, "% -100" significa que el flotado adyacente sería con respecto al borde derecho menos 100% de la anchura del contenedor. Esto debe significar que la "borde relativo" está muy a la izquierda del borde izquierdo del contenedor. Sin embargo, con el borde izquierdo del contenedor evitará que los flotados adyacentes vean siquiera el borde relativo por estár tan lejos y fuera del contenedor. Dicho de forma corta, cada flotado adyacente ya no ve el borde derecho de sus hermanos para posicionarse, sino que sólo ve el lado izquierdo interior del contenedor.

Si usted piensa que esto suena un montón al posicionamiento absoluto, se está perdiendo la diferencia crucial. Elementos con posición absoluta están completamente fuera del flujo del documento y no hay manera de que afecten a la ubicación de otros elementos. Pero los contenedores relativos flotantes todavía hay que "limpiar el float". Este es el punto crucial. Mientras que los elementos flotantes con esta técnica ya no pueden ver el borde derecho del otro, todavía pueden ver sus bordes inferiores al limpiar el flotado. Y esto significa que usted puede comenzar una nueva fila de elementos de la cuadrícula simplemente con "clear" en los elementos anteriores de la cuadrícula, y esta nueva fila se situará por debajo de todo el contenido anterior. Eso no es posible con los elementos con posición absoluta.

Puesto que nuestros elementos de cuadrícula ya no se ven afectados por los bordes adyacentes de sus hermanos, ya no estamos tan limitados por orden de aparición. ¿Qué nos impide poner el primer elemento de nuestro HTML en la columna del medio de la cuadrícula y luego distribuir aleatoriamente los siguientes elementos a la izquierda o a la derecha de la primera? Absolutamente nada. Dentro de una sola fila de elementos de la cuadrícula, el orden en el código fuente HTML ya no define el orden en que se visualizarán. Todo ello sin la necesidad de las clases (class) “push” y “pull” que se encuentran en los métodos de diseño como 960.gs.

Así que ... ¿hemos arreglado todos nuestros errores de redondeo? No del todo. Hemos reducido nuestros cálculos de posicionamiento a un solo valor. Pero ese único valor todavía está sujeto a un error de redondeo, lo que significa que a veces se ve con un error de píxel. Afortunadamente, debido a la naturaleza no-OCD de los usuarios de la mayoría de los sitios web, este error suele ser un pixel imperceptible.

Si su contenido es de calidad, nadie se dará cuenta de un error de diseño de 1 píxel.

Pero hay un método que se puede poner en práctica para reducir incluso este pixel de error.

¿Solución al píxel de error? Trampear

Si todos los elementos de su estrucutura están flotando a la izquierda, todos los bordes izquierdo se deben alinear. Así que lo más probable es ver el error de píxeles en el lado derecho del elemento de la cuadrícula más a la derecha. Si este borde derecho se supone que se alinea con otros elementos de las otras filas, este error de un píxel aún podría ser perceptible incluso a los no diseñadores. Pero ¿adivinen qué? Podemos alinear todos esos bordes derecho perfectamente si flotamos todos esos elementos a la derecha en vez de flotarlos a la izquierda. ¿Adivina qué navegadores dar un error de redondeo en el cálculo margin-right: 0%? Ni siquiera IE6.

Esto último colocará el error de redondeo en medio de nuestra página donde es menos notable. Por lo tanto, tiene un cierto nivel de control sobre dónde se produce el error de renderizado por el redondeo, por lo que el lugar donde aparece es un problema menor.

Grids Zen

Hace poco escribí un manifiesto acerca de por qué la creación de diseños "responsive" requiere un preprocesador CSS como Sass. Usar Sass simplifica mucho el diseño de la disposición que tenemos que hacer, y al mismo tiempo oculta la complejidad a la que de otra manera tendrían que hacer frente a la hora de escribir en CSS puro.

Entonces, ¿cómo maneja Grids Zen estos errores de redondeo? Con los Grids Zen, el box-sizing: border-box es el método por defecto y los "container-relative floats" se realiza de forma automática para usted. Y cambiando la dirección del flotado en un elemento de la grilla es tan fácil como añadir “right” al zen-grid-item() mixin.

Y ahora, con estas técnicas, los errores de redondeo no serán un problema para usted tampoco.

Información adicional sobre cómo crear sitios "responsive" usando Mallas de Zen y el tema Zen 5 Drupal se pueden encontrar en este trabajo que presenta la gente de Acquia el 19 de julio: http://www.acquia.com/resources/acquia -tv/conference/creating-responsive ...

Autoría, créditos y permisos

Artículo original publicado en:
© Copyright 1996–2012 Palantir.net, Inc. All Rights Reserved. PALANTIR® is a registered trademark of Palantir.net, Inc.
Autor del artículo original:
John Albin Wilkins
Gracias al autor por la amabilidad y autorización para traducido y publicarlo en este blog:

Comentarios: 18

  1. Este comentario ha sido eliminado por un administrador del blog.

    ResponderEliminar
  2. Muchas gracias, información importante que desconocía

    ResponderEliminar
  3. Este comentario ha sido eliminado por un administrador del blog.

    ResponderEliminar
  4. Thanks for sharing this site, it is very informative for the business personals.Keep on continuing with this.
    Website Design Sydney
    Also visit my page

    ResponderEliminar
  5. Este comentario ha sido eliminado por un administrador del blog.

    ResponderEliminar
    Respuestas
    1. No, ma, no.
      Gracias pero tu intento de spam no cuela.
      Este blog y la página que enlazas no tienen nada en común.
      Así que: ¡ESCOBA VA!

      Eliminar
  6. Este comentario ha sido eliminado por un administrador del blog.

    ResponderEliminar
  7. Este comentario ha sido eliminado por un administrador del blog.

    ResponderEliminar
  8. Muy bueno el articulo, muchas gracias por traducirlo!!

    ResponderEliminar
  9. Este comentario ha sido eliminado por un administrador del blog.

    ResponderEliminar
  10. ¿Otro más? Ok, es un offtopic, pero no me aguanté y empecé a escribir.
    Me parece que tenés un sentido de la tolerancia y el respeto que no funcionan en la red. Es cierto que todos siempre tratamos de ser justos para no "castigar" a quien no lo merece. Pero este medio es muy ingrato, porque es público, y permite el acceso tanto a las personas decentes como a espamers, trolls, flamewares y cualquier otra lacra de una comunidad. Esto a mí me lo enseñaron a la fuerza, junto conque no se debe dar margen, resquicio por donde esta basura pueda pasar. Seguro que más de uno va a publicar mal sin segundas intenciones, por ingenuidad o ignorancia o simple estupidez, pero si los cacheteás como ejemplo tienen que entender el motivo. Al fin y al cabo ellos también están aquí y ya vieron el daño que causan quienes vienen a un blog para empiojarlo o sacar alguna ventaja gratuita. Si "castigás" a alguien normal, lo va a entender. Y si no, no es normal y nadie lo necesita.

    Seguramente el motivo para el alto porcentaje de espam en esta entrada fue la tolerancia a ... ¿cómo se llamaba? ... creo que web-on in-line o algo así; está más arriba. Si mirás su perfil, claramente es espamer. Y si a él lo dejaste pasar, todos los demás piensan "¿y a mí por qué no?". Y se mandan.

    No estoy seguro si los buscadores cuentan las direcciones que no están en enlaces sino en texto para subirles el rank, pero aún así entrar a ver un comentario nuevo y encontrar mensajes en cualquier idioma que claramente son multipropósito y les sirven tanto para un barrido como para un fregado, no es agradable. Aunque el autor no gane nada, los seguidores de un sitio sí perdemos.

    Por supuesto que solamente estoy opinando, no es una crítica directa a tu modo de filtrar los comentarios y mucho menos a vos, porque entiendo -repito- que viene de un sentido natural de justicia. Yo también lo tengo, pero te aseguro que en la web no lo aplico, porque no sirve.

    (Ah, sí! ... Que "ya lo habías notado de otros sitios".)
    ;-)

    ResponderEliminar
  11. EXCELENTE artículo, MUCHISIMAS GRACIAS por postearlo y tomarte el duro trabajo de traducir al autor!!!! Saludos!!!!!

    ResponderEliminar
  12. Este comentario ha sido eliminado por un administrador del blog.

    ResponderEliminar
    Respuestas
    1. Felicite a sus padres por la educación que le dieron... y que ha olvidado.
      Y no le quepa duda que agredeceremos no volver a verle por este blog.

      Eliminar
    2. Ya sé que siempre me meto donde no me llaman, pero quizá valga aclarar que más allá de la poca educación para criticar el artículo, este sujeto al que no conocemos en el blog porque jamás ha colaborado antes (por lo que su opinión se toma como la de cualquier desconocido) se la agarró contra los "sudacas" porque, según él, no sabemos traducir una preposición en inglés, y el motivo es que tampoco sabemos hablar español.
      A mí personalmente me nefrega la opinión de esta clase de gente, pero es cierto que no lo hizo ni como broma ni como algún guiño para con los sudamericanos, sino con intención ofensiva.
      Y es lógico que al Balrog no le guste.

      Kseso: como mencioné más arriba, este artículo es un imán para los desubicados. Pero al menos nos sirve a todos nosotros para reirnos un poco de ellos. Cuando no nos dan pena.

      Eliminar
  13. Este comentario ha sido eliminado por un administrador del blog.

    ResponderEliminar
    Respuestas
    1. El comentario de Gabriel Pardo ha sido borrado por spam

      Eliminar
  14. Muchas gracias por el articulo y su traducción. Saludos.

    ResponderEliminar

EsCss RSS del Blog RSSS Comentarios Humans.txt ᛯ Diseno por Kseso SiteMap