Por qué las webs se rompen en silencio en otros navegadores

El informe de error suena familiar: «A mí la página se me ve rota». La desarrolladora abre la página y ve — nada. Todo en su sitio. Solo la llamada de vuelta aclara la situación: el cliente usa Safari en el iPhone; ella, Chrome en el escritorio. Entre ambos median dos motores de renderizado, varios anchos de pantalla y una serie de diferencias silenciosas de las que ninguna ha generado jamás un mensaje de error.

Que la misma web pueda verse distinta según el navegador no es un accidente de funcionamiento, sino arquitectura. En el núcleo de cada navegador trabaja un motor de renderizado que traduce HTML y CSS a píxeles. Tres familias se reparten hoy prácticamente todo el mercado: Blink impulsa Chrome, Edge y la mayoría de los derivados menores de Chromium; Gecko, el Firefox; WebKit, el Safari — y en el iPhone, hasta hoy, prácticamente todos los navegadores extendidos renderizan con WebKit, aunque en el icono ponga Chrome o Firefox.

Estos motores son implementaciones independientes de los mismos estándares web. Los estándares describen qué debe hacer una propiedad CSS — pero dejan márgenes, se implementan a ritmos distintos y, de vez en cuando, dos equipos de desarrollo entienden la misma formulación de manera diferente. El resultado son tres programas que leen el mismo documento y llegan a imágenes ligeramente distintas. Casi siempre las diferencias son invisiblemente pequeñas. A veces, no.

El punto decisivo: estas diferencias permanecen mudas. CSS está diseñado deliberadamente para tolerar errores. Una propiedad que un navegador no conoce se ignora sin más — sin aviso, sin fallo, sin entrada en registro alguno. Lo que en la introducción de técnicas nuevas es una bendición, porque los navegadores antiguos no responden a las hojas de estilo modernas con un fallo total, se convierte en el día a día en una trampa: la página no se rompe, solo se ve mal. Y nadie se entera mientras nadie mire.

Los puntos de rotura típicos se dejan ordenar. Están, primero, las funciones CSS jóvenes que un motor ya domina y otro todavía no, o de otro modo en los detalles. Están las cuestiones de interpretación del layout — cómo tratan Flexbox y Grid los anchos mínimos, los saltos de línea o los contenedores anidados allí donde la especificación deja margen de interpretación. Y están los clásicos: elementos de formulario como campos de selección, casillas de verificación y entradas de fecha, que cada navegador dibuja a su gusto y que solo se dejan remodelar de forma limitada.

Un ejemplo de la primera categoría hace tangible el patrón. La propiedad CSS gap, que regula las distancias entre elementos, estuvo disponible pronto en todos los motores para el layout Grid — en el contexto de Flexbox, sin embargo, Safari la soportó bastante más tarde que Chrome y Firefox. Una navegación cuyos puntos de menú se mantenían separados con Flexbox y gap se veía impecable en dos motores; en versiones antiguas de Safari, los puntos quedaban pegados. Ningún mensaje de error, ningún fallo, técnicamente todo funcionaba — solo que la página parecía apretada y descuidada en una parte de los iPhone. En casos así, el remedio es una solución de repliegue con los márgenes exteriores clásicos; pero para eso primero hay que saber que la diferencia existe. Justo esa es la verdadera barrera de las roturas silenciosas: no figuran en ninguna lista de errores. Solo figuran en la imagen.

A eso se suman diferencias que ni siquiera están en la hoja de estilos. Las fuentes se renderizan de forma distinta en cada sistema operativo y resultan de anchos diferentes; un titular que en un entorno cabe en una línea salta en el otro y empuja hacia abajo todo lo que hay debajo. Las barras de desplazamiento, según el sistema, restan espacio al contenido o se superponen a él — y con ello alteran el ancho disponible. Las unidades de viewport se comportan de manera distinta en dispositivos móviles según cómo el navegador contabilice las barras de dirección que aparecen y desaparecen.

La segunda gran fuente de roturas silenciosas son los anchos de pantalla. El diseño responsive define puntos de conmutación — breakpoints — en los que el layout se reorganiza: la navegación se pliega en el icono de menú, las columnas se apilan, los espaciados encogen. Por experiencia, se prueba en los anchos estándar de los dispositivos habituales. Se rompe en el medio: en tamaños de ventana inusuales, en tabletas en horizontal, en ventanas partidas por la mitad en monitores de escritorio anchos.

A las páginas en alemán les golpea con especial dureza una peculiaridad: los compuestos largos. Donde en inglés hay tres palabras cortas, en alemán está la «Datenschutzgrundverordnung» — una palabra que se niega a partirse, sobresale de su contenedor o revienta una navegación en cuanto escasea el espacio. Las interfaces traducidas, que en el original inglés se veían impecables, figuran por eso entre los candidatos más fiables a problemas de salto de línea.

Incluso una página que hoy se ve correcta en todas partes, por cierto, no se mantiene así por sí sola. Los navegadores se actualizan solos a ritmos cortos, los motores de renderizado cambian detalles de su comportamiento — y la web cambia de aspecto sin que nadie haya desplegado nada. La prueba cuidadosa del lanzamiento es, por eso, una instantánea, no un estado permanente. Lo mismo vale en la dirección contraria: cada actualización del CMS, cada plugin nuevo, cada cambio de texto puede provocar desplazamientos.

Detrás de todo esto hay un problema psicológico de fondo que cualquiera conoce del día a día del desarrollo: «works on my machine». Quien construye una página la ve cientos de veces en su propio navegador, en su propio monitor — y toma inconscientemente esa vista por la verdad. Las visitantes y los visitantes, sin embargo, se reparten entre motores, clases de dispositivo y tamaños de ventana, y ninguno de ellos avisa por sí solo cuando algo se descoloca. Poquísimas personas escriben un correo cuando un menú se superpone. Simplemente se van.

Tanto más valioso es el caso raro de que alguien sí avise — siempre que la notificación se trabaje con método. Un procedimiento acreditado tiene cuatro pasos. Primero, preguntar por el entorno: ¿qué navegador, qué dispositivo, qué ancho de ventana aproximado? Sin estos datos, toda búsqueda es adivinar. Segundo, reproducir en el motor adecuado, no en una simulación — llegado el caso, mediante un servicio de capturas, si en ese momento no hay a mano un dispositivo con el motor correcto; cómo transcurre un ciclo de prueba así lo describe ScanU paso a paso. Tercero, acotar qué mecanismo está afectado: ¿se rompe el layout en un punto de conmutación, falta una función CSS, resulta más ancha una fuente? La respuesta determina la reparación — los problemas de breakpoints los resuelve la propia hoja de estilos, las funciones ausentes necesitan una solución de repliegue, los problemas de fuentes a menudo solo contenedores más generosos. Y cuarto, el paso que más a menudo se omite: tras la corrección, volver a mirar todos los motores. Quien solo comprueba el punto notificado pasa fácilmente por alto que la reparación ha desplazado algo en otro lugar.

Llegado este punto, cabría la objeción de que las herramientas de desarrollo de los navegadores han resuelto el problema hace tiempo: todo navegador moderno trae un modo de dispositivo que simula los tamaños de pantalla de teléfonos y tabletas. La objeción pasa por alto lo que ese modo hace realmente. Quien en Chrome elige la vista de iPhone obtiene una ventana estrecha con resolución adaptada e identificación móvil — pero se sigue renderizando con Blink, el motor de Chrome. Las peculiaridades WebKit del navegador real del iPhone no las muestra esta simulación, ni tampoco las peculiaridades Gecko del Firefox. Para el trabajo en los breakpoints, el modo de dispositivo es una herramienta excelente; como prueba de compatibilidad entre navegadores no sirve. Un motor no se deja simular, solo cambiar.

¿Cómo se encuentran roturas que no avisan? El camino tradicional es trabajo manual: un armario lleno de dispositivos de prueba o una lista de navegadores que alguien recorre a golpe de clic tras cada cambio. Funciona, pero escala mal — ya tres navegadores por tres clases de dispositivo dan nueve vistas por página, y la minuciosidad, según muestra la experiencia, baja con cada repetición. El camino más sistemático son los servicios de capturas que paralelizan esa inspección visual. ScanU, por ejemplo, genera tras introducir una URL, en unos 30 segundos, capturas en Chrome, Firefox y Safari, cada uno en vistas de móvil, tableta y escritorio; qué combinaciones de dispositivo están disponibles lo enumera la visión general de funciones de ScanU. En lugar de abrir nueve ventanas una tras otra, se ve una retícula de imágenes — y los valores atípicos saltan a la vista.

Realmente interesante se vuelve en la repetición. Los servicios de este tipo comparan el estado actual con un estado de referencia guardado y marcan las desviaciones en un careo directo. Así, de la vaga pregunta «¿se ve bien la página en todas partes?» surge la mucho más afilada «¿ha cambiado algo desde el último estado comprobado?» — una pregunta que puede responderse incluso cuando ya nadie tiene en la cabeza qué aspecto tenía la página la semana pasada.

También aquí forma parte la honestidad: las capturas muestran estados, no procesos. Qué ocurre al pasar el ratón por encima, si un menú se despliega limpiamente, cómo se comporta la página al hacer scroll o con una conexión lenta — nada de eso lo refleja una imagen estática. Tampoco sustituye una ventana de navegador renderizada la sensación del hardware real: el manejo táctil, el rendimiento de los dispositivos más antiguos, las peculiaridades de versiones concretas del sistema. Antes de un lanzamiento importante, echar mano del teléfono de verdad sigue siendo una buena idea, y los tests funcionales, en cualquier caso, no los reemplaza una captura.

Cuánto esfuerzo es apropiado dedicar al tema no tiene que decidirlo nadie de forma genérica — las propias estadísticas de acceso marcan la dirección. Muestran por qué navegadores, clases de dispositivo y anchos de pantalla llegan las visitantes y los visitantes reales, y con ello qué combinaciones merecen prioridad en la lista de comprobación. Dos salvedades, no obstante, forman parte del cuadro. Primera: la estadística solo mide quién llega — no quién ni siquiera se queda por culpa de una vista rota; un motor débilmente representado puede ser también consecuencia de un problema, no solo señal de escasa relevancia. Segunda: las proporciones difieren considerablemente según el público objetivo y la situación de uso: una oferta que se lee por la noche en el sofá tiene otra distribución de dispositivos que un portal especializado para la jornada de oficina. La propia lista de comprobación debería seguir, por eso, las propias cifras, no los panoramas generales del mercado.

Para el día a día basta a menudo una rutina sencilla: tras cada cambio en estilos o plantillas, comprobar las páginas más importantes en las tres familias de motores; tras las releases mayores de los navegadores, revisar una vez el inventario; en los rediseños, mirar conscientemente también los anchos intermedios, no solo los formatos estándar. Quien tema el esfuerzo, que empiece pequeño — la página en español de ScanU introduce el servicio, cuyo nivel gratuito, con un proyecto y 500 créditos al mes, alcanza para los primeros pasos.

El núcleo del problema, mientras tanto, permanece, y esa es quizá la verdadera conclusión: los navegadores seguirán siendo también en el futuro programas independientes con motores propios, los estándares seguirán dejando márgenes y CSS seguirá callando en lugar de avisar. Las roturas silenciosas no son señal de trabajo descuidado, sino una propiedad sistémica de la web. Tratar con ellas es, por eso, ante todo una cuestión de visibilidad: quien contempla su propia página con regularidad a través de los ojos de los tres motores — da igual con qué herramienta — le quita al silencio su efecto.