Bajas y eliminaciones de APIs en Chrome 50

En casi todas las versiones de Chrome, vemos una cantidad significativa de actualizaciones y mejoras del producto, su rendimiento y las capacidades de la plataforma web.

En Chrome 50 (fecha beta estimada: del 10 al 17 de marzo), hay una serie de cambios en Chrome. Esta lista está sujeta a cambios en cualquier momento.

AppCache obsoleta en contextos no seguros

Resumen: Para dificultar la secuencia de comandos entre sitios, Daremos de baja AppCache en orígenes inseguros. Esperamos que en Chrome 52 solo funcione en orígenes que entreguen contenido a través de HTTPS.

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

AppCache es una función que permite el acceso persistente y sin conexión a un origen, lo que constituye una potente elevación de privilegios para un ataque de secuencia de comandos entre sitios. Como parte de un esfuerzo mayor para quitar funciones potentes en orígenes inseguros.

Para quitar este vector de ataque, Chrome solo lo permite a través de HTTPS. La compatibilidad con HTTP dejará de estar disponible en Chrome 50 y esperamos quitarla por completo en Chrome 52.

Se quitó Document.defaultCharset.

Resumen: Se quitó document.defaultCharset para mejorar el cumplimiento de las especificaciones.

Intent de quitar | Seguimiento de Chromestatus | Problema de CRBug

document.defaultCharset, que dejó de estar disponible en Chrome 49, es una propiedad de solo lectura que muestra la codificación de caracteres predeterminada del sistema del usuario según su configuración regional. No se ha resultado útil mantener este valor debido a la forma en que los navegadores usan la información de codificación de caracteres en la respuesta HTTP o en la metaetiqueta incorporada en la página.

En su lugar, usa document.characterSet para obtener el primer valor especificado en el encabezado HTTP. Si ese valor no está presente, obtendrás el valor especificado en el atributo charset del elemento <meta> (por ejemplo, <meta charset="utf-8">). Por último, si ninguno de ellos está disponible, document.characterSet será la configuración del sistema del usuario.

Puedes leer más sobre el razonamiento de no especificar esto en este problema de GitHub.

Resumen: Quita la compatibilidad con el valor subresource del atributo rel de HTMLLinkElement.

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

El intent del atributo subresource en <link> era precargar un recurso durante el tiempo de inactividad de un navegador. Después de que un navegador descarga una página, podía descargar previamente recursos, como otras páginas, para que, cuando los usuarios los solicitaran, simplemente se los pudiera recuperar de la caché del navegador.

El atributo subresource presentó varios problemas. Primero, nunca funcionó según lo previsto. Los recursos de referencia se descargaron con baja prioridad. El atributo nunca se implementó en ningún navegador que no sea Chrome. La implementación de Chrome tuvo un error que provocó que los recursos se descargaran dos veces.

Los desarrolladores que buscan mejorar la experiencia del usuario mediante la precarga del contenido tienen varias opciones. La más personalizable es compilar un service worker para aprovechar el almacenamiento previo en caché y la API de Caches. Las soluciones adicionales incluyen otros valores para el atributo rel, como preconnect, prefetch, preload y prerender. Algunas de estas opciones son experimentales y es posible que no sean ampliamente compatibles.

Quita el resguardo de las versiones de TLS no seguras

Resumen: Quita un mecanismo para obligar a los servidores a mostrar datos con versiones de TLS menos seguras o no seguras.

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

La seguridad de la capa de transporte (TLS) admite un mecanismo para negociar versiones, lo que permite la incorporación de nuevas versiones de TLS sin afectar la compatibilidad. Algunos servidores implementaron esto de tal manera que los navegadores tenían que usar extremos inseguros como resguardo. Debido a esto, los atacantes podrían forzar cualquier sitio web, no solo los que están mal configurados, a negociar versiones más débiles de TLS.

Los sitios afectados no podrán conectarse con ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION. Los administradores deben asegurarse de que el software del servidor esté actualizado. Si el problema persiste, comunícate con el proveedor de software del servidor para ver si hay una solución disponible.

Se quitó KeyboardEvent.prototype.keyLocation.

TL;DR: Quita un alias innecesario para el atributo Keyboard.prototype.location.

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

Este atributo es simplemente un alias del atributo Keyboard.prototype.location, que permite la desambiguación entre teclas ubicadas en varias ubicaciones en un teclado. Por ejemplo, ambos atributos permiten a los desarrolladores distinguir entre las dos teclas Enter en un teclado extendido.

Se requieren controladores de errores y éxito en los métodos de RTCPeerConnection

TL;DR: Los métodos createOffer() y createAnswer() de WebRTC RTCPeerConnection ahora requieren un controlador de errores y uno de éxito. Anteriormente, era posible llamar a estos métodos solo con un controlador de éxito. Ese uso dejó de estar disponible.

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

En Chrome 49, agregamos una advertencia si llamas a setLocalDescription() o setRemoteDescription() sin proporcionar un controlador de errores. El argumento del controlador de errores es obligatorio a partir de Chrome 50.

Esto forma parte de despejar el camino para introducir promesas en estos métodos, según lo requiere la especificación de WebRTC.

Este es un ejemplo de la demostración de RTCPeerConnection de WebRTC (main.js, línea 126):

    function onCreateOfferSuccess(desc) {
      pc1.setLocalDescription(desc, function() {
         onSetLocalSuccess(pc1);
      }, onSetSessionDescriptionError);
      pc2.setRemoteDescription(desc, function() {
        onSetRemoteSuccess(pc2);
      }, onSetSessionDescriptionError);
      pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
    }

Ten en cuenta que setLocalDescription() y setRemoteDescription() tienen un controlador de errores. Los navegadores más antiguos que solo esperan un controlador de éxito simplemente ignoran el argumento del controlador de errores si está presente. Llamar a este código en un navegador anterior no causará una excepción.

En general, para las aplicaciones WebRTC de producción, recomendamos que uses adapter.js, una corrección de compatibilidad, que mantiene el proyecto de WebRTC, para aislar las apps de los cambios de especificaciones y las diferencias de prefijos.

Ya no se admite XMLHttpRequestProgressEvent.

Resumen: Se quitará la interfaz XMLHttpRequestProgressEvent, junto con los atributos position y totalSize.

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

Este evento existió para admitir las propiedades de compatibilidad de Gecko position y totalSize. La compatibilidad con los tres se quitó en Mozilla 22 y la funcionalidad fue reemplazada por mucho tiempo por ProgressEvent.

     var progressBar = document.getElementById("p"),
          client = new XMLHttpRequest()
      client.open("GET", "magical-unicorns")
      client.onprogress = function(pe) {
        if(pe.lengthComputable) {
          progressBar.max = pe.total
          progressBar.value = pe.loaded
        }
      }

Quitar las extensiones de medios encriptados con prefijo

Resumen: Se quitaron las extensiones de medios encriptados con prefijos para reemplazar un reemplazo basado en especificaciones y sin prefijo.

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

En Chrome 42, lanzamos una versión basada en especificaciones y sin prefijo de las extensiones de medios encriptadas. Esta API se usa para descubrir sistemas de administración de derechos digitales, además de interactuar con ellos, y seleccionarlos para usarlos con HTMLMediaElement.

Eso fue hace casi un año. Y como la versión sin prefijo tiene más capacidades que la versión con prefijo, es hora de quitar la versión con prefijo de la API.

Se quitó la compatibilidad con las propiedades SVGElement.offset.

TL;DR: Se descartaron las propiedades de desplazamiento de SVGElement y se reemplazaron por las propiedades más compatibles en HTMLElement.

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

Desde hace mucho tiempo, las propiedades de desplazamiento son compatibles con HTMLElement y SVGElement. Sin embargo, Gecko y Edge solo las admiten en HTMLElement. Para mejorar la coherencia entre los navegadores, estas propiedades dejaron de estar disponibles en Chrome 48 y se quitarán.

Si bien las propiedades equivalentes son parte de HTMLElement, los desarrolladores que buscan una alternativa también pueden usar getBoundingClientRect()