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 49 (versión beta 2 de febrero de 2016. fecha estable estimada: marzo de 2016) hay varios cambios en Chrome
El uso del prefijo "css" en getComputedStyle(e).cssX dejó de estar disponible.
TL;DR: El uso del prefijo “css” en getComputedStyle(e) dejó de estar disponible porque no formaba parte de la spec formal.
getComputedStyle es una pequeña función excelente. Se mostrarán todos los valores de CSS de los estilos del elemento del DOM tal como los haya calculado el motor de renderización. Por ejemplo, puedes ejecutar getComputedStyle(_someElement_).height, que podría mostrar 224.1 px porque esa es la altura del elemento como se muestra actualmente.
Parece una API bastante útil. ¿Qué cambiará?
Antes de que el motor de renderización de Chrome cambiara a Blink, funcionaba con WebKit y eso te permitía agregar prefijos "css" al inicio de una propiedad. Por ejemplo, getComputedStyle(e).cssHeight en lugar de getComputedStyle(e).height.
Ambas mostrarían los mismos datos a medida que se asignaron a los mismos valores subyacentes, pero es este uso del prefijo "css" el que no es estándar y se dio de baja y se quitó.
Nota: cssFloat es una propiedad estándar y no se ve afectada por esta baja.
Si accedes a una propiedad de esta manera en Chrome 49, se mostrará undefined y deberás corregir el código.
El uso de initTouchEvent dejó de estar disponible.
Resumen: initTouchEvent dejó de estar disponible y se reemplazó por TouchEvent
constructor para mejorar el cumplimiento de las especificaciones y se quitará por completo en Chrome 54.
Intent de eliminación Seguimiento de Chromestatus Error de error de CR
Durante mucho tiempo, pudiste crear eventos táctiles sintéticos en Chrome con la API de initTouchEvent, que con frecuencia se usan para simular eventos táctiles con el objetivo de probar o automatizar algunas IU en tu sitio. En Chrome 49, esta API se dio de baja y se mostrará la siguiente advertencia con la intención de quitarla por completo en Chrome 53.
Existen varios motivos por los que este cambio es útil.
Tampoco está en la especificación de Touch Events. La implementación de Chrome de initTouchEvent no era compatible en absoluto con la API de initTouchEvent de Safari y era diferente a Firefox en Android. Por último, el constructor TouchEvent es mucho más fácil de usar.
Se decidió que nuestro objetivo es seguir la especificación en lugar de mantener una API que no se especifique ni sea compatible con la única otra implementación.
Por lo tanto, primero daremos de baja y, luego, quitaremos la función initTouchEvent, y los desarrolladores deberán usar el constructor TouchEvent.
Esta API sí se usa en la Web, pero sabemos que una cantidad relativamente baja de sitios la usa, por lo que no la quitaremos tan rápido como debería. Creemos que parte del uso no funciona debido a que los sitios no manejan la versión de la firma de Chrome.
Como las implementaciones de la API de initTouchEvent para iOS y Android/Chrome eran tan diferentes que, a menudo, tendrías código similar al (a menudo olvidamos Firefox).
var event = document.createEvent('TouchEvent');
if(ua === 'Android') {
event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
300, 300, 200, 200, false, false, false, false);
} else {
event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
200, false, false, false, false, touches, targetTouches, changedTouches, 0, 0);
}
document.body.dispatchEvent(touchEvent);
En primer lugar, esto es malo, ya que busca "Android" en el usuario-agente, y Chrome en Android coincidirá y se dará de baja. Sin embargo, todavía no se puede quitar, dado que habrá otros navegadores basados en WebKit y Blink anteriores en Android por un tiempo, y deberás admitir la API anterior.
A fin de controlar correctamente TouchEvents en la Web, debes cambiar tu código para que admita Firefox, IE Edge y Chrome. Para ello, verifica la existencia de TouchEvent en el objeto window y, si tiene una "longitud" positiva (lo que indica que es un constructor que toma un argumento), debes usar eso.
if('TouchEvent' in window && TouchEvent.length > 0) {
var touch = new Touch({
identifier: 42,
target: document.body,
clientX: 200,
clientY: 200,
screenX: 300,
screenY: 300,
pageX: 200,
pageY: 200,
radiusX: 5,
radiusY: 5
});
event = new TouchEvent("touchstart", {
cancelable: true,
bubbles: true,
touches: [touch],
targetTouches: [touch],
changedTouches: [touch]
});
}
else {
event = document.createEvent('TouchEvent');
if(ua === 'Android') {
event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
300, 300, 200, 200, false, false, false, false);
} else {
event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
200, false, false, false, false, touches, targetTouches,
changedTouches, 0, 0);
}
}
document.body.dispatchEvent(touchEvent);
Se requieren controladores de errores y éxito en los métodos de RTCPeerConnection
Resumen: 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.
En Chrome 49, también agregamos una advertencia si llamas a setLocalDescription() o setRemoteDescription() sin proporcionar un controlador de errores. Esperamos que el argumento del controlador de errores sea obligatorio para estos métodos en Chrome 50.
Esto forma parte de despejar el camino para introducir promesas en estos métodos, según se requiere en las especificaciones 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() siempre tuvieron un parámetro de controlador de errores, por lo que especificar ese parámetro es un cambio seguro.
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.
Document.defaultCharset dejó de estar disponible
Resumen: Document.defaultCharset dejó de estar disponible para mejorar el cumplimiento de las especificaciones.
Intent de eliminación Seguimiento de Chromestatus Error de error de CR
Document.defaultCharset 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 utilizan la información de codificación de caracteres en la respuesta HTTP o en la metaetiqueta incorporada en la página.
Si usas document.characterSet, obtendrás el primer valor especificado en el encabezado HTTP. Si eso 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.
Gecko no es compatible con esta propiedad y no está especificada correctamente, por lo que dejará de estar disponible en Blink en Chrome 49 (versión beta en enero de 2016). La siguiente advertencia aparecerá en tu consola hasta que se quite la propiedad en Chrome 50:
Puedes leer más información sobre el razonamiento de no especificar esto en GitHub: https://github.com/whatwg/dom/issues/58.
Se quitó getStorageUpdates()
TL;DR: Se quitó Navigator.getStorageUpdates() porque ya no está en la especificación de Navigator.
Intent de eliminación Seguimiento de Chromestatus Error de error de CR
Si esto afecta a alguien, me comeré mi sombrero. getStorageUpdates() casi nunca (si es que lo hace) se usa en la Web.
Para citar la versión (versión muy antigua) de la especificación HTML5, haz lo siguiente:
Suena genial, ¿verdad? La especificación incluso usa la palabra "whence" (que, por hecho, es la única instancia del lugar en la especificación). En el nivel de especificaciones, había una StorageMutex que controlaba el acceso al almacenamiento de bloqueo, como localStorage y cookies, y esta API ayudaría a liberar esa exclusión mutua para que este StorageMutex no bloqueara otras secuencias de comandos. Sin embargo, nunca se implementó, no es compatible con IE ni Gecko, y la implementación de WebKit (y, por lo tanto, la de Blink) ha sido una no-op.
Se quitó de las especificaciones durante bastante tiempo y se quitó por completo de Blink (durante mucho tiempo, no funcionó ni hizo nada, incluso si se llamaba).
En el caso improbable de que tuvieras un código que llamaba a navigator.getStorageUpdates(),
deberás verificar la presencia de la función antes de llamarla.
Object.observa() dejó de estar disponible
Resumen: Object.observe() dejó de estar disponible porque ya no se encuentra en el segmento de estandarización y se quitará en una versión futura.
Intent de eliminación Seguimiento de Chromestatus Error de error de CR
En noviembre de 2015, se anunció que se retiró Object.Observe de TC39. Dado que dejó de estar disponible en Chrome 49, verás la siguiente advertencia en la consola si intentas usarla:
A muchos desarrolladores les gustó esta API y, si has estado experimentando con ella y ahora buscas una ruta de transición, considera usar un polyfill como MaxArt2501/object-observa o una biblioteca de wrapper como polymer/observe-js.