El bug de Chrome con html {font-size: 62.5%} En el pecado llevas la penitencia 5.3.14
El porqué y soluciones del bug de Google Chrome al declarar un tamaño para font-size en el html en % y en el body en rem o em
El bug de Chrome con html {font-size: 62.5%} En el pecado llevas la penitencia
Desde hace un tiempo vienen sucediéndose las "quejas" o avisos de un bug del navegador de Google Chrome relativo a la propiedad font-size cuando se usan porcentajes en el html y rem en el body.
Es una práctica bastante extendida desde la llegada y uso de las unidades EM y REM
el pretender controlarlas al píxel y por lo tanto prostituir su misma naturaleza y el componente de accesibilidad que le es innato.
Para ello se recurre a hacer trampas para que el valor inicial de ambas no sea el que el usuario del navegador tenga definido en sus preferencias/ajustes si no otro conocido de antemano por el desarrollador. Para un explicación más detallada tanto de ambas unidades como de la mala práctica lee el artículo De Ems y Rems.
Preparando el bug
El bug de Chrome se produce al declarar en el html el tamaño de la fuente en % (normalmente 62.5%) para buscar que sean 10px ya que la mayoría de navegadores fijan el valor de font-size en 16px en sus ajustes de configuración (62.5% de 16 = 10). A partir de ese momento el mal desarrollador ya cree controlar el valor final o equivalente del Rem y del tamaño de los textos.
Si quiere que los párrafos sean de 16px sólo tiene que declararles 1.6rem. Si dice que el h1 sea de 3rem sabe que eso son 30px para la mayoría de usuarios.
Esta práctica traducida al código que provoca el bug es algo como lo siguiente:
html {
font-size: 62.5%;
}
body {
font-size: 1.6rem;
}
El efecto del bug
Tras el código anterior la expectativa es que el texto sea renderizado en un tamaño de 16px. Sin embargo Chrome hace caso omiso del 62.5% y lo muestra mucho mayor.
En concreto multiplica por 1.6 el valor indicado en los ajustes del navegador: 16 * 1.6 = 25.6px
. Ignora olímpicamente la reducción del tamaño indicada en el html. No hace el cálculo del 62.5% de 16.
El porqué del bug
Según indican en uno de los reportes de este bug de Chrome parece ser que si se declara en el html un tamaño menor del 100% en el tamaño de la fuente es ignorado. Cosa que no ocurre si es mayor a 100%.
Y según el testimonio de algún usuario, también se produce declarando en px en ek html un tamaño inferior al valor indicado en los ajustes.
Este comportamiento afecta a las versiones estables 31.0.1650.57, dev 33.0.1707.0 y beta 32.0.1700.14 y posteriores, sin importar el SO.
Soluciones al bug de Chrome con font-size
La lógica, más efectiva, respetuosa con el usuario y sus preferencias/necesidades pasa por hacer las cosas bien y no pervertir la razón de ser del Rem y EM.
No alteres el valor del tamaño del texto que el usuario haya elegido. Construye tu css en base a él sin pretender saber al píxel el tamaño computado del rem y em.
Pero si ya tienes el problema encima y ahora Chrome te ha estropeado el control férreo que pretendías aquí indican un patch
Y si quieres otra forma de arreglarlo, TechAbly sugieren la vía de un hack javascript
<script type="text/javascript">
document.getElementsByTagName('html')[0].style.fontSize = '62.5%';
document.body.style.fontSize = '1.6rem';
</script>
Un ruego
Sinceramente, y esto no debería extrañarte después de lo que he dicho antes, por mi ¡ojalá! no sólo no lo arreglaran los desarrolladores de Chrome, no. Deberían implementarlo todos los navegadores. Ignorar la declaración font-size en el selector html si el valor fuese menor al fijado por el usuario en la configuración de su navegador.
¡Ala! Yo lo he dicho. Ahora me puedes "atizar" por mi deseo.
Kseso
the obCSServer ᛯ Ramajero Argonauta, Enredique Amanuense de CSS.#impoCSSible inside
Dicen que, en español, EsCss es el mejor blog de CSS. Posíblemente exageren.
@Kseso EsCss Kseso
Totalmente de acuerdo con tu plegaria a San Chrome, y a todos los desarrolladores de browsers. La medida debe ser relativa al valor default configurado por el usuario. Pero ni mayor, ni menor. Si hay que agregar otra unidad en la plana de CSS para que no haya lugar a dudas, que lo hagan; pero el criterio de los chicos del Chromium es excelente.
ResponderEliminarJe. Cuando hablaste de "bug" me agarré las cachas con ambas manos mientras gritaba "¡¿OTRO?!". Pero éste es justificable. Ahora me estoy peleando con uno que hace que ya no anden algunas animaciones, y a veces hasta me cuelga las páginas con los ejemplos de Codepen.
¡Amén!
ResponderEliminarEs la forma más rápida de expresar lo que pienso. Si podemos hacer una campaña de 'soporte' a la idea de estandarizar esto (que no conozco) me apunto.
No estaría mal. Por lo general estos comentarios llegan directa o indirectamente a los responsables de proponer cambios o novedades en el W3C. Pero después de releer mi discurso anterior, creo que debía aclara alguna cosa más.
EliminarKseso adhirió como nosotros a un límite en la interpretación de las medidas, y es lógico desde el punto de vista más sensato, porque los estilos no deben pisar la configuración del usuario (más si tienen que ver con accesibilidad), pero con ese criterio llevado al extremo no podríamos cambiar ni los colores de los links.
Recordemos que en el seteo de cualquier(¿?) navegador no sólo existe la opción del tamaño de fuente default (de referencia para 'em' y porcentaje de 'font-size') sino también la de "tamaño mínimo". Si lo configuramos para 5px; por más que el diseñador de la página nos ponga un tamaño 0, los caracteres se van a ver de 5px. Esto ya tiene que limitar las aspiraciones de los que se creen que desarrollar una página web es hacer un imprimible tipo *.pdf (¡Hola, drimgüeveros!).
Peeero... las medidas de vh o vw toman como referencia el viewport, y responden al pedido de crear unidades para hacer cosas como ésta
Responsive text.
que en algunos casos es perfectamente lícita, y puede que el diseño se descuadre si le limitan el ajuste. Por eso mencioné lo de una nueva unidad, o quizá una propiedad que permita (o no) saltarse los valores default de la fuente. El drama va a aparecer más en móviles o tablets, porque en pantallas grandes y sus navegadores es imposible reducir el tamaño a un "cartel" hasta que quede ilegible.
No, Furoya, si por mi cada cual puede declarar el texto (y lo que quiera) como mejor le venga en gana. Nada como los párrafos en 10 ó 12px y con una tipografía font pixel.
EliminarA lo que yo meto caña es a los tramposos que se las dan: ¡Hey! ¡Mira qué chulo soy que te pongo el texto en REMs! y ahora que nadie me ve voy y hago que 1rem sean 10px.
¡A tomar vientos, tahúr!
¿Quieres controlar al px el tamaño de los texto. ¡Hazlo! Nada te lo impide. Pero no quieras hacerte pasar por lo que no eres.
Y sobre el uso de las "vewport units" no sólo las apoyo sino que por ahí puse un par de tuits a los editores del documento del w3c que las desarrolla para que mirasen de añadir las propiedades min-font-size y max-font-size.
Pero con ellos lo mismo que con los comentarios en este blog o cualquier otro en es-es: ♫ ♬ ♪ ♩ ♭ ♪
Que mañosos, fijar el texto para que quepa en la cajita, por no dejar que la caja de texto se modifique sola. antes veia en eso una dificultad, ahora pienso que es una ventaja..
ResponderEliminarY si le colocas el 62.5% en el body? no sería lo mismo y listo!
ResponderEliminarMe parece que sí. De hecho, es lo que aplica el hack JS de TechAbly.
EliminarYo no probé las nuevas versiones de Chrome con esto. Puede que ya esté ... ¿corregido?.
(La verdad, espero que no.)
;-)
El bendito fallo, Roy, se manifiesta (¿o manifestaba?) al hacer algo de lo que indico en el artículo en el apartado El porqué del bug,
EliminarSólo encontré referencias al hacerlo en el selector html al documentarme para el post.
Pero es igual de tramposo (para mi) el hacerlo en el selector html, que en el body que en cualquier otro.
Un saludo