Usé la web por un día en Internet Explorer 8

Este artículo es parte de una serie en la que intento usar la web bajo varias restricciones, que representan un grupo demográfico determinado de usuarios. Espero elevar el perfil de las dificultades que enfrentan las personas reales, que son evitables si diseñamos y desarrollamos de una manera que sea comprensiva con sus necesidades.

La última vez, navegué por la web durante un día usando un lector de pantalla. Esta vez, pasé el día usando Internet Explorer 8, que se lanzó hace diez años hoy, el 19 de marzo de 2009.

¿Quién en el mundo usa IE8?

Antes que empecemos; un descargo de responsabilidad: no voy a decirle que necesita comenzar a admitir IE8.

Hay muchas razones para no admitir IE8. Microsoft oficialmente dejó de admitir IE8, IE9 e IE10 hace más de tres años, y los ejecutivos de Microsoft incluso le dicen que deje de usar Internet Explorer 11.

Pero por mucho que los desarrolladores esperemos que desaparezca, simplemente. no lo haré morir IE8 continúa apareciendo en las estadísticas del navegador, especialmente fuera de la burbuja del mundo occidental.

Las estadísticas de los navegadores deben tomarse con pinzas, pero las estimaciones actuales para el uso de IE8 en todo el mundo rondan entre el 0,3 % y el 0,4 % de la cuota de mercado de escritorio. El extremo inferior de la estimación proviene de w3counter:

La estimación más alta proviene de StatCounter (la misma fuente de datos utilizada por la tabla de uso "Puedo usar"). Estima que la proporción global de navegadores de escritorio IE8 es de alrededor del 0,37%.

Sospeché que podríamos ver un mayor uso de IE8 en ciertas regiones geográficas, por lo que analicé los datos por continente.

Uso de IE8 por región

Aquí está la proporción de escritorio IE8 por continente (datos de febrero de 2018 a enero de 2019):

Alguien en Asia tiene cinco veces más probabilidades de usar IE8 que alguien en Oceanía.

Miré más de cerca las estadísticas asiáticas, notando la proporción de uso de IE8 para cada país. Hay seis países principales muy claros para el uso de IE8, después de lo cual las cifras descienden para ser comparables con el promedio mundial:

Estos datos se resumen en el siguiente mapa:

Increíblemente, IE8 representa alrededor del 4 % de los usuarios de escritorio en Irán, cuarenta veces la proporción de usuarios de IE8 en Oceanía.

A continuación, miré las estadísticas de países de África, ya que tenía aproximadamente el mismo uso general de IE8 que Asia. Hubo un claro ganador (Eritrea), seguido de varios países por encima o alrededor de la marca de uso del 1 %:

Esto se resume en el siguiente mapa:

Mientras que los países de Asia que tienen un uso de IE8 más alto de lo normal están aproximadamente agrupados geográficamente, no parece haber un patrón en África. El único patrón que puedo ver, a menos que sea una coincidencia, es que varios de los países que usan IE8 más grandes del mundo censuran el acceso a Internet y, por lo tanto, probablemente no alienten o permitan la actualización a navegadores más seguros.

Si su sitio está dirigido a una audiencia puramente occidental, es poco probable que le importe mucho IE8. Sin embargo, si tiene un floreciente mercado asiático o africano, y particularmente si le interesan los usuarios en China, Irán o Eritrea, es posible que le interese la experiencia IE8 de su sitio web. Sí, ¡incluso en 2019!

¿Quién sigue usando IE?

Entonces, ¿quiénes son estas personas? ¿De verdad caminan entre nosotros?

Quienquiera que sea, puedes apostar a que no está usando un navegador antiguo solo para molestarte. Nadie elige deliberadamente una peor experiencia de navegación.

Alguien podría estar usando un navegador antiguo debido a las siguientes razones:

• Falta de conciencia
  Simplemente no son conscientes de que están utilizando tecnología obsoleta.
• Falta de educación
  No conocen las opciones de actualización y los navegadores alternativos que se les abren.
• Falta de planificación
  Descartar las solicitudes de actualización porque están ocupadas, pero no tener la previsión de actualizar durante los períodos más tranquilos.
• Aversión al cambio
  La última vez que actualizaron su software, tuvieron que aprender una nueva interfaz de usuario. “Si no está roto, no lo arregles”.
• Aversión al riesgo
  La última vez que actualizaron, su máquina se desaceleró o perdieron su función favorita.
• Limitación de software
  Su sistema operativo es demasiado antiguo para permitirles actualizar, o sus privilegios de administrador pueden estar bloqueados.
• Limitación de hardware
  Los navegadores más nuevos generalmente exigen más espacio en el disco duro, memoria y CPU.
• Limitación de red
  Una asignación de datos limitada o una conexión lenta significa que no quieren descargar 75 MB de software.
• Limitación legal
  Pueden estar en una máquina corporativa que solo aprueba el uso de un navegador específico.

¿Es realmente tan sorprendente que todavía haya personas en todo el mundo que se aferren a IE8?

Decidí ponerme en el lugar de una de estas almas anónimas y navegar por la web por un día usando IE8. ¡Puedes jugar en casa! Descargue una máquina virtual "IE8 en Windows 7" del sitio web de Microsoft, luego ejecútela en un virtualizador como VirtualBox.

IE8 VM: con un mal comienzo

Arranqué mi máquina virtual IE8, hice clic en el programa Internet Explorer con anticipación y esto es lo que vi:

Hmm, ok. Parece que la página web predeterminada de IE8 ya no existe. Bueno, eso figura. Microsoft ha dejado oficialmente de admitir IE8, entonces, ¿por qué debería asegurarse de que la página de inicio de IE8 aún funcione?

Decidí cambiarme al sitio más utilizado del mundo.

Google

Es un sitio simple, por lo tanto, es difícil equivocarse, pero para ser justos, ¡se ve genial! Traté de buscar algo:

La búsqueda funcionó bien, aunque el diseño se ve un poco diferente a lo que estoy acostumbrado. Entonces recordé: había visto el mismo diseño de resultados de búsqueda cuando usé Internet durante un día con JavaScript desactivado.

Como referencia, así es como se ven los resultados de la búsqueda en un navegador moderno con JavaScript habilitado:

Entonces, parece que IE8 obtiene la versión sin JS de la búsqueda de Google. No creo que esto haya sido necesariamente una decisión de diseño deliberada; podría ser simplemente que JavaScript se equivocó:

Aún así, el resultado final está bien para mí: obtuve mis resultados de búsqueda, que es todo lo que quería.

Hice clic para ver un video de YouTube.

YouTube

Hay muchas cosas rotas en esta página. Todo relacionado con pequeñas peculiaridades en IE.

El logotipo, por ejemplo, se amplía y se recorta. Esto se debe a que IE8 no es compatible con SVG, y lo que en realidad estamos viendo es la opción alternativa proporcionada por YouTube. Han aplicado una propiedad CSS background-image para que, en caso de que no haya compatibilidad con SVG, intente mostrar el logotipo. Solo que parece que no han configurado el background-size correctamente, por lo que está demasiado ampliado.

Como referencia, aquí está la misma página en Chrome (vea cómo Chrome representa un SVG en su lugar):

¿Y qué hay de ese interruptor de reproducción automática? Se representa como una casilla de verificación de aspecto extraño:

Esto parece deberse al uso de un elemento personalizado (un botón de papel, que es un elemento de Material Design), que IE no entiende:

No me sorprende que esto no se haya renderizado correctamente; IE8 ni siquiera hace frente al marcado semántico básico que usamos en estos días. Intente usar un <aside> o <main> y básicamente los representará como divs, pero ignorando cualquier estilo que les aplique.

Para habilitar el marcado HTML5, debe decirle explícitamente al navegador que estos elementos existen. Luego se pueden diseñar como de costumbre:

 <!--[if lt IE 9]> <script> document.createElement('header'); document.createElement('nav'); document.createElement('section'); document.createElement('article'); document.createElement('aside'); document.createElement('footer'); </script> <![endif]-->

Eso está envuelto en un IE condicional, por cierto. <!--[if lt IE 9]> es un comentario HTML para la mayoría de los navegadores, y por lo tanto se omite, pero en IE es un condicional que solo pasa "si es menor que IE 9", donde ejecuta/representa los nodos DOM dentro de ella.

Entonces, la página de videos fue un fracaso. Visitar YouTube.com directamente no fue mucho mejor:

Sin inmutarme, ignoré la advertencia e intenté buscar un video en la barra de búsqueda de YouTube.

El tráfico de IE8 es claramente lo suficientemente sospechoso como para que YouTube no confiara en que soy un usuario real y decidió no procesar mi solicitud de búsqueda.

Registrarse en Gmail

Si voy a pasar el día en IE8, voy a necesitar una dirección de correo electrónico. Así que trato de configurar uno nuevo.

En primer lugar, probé Gmail.

Hay algo un poco raro en la imagen y el texto aquí. Creo que se debe al hecho de que IE8 no admite consultas de medios, por lo que intenta mostrarme una imagen móvil en el escritorio.

Una forma de evitar esto es usar Sass para generar dos hojas de estilo; uno para navegadores modernos y otro para IE heredado. Puede obtener CSS compatible con IE y compatible con dispositivos móviles (consulte el tutorial de Jake Archibald) mediante el uso de un mixin para sus consultas de medios. El mixin "aplana" su IE CSS heredado para tratar a IE como si siempre fuera un ancho predefinido específico (por ejemplo, 65em), brindando solo el CSS relevante para ese ancho. En este caso, habría visto la background-image correcta para mi tamaño de pantalla supuesto y habría tenido una mejor experiencia.

De todos modos, no me impidió hacer clic en 'Crear una cuenta'. Había algunas diferencias entre cómo se veía en IE8 y un navegador moderno:

Si bien prometía a primera vista, el formulario presentaba muchos errores al completarlo. La 'etiqueta' no desaparece cuando comienzas a completar los campos, por lo que el texto de entrada está ofuscado:

El marcado para esta etiqueta es en realidad un <div> , y algunos JS inteligentes mueven el texto fuera del camino cuando la entrada está enfocada. El JS no tiene éxito en IE8, por lo que el texto permanece obstinadamente en su lugar.

Después de completar todos mis datos, presioné "Siguiente" y esperé. No pasó nada.

Entonces noté el pequeño símbolo de advertencia amarillo en la parte inferior izquierda de mi ventana de IE. Hice clic y vi que se quejaba de un error de JS:

Renuncié a Gmail y recurrí a MSN.

Registrarse en Hotmail

Estaba empezando a preocuparme de que el correo electrónico pudiera estar fuera del alcance de un navegador de diez años. Pero cuando fui a Hotmail, el formulario de registro se veía bien, hasta ahora todo bien:

Entonces noté un CAPTCHA. Pensé: "No hay forma de que supere esto..."

Para mi sorpresa, ¡el CAPTCHA funcionó!

Lo único peculiar en el formulario fue un posicionamiento de etiqueta ligeramente defectuoso, pero el registro fue perfecto:

¿Te parece bien esa captura de pantalla? ¿Puedes detectar el error deliberado?

La entrada más a la izquierda debería haber sido mi nombre, no mi apellido. Cuando regresé y revisé esta página más tarde, hice clic en la etiqueta "Nombre" y se centró en la entrada más a la izquierda, que es como podría haber verificado que estaba completando el cuadro correcto en primer lugar. Esto muestra la importancia del marcado accesible : incluso sin CSS ni asociación visual, pude determinar exactamente qué cuadro de entrada se aplicaba a qué etiqueta (¡aunque la segunda vez!).

De todos modos, pude completar el proceso de registro y fui redirigido a la página de inicio de MSN, que resultó excelente.

Incluso podría leer artículos y olvidar que estaba usando IE8:

Con mi correo electrónico registrado, ¡estaba listo para ir y ver el resto de Internet!

Facebook

Visité el sitio de Facebook y fui redirigido inmediatamente al sitio móvil:

Esta es una táctica alternativa inteligente, ya que Facebook necesita admitir una gran audiencia global en dispositivos móviles de gama baja, por lo que debe proporcionar una versión básica de Facebook de todos modos. ¿Por qué no ofrecer la misma base de experiencia a los navegadores de escritorio más antiguos?

Intenté registrarme y pude crear una cuenta. ¡Genial! Pero cuando inicié sesión en esa cuenta, me trataron con sospecha, al igual que cuando busqué cosas en YouTube, y me encontré con un CAPTCHA.

Solo que esta vez, no fue tan fácil.

Intenté solicitar nuevos códigos y actualizar la página varias veces, pero la imagen CAPTCHA nunca se cargó, por lo que mi cuenta quedó efectivamente bloqueada.

Oh bien. Probemos con más redes sociales.

Gorjeo

Visité el sitio de Twitter y tuve exactamente la misma experiencia de redirección móvil.

Pero ni siquiera pude llegar tan lejos como para registrar una cuenta esta vez:

Curiosamente, Twitter está feliz de que inicies sesión, pero no de que te registres en primer lugar. No estoy seguro de por qué, tal vez tiene un escenario CAPTCHA similar en sus páginas de registro que no funcionará en navegadores más antiguos. De cualquier manera, no voy a poder crear una nueva cuenta.

Me sentí incómodo al iniciar sesión con mi cuenta de Twitter existente. Llámeme paranoico, pero las vulnerabilidades como el CFR Watering Hole Attack de 2013, donde el mero hecho de visitar una URL específica en IE8 instalaría malware en su máquina, me ponía nervioso de que pudiera comprometer mi cuenta.

Pero, en aras de la educación, perseveré (con una nueva contraseña temporal):

También podría twittear, aunque usando el <textarea> muy básico:

En conclusión, Twitter está básicamente bien en IE8, ¡siempre y cuando ya tengas una cuenta!

He terminado con las redes sociales por hoy. Vamos a ver algunas noticias.

noticias de la BBC

La página de inicio de noticias parece muy básica y torpe, pero básicamente funciona, aunque con advertencias de seguridad de contenido mixto.

Echa un vistazo al logotipo. Como ya hemos visto en YouTube, IE8 no es compatible con SVG, por lo que necesitamos un respaldo de PNG.

La BBC utiliza la técnica alternativa <image> para representar un PNG en IE:

…y para ignorar el PNG cuando SVG está disponible:

Esta técnica aprovecha el hecho de que los navegadores más antiguos solían obedecer las etiquetas <image> y <img> , por lo que ignorarán la etiqueta <svg> desconocida y mostrarán el respaldo, mientras que los navegadores modernos ignoran la representación de <image> cuando están dentro de un SVG. Chris Coyier explica la técnica con más detalle.

Intenté ver un artículo:

es legible Puedo ver el título, la navegación, la imagen destacada. Pero faltan el resto de imágenes del artículo:

Esto es de esperar, y se debe a las imágenes de carga diferida de la BBC. IE8 no es un 'navegador compatible' significa que no obtiene el JavaScript que permite la carga diferida, por lo que las imágenes nunca se cargan.

Por interés, pensé que vería qué sucede si intento acceder a BBC iPlayer:

Y eso me hizo preguntarme acerca de otro servicio de transmisión.

netflix

Casi esperaba una página en blanco vacía cuando cargué Netflix en IE8. Me sorprendió gratamente cuando vi una página de destino decente:

Comparé esto con la versión moderna de Chrome:

Hay una llamada a la acción ligeramente diferente (texto del botón), probablemente debido a pruebas multivariadas en lugar de en qué navegador estoy.

Lo que es diferente en el renderizado es el texto centralizado y la superposición negra semitransparente.

La falta de texto centralizado se debe al uso de Flexbox por parte de Netflix para alinear elementos:

Un text-align: center en esta clase probablemente arreglaría el centrado para IE8 (y de hecho todos los navegadores antiguos). Para obtener la máxima compatibilidad con el navegador, puede seguir un enfoque alternativo de CSS con CSS "seguro" antiguo y luego ajustar los diseños con CSS más moderno para los navegadores que lo admitan.

La falta de fondo se debe al uso de rgba() , que no es compatible con IE8 y versiones anteriores.

Tradicionalmente, es bueno proporcionar respaldos de CSS como este, que muestran un fondo negro para los navegadores antiguos pero muestran un fondo semitransparente para los navegadores modernos:

 rgb(0, 0, 0); /* IE8 fallback */ rgba(0, 0, 0, 0.8);

Esta es una solución muy específica de IE, sin embargo, básicamente todos los demás navegadores admiten rgba . Además, en este caso, perdería los elegantes mosaicos de Netflix por completo, por lo que sería mejor no tener ningún filtro de fondo. La forma segura de garantizar la compatibilidad entre navegadores sería incluir el filtro en la propia imagen de fondo. Simple pero efectivo.

De todos modos, hasta ahora, todo bien: ¡IE8 en realidad representó la página de inicio bastante bien! ¿Realmente voy a ver Breaking Bad en IE8 hoy?

Mi optimismo ya tentativo fue derribado inmediatamente cuando vi la página de inicio de sesión:

Aún así, pude iniciar sesión y vi un tablero reducido (sin remolques de expansión automática de lujo):

Hice clic en un programa con vaga anticipación, pero, por supuesto, solo vi una pantalla negra.

Amazonas

Ok, las redes sociales y el video están fuera. Todo lo que queda es ir de compras.

Revisé Amazon y quedé impresionado: es casi indistinguible de la experiencia que obtendrías dentro de un navegador moderno:

He sido atraído por una buena página de inicio antes. Entonces, hagamos clic en la página de un producto y veamos si esto es solo una casualidad.

¡No! ¡La página del producto también se veía bien!

Amazon no fue el único sitio que me sorprendió por su compatibilidad con versiones anteriores. Wikipedia se veía muy bien, al igual que el sitio web del gobierno Gov.UK. No es fácil tener un sitio que no parezca un accidente automovilístico total en IE8. ¡La mayoría de mis experiencias fueron decididamente menos pulidas...!

Pero un aviso de advertencia en desuso o un diseño original no fue lo peor que vi hoy.

Sitios completamente rotos

¡Algunos sitios estaban tan dañados que ni siquiera podía conectarme a ellos!

Me preguntaba si podría ser un problema temporal de la red de VM, pero sucedía cada vez que actualizaba la página, incluso cuando volvía al mismo sitio más tarde ese mismo día.

Esto sucedió en algunos sitios diferentes a lo largo del día, y finalmente llegué a la conclusión de que esto nunca afectó a los sitios en HTTP, solo en HTTPS (pero no en todos los sitios HTTPS). ¿Entonces, Cual fue el problema?

Usando Wireshark para analizar el tráfico de la red, intenté conectarme a GitHub nuevamente. Podemos ver que la conexión no se pudo establecer debido a un error fatal, "Descripción: Versión del protocolo".

Mirando la configuración predeterminada en IE8, solo TLS 1.0 está habilitado, pero GitHub dejó de admitir TLSv1 y TLSv1.1 en febrero de 2018.

Marqué las casillas de TLS 1.1 y TLS 1.2, volví a cargar la página y ¡listo! — ¡Pude ver GitHub!

Muchas gracias a mi extremadamente talentoso amigo Aidan Fewster por ayudarme a solucionar ese problema.

Estoy a favor de la compatibilidad con versiones anteriores, pero esto presenta un dilema interesante. Según el PCI Security Standards Council, TLS 1.0 no es seguro y ya no debe utilizarse. Pero al forzar TLS 1.1 o superior, algunos usuarios quedarán invariablemente bloqueados (y es probable que no todos sean lo suficientemente expertos en tecnología como para habilitar TLS 1.2 en su configuración avanzada).

Al permitir estándares más antiguos e inseguros y permitir que los usuarios continúen conectándose a nuestros sitios, no los estamos ayudando, los estamos perjudicando al no darles una razón para cambiar a tecnologías más seguras. Entonces, ¿hasta dónde debe llegar para admitir navegadores más antiguos?

¿Cómo puedo comenzar a admitir navegadores más antiguos?

Cuando algunas personas piensan en "soportar navegadores más antiguos", podrían estar pensando en esos viejos trucos patentados para IE, como esa vez que la BBC tuvo que hacer algunas cosas increíblemente retorcidas para admitir contenido iframed en IE7.

O pueden estar pensando en hacer que las cosas funcionen en el "modo peculiar" de Internet Explorer; un modo de operación específico de IE que hace que las cosas sean muy diferentes a los estándares.

Pero "soportar navegadores más antiguos" es muy diferente a "hackearlo para IE". No abogo por lo segundo, pero deberíamos tratar pragmáticamente de hacer lo primero. El mantra con el que trato de vivir como desarrollador web es este:

“Optimice para la mayoría, haga un esfuerzo por la minoría y nunca sacrifique la seguridad”.

Me alejaré del mundo de IE8 ahora y hablaré sobre soluciones generales y sostenibles para la compatibilidad con navegadores heredados.

Hay dos estrategias amplias para admitir navegadores más antiguos, ambas comienzan con P:

1. polirelleno
   Esfuércese por la paridad de funciones para todos completando la funcionalidad del navegador que falta.
2. Mejora progresiva
   Comience desde una experiencia central, luego use la detección de características para superponer la funcionalidad.

Estas estrategias no son mutuamente excluyentes entre sí; se pueden usar en tándem. Hay una serie de decisiones de implementación para tomar en cualquier enfoque, cada una con sus propios matices, que trataré con más detalle a continuación.

polirelleno

Para algunos sitios web o páginas web, JavaScript es muy importante para la funcionalidad y simplemente desea entregar JavaScript funcional a tantos navegadores como sea posible.

Hay varias maneras de hacer esto, pero primero, una lección de historia.

Una breve historia de ECMAScript

ECMAScript es un estándar y JavaScript es una implementación de ese estándar. Eso significa que ES5 es "ECMAScript versión 5" y ES6 es "ECMAScript versión 6". Confusamente, ES2015 es lo mismo que ES6.

ES6 era el nombre popularizado de esa versión antes de su lanzamiento, pero ES2015 es el nombre oficial y las versiones posteriores de ECMAScript están todas asociadas con su año de lanzamiento.

Nota : Todo esto está explicado de manera útil por Brandon Morelli en una excelente publicación de blog que explica la historia completa de las versiones de JavaScript.

Al momento de escribir, el último estándar es ES2018 (ES9). La mayoría de los navegadores modernos admiten al menos ES2015. Casi todos los navegadores son compatibles con ES5.

Técnicamente, IE8 no es ES5. Ni siquiera es ES4 (que no existe, el proyecto fue abandonado). IE8 usa la implementación de Microsoft de ECMAScript 3, llamada JScript. IE8 tiene algo de compatibilidad con ES5, pero se lanzó unos meses antes de que se publicaran los estándares de ES5, por lo que no coincide con la compatibilidad.

Transpiling vs Polyfilling

Puede escribir JavaScript ES5 y se ejecutará en casi todos los navegadores antiguos:

 var foo = function () { return 'this is ES5!'; };

También puede continuar escribiendo todo su JavaScript de esa manera, para habilitar la compatibilidad con versiones anteriores para siempre. Pero se perdería las nuevas funciones y el azúcar sintáctico que está disponible en las versiones en evolución de JavaScript, lo que le permite escribir cosas como:

 const foo = () => { return 'this is ES6!'; };

Intente ejecutar ese JavaScript en un navegador anterior y generará un error. Necesitamos transpilar el código a una versión anterior de JavaScript que el navegador entienda (es decir, convertir nuestro código ES6 en ES5, usando herramientas automatizadas).

Ahora digamos que nuestro código usa un método ES5 estándar, como Array.indexOf . La mayoría de los navegadores tienen una implementación nativa de esto y funcionarán bien, pero IE8 fallará. ¿Recuerda que IE8 se lanzó unos meses antes de que se publicaran los estándares ES5, por lo que no coincide con el soporte? Un ejemplo de eso es la función indexOf , que se ha implementado para String pero no para Array .

Si intentamos ejecutar el método Array.indexOf en IE8, fallará. Pero si ya estamos escribiendo en ES5, ¿qué más podemos hacer?

Podemos policompletar el comportamiento del método faltante. Los desarrolladores tradicionalmente completan cada función que necesitan copiando y pegando código, o extrayendo bibliotecas de relleno externo de terceros. Muchas funciones de JavaScript tienen buenas implementaciones de polyfill en sus respectivas páginas de MDN de Mozilla, pero vale la pena señalar que hay varias formas en las que puede polyfill la misma función.

Por ejemplo, para asegurarse de que puede usar el método Array.indexOf en IE8, copiaría y pegaría un polyfill como este:

 if (!Array.prototype.indexOf) { Array.prototype.indexOf = (function (Object, max, min) { // big chunk of code that replicates the behaviour in JavaScript goes here! // for full implementation, visit: // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/indexof#Polyfill })(Object, Math.max, Math.min); }

Siempre que llame al polyfill antes de extraer cualquiera de sus propios JS, y siempre que no use ninguna función de JavaScript ES5 que no sea Array.indexOf , su página funcionará en IE8.

Polyfills se puede usar para tapar todo tipo de funcionalidad faltante. Por ejemplo, hay polyfills para habilitar selectores CSS3 como :last-child (no admitido en IE8) o el atributo de placeholder de posición (no admitido en IE9).

Los polyfills varían en tamaño y efectividad y, a veces, dependen de bibliotecas externas como jQuery.

También puede oír hablar de "calzas" en lugar de "polyfills". No se obsesione demasiado con el nombre: la gente usa los dos términos indistintamente. Pero técnicamente hablando, un shim es un código que intercepta una llamada API y proporciona una capa de abstracción. Un polyfill es un tipo de calce , en el navegador . Utiliza específicamente JavaScript para actualizar las nuevas características de HTML/CSS/JS en navegadores más antiguos.

Resumen de la estrategia de "importación manual de polyfills":

• Control completo sobre la elección de polyfills;
• Adecuado para sitios web básicos;
• ️ Sin herramientas adicionales, se ve obligado a escribir en JavaScript ES5 nativo;
• ️ Difícil de microgestionar todos sus polyfills;
• ️ Desde el primer momento, todos sus usuarios obtendrán los polyfills, ya sea que los necesiten o no.

Babel polirelleno

He hablado sobre transpilar el código ES6 a ES5. Para ello, utilice un transpilador , el más popular de los cuales es Babel.

Babel se puede configurar a través de un archivo .babelrc en la raíz de su proyecto. En él, señala varios complementos y ajustes preestablecidos de Babel. Por lo general, hay uno para cada transformación de sintaxis y relleno múltiple del navegador que necesitará.

Microgestionarlos y mantenerlos sincronizados con la lista de soporte de su navegador puede ser una molestia, por lo que la configuración estándar hoy en día es delegar esa microgestión al módulo @babel/preset-env. Con esta configuración, simplemente le da a Babel una lista de versiones de navegador que desea admitir, y hace el trabajo duro por usted:

 { "presets": [ [ "@babel/preset-env", { "useBuiltIns": "usage", "targets": { "chrome": "58", "ie": "11" } } ] ] }

La opción de configuración useBuiltIns de @babel/preset-env es donde ocurre la magia, en combinación con una import "@babel/polyfill" (otro módulo) en el punto de entrada de su aplicación.

• Cuando se omite, useBuiltIns no hace nada. La totalidad de @babel/polyfill está incluida en su aplicación, que es bastante pesada.
• Cuando se establece en "entry" , convierte la importación de @babel/polyfill en importaciones múltiples y más pequeñas, importando los polyfills mínimos necesarios para polyfill en los navegadores específicos que ha enumerado en su .babelrc (en este ejemplo, Chrome 58 e IE 11) .
• La configuración en "usage" lleva esto un paso más allá al realizar un análisis de código y solo importar polyfills para las funciones que realmente se están utilizando . Está clasificado como "experimental", pero se equivoca en el lado de "demasiado relleno de plástico" en lugar de "demasiado poco". En cualquier caso, no veo cómo es posible que cree un paquete más grande que "entry" o false , por lo que es una buena opción para elegir (y es la forma en que vamos en la BBC).

Con Babel, puede transpilar y policompletar su JavaScript antes de implementarlo en producción y orientar el soporte en una línea de base mínima específica de navegadores. NB, otra herramienta popular es TypeScript, que tiene su propio transpilador que transpila a ES3, en teoría compatible con IE8 listo para usar.

Resumen del uso de @babel/preset-env para polirrelleno:

• Delegar la microgestión de polyfills a una herramienta;
• La herramienta automatizada ayuda a evitar la inclusión de polirellenos que no necesita;
• Escala a sitios más grandes y complejos;
• ️ Fuera de la caja, todos sus usuarios obtendrán los polyfills, ya sea que los necesiten o no;
• ️ Es difícil no perder de vista exactamente lo que se incluye en su paquete de aplicaciones.

Lazy Loading Polyfills con Webpack e importaciones dinámicas

Es posible aprovechar la nueva propuesta de import() para detectar características y descargar polyfills dinámicamente antes de inicializar su aplicación. Se ve algo como esto en la práctica:

 import app from './app.js'; const polyfills = []; if (!window.fetch) { polyfills.push(import(/* webpackChunkName: "polyfill-fetch" */ 'whatwg-fetch')); } Promise.all(polyfills) .then(app) .catch((error) => { console.error('Failed fetching polyfills', error); });

Este código de ejemplo se copia descaradamente del muy buen artículo, "Lazy Loading Polyfills With Webpack And Dynamic Imports" que profundiza en la técnica con más detalle.

Resumen:

• No satura los navegadores modernos con rellenos polifónicos innecesarios;
• ️ Requiere gestionar manualmente cada polifill.

polyfill.io

polyfill.io es polyfilling como servicio, creado por Financial Times. Funciona cuando su página realiza una solicitud de secuencia de comandos única a polyfill.io y, de manera opcional, enumera las características específicas que necesita para polyfill. Luego, su servidor analiza la cadena del agente de usuario y completa el script en consecuencia. Esto le evita tener que proporcionar manualmente sus propias soluciones de polirelleno.

Aquí está el JavaScript que polyfill.io devuelve para una solicitud realizada desde IE8:

Aquí está la misma solicitud de polyfill.io, pero de donde proviene la solicitud de Chrome moderno:

Todo lo que se requiere de su sitio es una sola llamada de secuencia de comandos.

Resumen:

• Facilidad de inclusión en su aplicación web;
• Delega la responsabilidad del conocimiento de polyfill a un tercero;
• ️ Por otro lado, ahora depende de un servicio de terceros;
• ️ Realiza una llamada <script> de bloqueo, incluso para navegadores modernos que no necesitan rellenos polifónicos.

Mejora progresiva

Polyfilling es una técnica increíblemente útil para admitir navegadores más antiguos, pero puede ser una exageración para las páginas web y tiene un alcance limitado.

La técnica de mejora progresiva, por otro lado, es una excelente manera de garantizar una experiencia básica para todos los navegadores, al tiempo que conserva la funcionalidad completa para sus usuarios en los navegadores modernos. Debería ser factible en la mayoría de los sitios.

El principio es este: comience desde una línea de base de HTML (y el estilo, opcional) y "mejore progresivamente" la página con la funcionalidad de JavaScript. El beneficio es que si el navegador es heredado, o si el JavaScript se rompe en algún momento de su entrega, su sitio aún debería funcionar.

El término "mejora progresiva" a menudo se usa indistintamente con "JavaScript discreto". Significan esencialmente lo mismo, pero el último va un poco más allá en el sentido de que no debe ensuciar su HTML con muchos atributos, ID y clases que solo usa su JavaScript.

Cortar-La-Mostaza

La técnica de la BBC de "cortar la mostaza" (CTM) es una implementación probada y comprobada de mejora progresiva. El principio es que usted escribe una sólida experiencia básica de HTML, y antes de descargar cualquier JavaScript mejorado, verifica un nivel mínimo de soporte. La implementación original comprobó la presencia de características estándar de HTML5:

 if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) { // Enhance for HTML5 browsers }

A medida que aparezcan nuevas funciones y los navegadores más antiguos se vuelvan cada vez más anticuados, nuestros cortes en la línea de base de mostaza cambiarán. Por ejemplo, la nueva sintaxis de JavaScript, como las funciones de flecha ES6, significaría que esta verificación de CTM en línea ni siquiera se analiza en los navegadores heredados, ni siquiera se ejecuta de manera segura y falla la verificación de CTM, por lo que puede tener efectos secundarios inesperados, como romper otros JavaScript de terceros. (por ejemplo, Google Analytics).

Para evitar incluso intentar analizar JS moderno no transpilado, podemos aplicar esta "interpretación moderna" de la técnica CTM, tomada del blog de @snugug, en la que aprovechamos el hecho de que los navegadores más antiguos no entienden el type="module" declaración y la omitirá de forma segura. Por el contrario, los navegadores modernos ignorarán las declaraciones <script nomodule> .

 <script type="module" src="./mustard.js"></script> <script nomodule src="./no-mustard.js"></script> <!-- Can be done inline too --> <script type="module"> import mustard from './mustard.js'; </script> <script nomodule type="text/javascript"> console.log('No Mustard!'); </script>

Este enfoque es bueno, siempre que esté satisfecho con el tratamiento de los navegadores ES6 como su nueva línea de base mínima para la funcionalidad (~92% de los navegadores globales en el momento de escribir este artículo).

Sin embargo, así como el mundo de JavaScript está evolucionando, también lo está haciendo el mundo de CSS. Ahora que tenemos variables Grid, Flexbox, CSS y similares (cada una con una eficacia variable de respaldo), no se sabe qué combinación de compatibilidad con CSS podría tener un navegador antiguo que podría conducir a una mezcla de "moderno" y "heredado". estilo, cuyo resultado parece roto. Por lo tanto, los sitios eligen cada vez más la CTM de su estilo , por lo que ahora HTML es la línea de base central, y tanto CSS como JS se tratan como mejoras.

Las técnicas de CTM basadas en JavaScript que hemos visto hasta ahora tienen un par de inconvenientes si usa la presencia de JavaScript para aplicar CSS de alguna manera:

1. JavaScript en línea está bloqueando. Los navegadores deben descargar, analizar y ejecutar su JavaScript antes de obtener cualquier estilo. Por lo tanto, los usuarios pueden ver un destello de texto sin estilo.
2. Algunos usuarios pueden tener navegadores modernos, pero eligen deshabilitar JavaScript. Un CTM basado en JavaScript les impide obtener un sitio con estilo incluso cuando son perfectamente capaces de obtenerlo.

El enfoque 'último' es utilizar consultas de medios CSS como su prueba de fuego definitiva. Esta técnica “CSSCTM” se usa activamente en sitios como Springer Nature.

 <head> <!-- CSS-based cuts-the-mustard --> <!-- IMPORTANT: the JS depends on having this rule somewhere in the CSS: `body { clear: both }` --> <link rel="stylesheet" href="mq-test.css" media="only screen and (min-resolution: 0.1dpcm), only screen and (-webkit-min-device-pixel-ratio:0) and (min-color-index:0)"> </head> <body> <!-- content here... --> <script> (function () { // wrap in an IIFE to prevent global scope pollution function isSupported () { var val = ''; if (window.getComputedStyle) { val = window.getComputedStyle(document.body, null).getPropertyValue('clear'); } else if (document.body.currentStyle) { val = document.body.currentStyle.clear; } if (val === 'both') { // references the `body { clear: both; }` in the CSS return true; } return false; } if (isSupported()) { // Load or run JavaScript for supported browsers here. } })(); </script> </body>

Este enfoque es bastante frágil: anular accidentalmente la propiedad clear en su selector de body "rompería" su sitio, pero ofrece el mejor rendimiento. Esta implementación en particular utiliza consultas de medios que solo son compatibles con al menos IE 9, iOS 7 y Android 4.4, que es una línea de base moderna bastante sensata.

“Corta la mostaza”, en todas sus diversas formas, cumple dos principios fundamentales:

1. Amplio apoyo al usuario;
2. Esfuerzo de desarrollo aplicado eficientemente.

Simplemente no es posible que los sitios se adapten a todas las combinaciones de navegador/sistema operativo/conexión de red/configuración de usuario. Técnicas como "cortes de mostaza" ayudan a racionalizar los navegadores en navegadores de grado C y grado A, de acuerdo con el modelo Graded Browser Support de Yahoo! .

Corta-La-Mostaza: ¿Un Anti-Patrón?

Existe el argumento de que aplicar una decisión binaria global de "básico" frente a "avanzado" no es la mejor experiencia posible para nuestros usuarios. Brinda cordura a un problema técnico desalentador, pero ¿qué sucede si un navegador admite el 90 % de las funciones en su prueba de CTM global y esta página específica ni siquiera utiliza el 10 % de las funciones en las que falla? En este caso, el usuario obtendría la experiencia principal, ya que la verificación de CTM habría fallado. Pero podríamos haberles dado la experiencia completa.

¿Y qué pasa con los casos en los que la página dada hace uso de una función que el navegador no admite? Bueno, en el movimiento hacia la creación de componentes, podríamos tener un respaldo específico de la función (o límite de error), en lugar de un respaldo a nivel de página.

Hacemos esto todos los días en nuestro desarrollo web. Piense en extraer una fuente web; diferentes navegadores tienen diferentes niveles de soporte de fuentes. qué hacemos? Proporcionamos algunas variaciones de archivos de fuentes y dejamos que el navegador decida cuál descargar:

 @font-face { font-family: FontName; src: url('path/filename.eot'); src: url('path/filename.eot?#iefix') format('embedded-opentype'), url('path/filename.woff2') format('woff2'), url('path/filename.woff') format('woff'), url('path/filename.ttf') format('truetype'); }

Tenemos un respaldo similar con el video HTML5. Los navegadores modernos elegirán qué formato de video quieren usar, mientras que los navegadores heredados que no entienden qué es un elemento <video> simplemente mostrarán el texto alternativo:

 <video width="400" controls> <source src="mov_bbb.mp4" type="video/mp4"> <source src="mov_bbb.ogg" type="video/ogg"> Your browser does not support HTML5 video. </video>

El enfoque de anidamiento que vimos anteriormente utilizado por la BBC para los respaldos de PNG para SVG es la base para el elemento de imagen sensible <picture> . Los navegadores modernos mostrarán la imagen que mejor se ajuste según el atributo de media suministrado, mientras que los navegadores heredados que no entienden qué es un elemento <picture> mostrarán el recurso alternativo <img> .

 <picture> <source media="(min-width: 650px)"> <source media="(min-width: 465px)"> <img src="img_orange_flowers.jpg" alt="Flowers"> </picture>

La especificación HTML ha evolucionado cuidadosamente a lo largo de los años para proporcionar un mecanismo alternativo básico para todos los navegadores, al tiempo que permite funciones y optimizaciones para los navegadores modernos que las entienden.

Podríamos aplicar un principio similar a nuestro código JavaScript. Imagine una característica como esta, donde el método foo contiene algo de JS complejo:

 class Feature { browserSupported() { return ('querySelector' in document); // internal cuts-the-mustard goes here } foo() { // etc } } export default new Feature();

Antes de llamar a foo , verificamos si la función es compatible con este navegador llamando a su método browserSupported . Si no es compatible, ni siquiera intentamos llamar al código que, de lo contrario, habría generado un error en nuestra página.

 import Feature from './feature'; if (Feature.browserSupported()) { Feature.foo(); }

Esta técnica significa que podemos evitar la extracción de polyfills y simplemente usar lo que cada navegador admite de forma nativa, degradando con gracia las características individuales si no son compatibles.

Tenga en cuenta que en el ejemplo anterior, asumo que el código se transpila a ES5 para que todos los navegadores entiendan la sintaxis , pero no asumo que parte del código está polillenado . Si quisiéramos evitar la transpilación del código, podríamos aplicar el mismo principio pero usando la versión type="module" de cortes de mostaza, pero viene con la advertencia de que ya tiene un requisito mínimo de navegador ES6, por lo que es solo Es probable que comience a ser una buena solución en un par de años:

 <script type="module"> import Feature from './feature.js'; if (Feature.browserSupported()) { Feature.foo(); } </script>

Hemos cubierto HTML y hemos cubierto JavaScript. También podemos aplicar alternativas localizadas en CSS; hay una palabra clave @supports en CSS, que le permite aplicar CSS de forma condicional en función de la presencia o ausencia de soporte para una característica de CSS. Sin embargo, irónicamente se le advierte que no es universalmente compatible. Solo necesita una aplicación cuidadosa; hay una excelente publicación de blog de Mozilla sobre cómo usar consultas de características en CSS.

En un mundo ideal, no deberíamos necesitar un cheque global de cortes de mostaza. En su lugar, cada característica individual de HTML, JS o CSS debe ser independiente y tener sus propios límites de error. En un mundo de componentes web, shadow DOM y elementos personalizados, espero que veamos un mayor cambio hacia este tipo de enfoque. Pero hace que sea mucho más difícil predecir y probar su sitio como un todo, y puede haber efectos secundarios no deseados si, por ejemplo, el estilo de un componente afecta el diseño de otro.

Dos estrategias principales de compatibilidad con versiones anteriores

Un resumen del polyfilling como estrategia :

• Puede ofrecer la funcionalidad JS del lado del cliente a la mayoría de los usuarios.
• Puede ser más fácil de codificar cuando se delega el problema de la compatibilidad con versiones anteriores a un polyfill.
• ️ Según la implementación, podría ser perjudicial para el rendimiento de los usuarios que no necesitan polyfills.
• ️ Según la complejidad de la aplicación y la antigüedad del navegador, es posible que se requieran muchos rellenos polivalentes y, por lo tanto, funcione muy mal. Corremos el riesgo de enviar megabytes de polyfills a los navegadores menos preparados para aceptarlo.

Un resumen de la mejora progresiva como estrategia :

• El CTM tradicional facilita la segmentación de su código y la prueba manual.
• Base de experiencia garantizada para todos los usuarios.
• ️ Podría entregar innecesariamente la experiencia principal a los usuarios que podrían manejar la experiencia avanzada.
• ️ No es adecuado para sitios que requieren JS del lado del cliente para su funcionalidad.
• ️ A veces es difícil equilibrar una estrategia robusta de mejora progresiva con un primer renderizado de alto rendimiento. Existe el riesgo de priorizar en exceso la experiencia "principal" en detrimento del 90 % de los usuarios que obtienen la experiencia "completa" (p. ej., proporcionar imágenes pequeñas para noJS y luego reemplazarlas con imágenes de alta resolución en carga diferida significa que he desperdiciado mucha capacidad de descarga en activos que ni siquiera se ven).

Conclusión

IE8 fue una vez un navegador de vanguardia. (No, en serio). Lo mismo podría decirse de Chrome y Firefox hoy.

Si los sitios web de hoy son totalmente inutilizables en IE8, es probable que los sitios web dentro de diez años sean igualmente inutilizables en los navegadores modernos de hoy, a pesar de estar construidos sobre las tecnologías abiertas de HTML, CSS y JavaScript.

Detente y piensa en eso por un momento. ¿No da un poco de miedo? (Dicho esto, si no puede abandonar los navegadores después de diez años y después de que la empresa que lo creó lo haya dejado obsoleto, ¿cuándo podrá hacerlo?)

IE8 es el chivo expiatorio de hoy. Mañana será IE9, el próximo año será Safari, un año después podría ser Chrome. Puede cambiar IE8 por el 'navegador antiguo de su elección'. El punto es que siempre habrá alguna división entre los navegadores para los que crean los desarrolladores y los navegadores que usa la gente. Deberíamos dejar de burlarnos de eso y comenzar a invertir en soluciones de ingeniería sólidas e inclusivas . Los efectos secundarios de estas estrategias tienden a pagar dividendos en términos de accesibilidad, rendimiento y resiliencia de la red, por lo que aquí hay un panorama más amplio en juego.

Tendemos a no pensar en los números de lectores de pantalla. Simplemente damos por sentado que es moralmente correcto hacer todo lo posible para apoyar a los usuarios que no tienen otra forma de consumir nuestro contenido, sin culpa nuestra. El mismo principio se aplica a las personas que utilizan navegadores más antiguos.

Hemos cubierto algunas estrategias de alto nivel para crear sitios sólidos que deberían continuar funcionando, hasta cierto punto, en un amplio espectro de navegadores heredados y modernos.

Una vez más, un descargo de responsabilidad: no piratee cosas para IE. Eso sería perder el punto. Pero tenga en cuenta que todo tipo de personas usan todo tipo de navegadores por todo tipo de razones, y que existen algunos enfoques de ingeniería sólidos que podemos tomar para hacer que la web sea accesible para todos.

Optimice para la mayoría, haga un esfuerzo por la minoría y nunca sacrifique la seguridad.

Lectura adicional en SmashingMag:

• Estándares web: el qué, el por qué y el cómo
• Empaquetado inteligente: cómo servir código heredado solo a navegadores heredados
• No use el atributo de marcador de posición
• Diseñando para una web sin navegador