En casi todas las versiones de Chrome, vemos una cantidad significativa de actualizaciones y mejoras en el producto, su rendimiento y las capacidades de la plataforma web.
En Chrome 49 (Beta, 2 de febrero de 2016. Fecha estable estimada: marzo de 2016) se realizaron 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, ya que no formaba parte de la especificación formal.
getComputedStyle es una pequeña función excelente. Devolverá todos los valores de CSS de los estilos del elemento DOM tal como los calculó el motor de renderización. Por ejemplo, podrías ejecutar getComputedStyle(_someElement_).height y podría devolver 224.1 px porque esa es la altura del elemento tal 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, lo que te permitía agregar el prefijo "css" al comienzo de una propiedad. Por ejemplo, getComputedStyle(e).cssHeight en lugar de getComputedStyle(e).height.
Ambas devolverían los mismos datos, ya que se asignaron a los mismos valores subyacentes, pero este uso del prefijo "css" no es estándar, se dejó de usar y se quitó.
Nota: cssFloat es una propiedad estándar y esta baja no la afecta.
Si accedes a una propiedad de esta manera en Chrome 49, se devolverá undefined y deberás corregir tu código.
El uso de initTouchEvent dejó de estar disponible
TL;DR:
initTouchEvent
quedó obsoleta y se reemplazó por
TouchEvent
constructor para mejorar
el cumplimiento de las especificaciones y se quitará por completo en Chrome 54.
Intención de quitar Seguimiento de Chromestatus Problema de CRBug
Durante mucho tiempo, pudiste crear eventos táctiles sintéticos en Chrome con la API de initTouchEvent, que se usa con frecuencia para simular eventos táctiles, ya sea para probar o automatizar alguna IU en tu sitio. En Chrome 49, marcamos esta API como obsoleta y mostraremos la siguiente advertencia con la intención de quitarla por completo en Chrome 53.
Existen varios motivos por los que este cambio es positivo.
Tampoco se encuentra en la especificación de Touch Events. La implementación de initTouchEvent de Chrome no era compatible con la API de initTouchEvent de Safari y era diferente a la de Firefox en Android. Por último, el constructor TouchEvent es mucho más fácil de usar.
Se decidió que intentaremos seguir la especificación en lugar de mantener una API que no esté especificada ni sea compatible con la única otra implementación.
Por lo tanto, primero dejaremos de usar la función initTouchEvent y, luego, la quitaremos. Además, exigiremos a los desarrolladores que usen el constructor TouchEvent.
Hay uso de esta API en la Web, pero sabemos que la usa una cantidad relativamente baja de sitios, por lo que no la quitaremos tan rápido como lo haríamos normalmente. Creemos que parte del uso no funciona debido a que los sitios no controlan la versión de la firma de Chrome.
Debido a que las implementaciones de la API de initTouchEvent para iOS y Android/Chrome eran tan diferentes, a menudo tenías código similar a (y, con frecuencia, olvidabas 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 porque busca "Android" en el encabezado User-Agent, y Chrome en Android coincidirá y alcanzará esta baja. Sin embargo, aún no se puede quitar, ya que habrá otros navegadores basados en WebKit y Blink más antiguos en Android durante un tiempo, por lo que aún deberás admitir la API anterior.
Para 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 usarlo.
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 de éxito en los métodos de RTCPeerConnection
Resumen: Los métodos WebRTC RTCPeerConnection createOffer() y createAnswer() ahora requieren un controlador de errores y un controlador 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 del proceso para allanar el camino a la introducción de promesas en estos métodos, como lo requiere la especificación de WebRTC.
A continuación, se muestra 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 de WebRTC de producción, recomendamos que uses adapter.js, un polyfill mantenido por el proyecto de WebRTC, para aislar las apps de los cambios en las especificaciones y las diferencias de prefijos.
Document.defaultCharset dejó de estar disponible
Resumen: Se dejó de usar Document.defaultCharset para mejorar el cumplimiento de las especificaciones.
Intención de quitar Seguimiento de Chromestatus Problema de CRBug
Document.defaultCharset es una propiedad de solo lectura que devuelve la codificación de caracteres predeterminada del sistema del usuario según su configuración regional. No se ha considerado ú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.
Si usas document.characterSet, obtendrás el primer valor especificado en el encabezado HTTP. Si 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 esos está disponible, document.characterSet será la configuración del sistema del usuario.
Gecko no admite esta propiedad y no se especifica con claridad, por lo que se dará de baja en Blink en Chrome 49 (beta en enero de 2016). La siguiente advertencia aparecerá en la consola hasta que se quite la propiedad en Chrome 50:
Puedes leer más sobre los motivos para 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.
Intención de quitar Seguimiento de Chromestatus Problema de CRBug
Si esto afecta a alguien, me comeré mi sombrero. getStorageUpdates() casi nunca se usó en la Web.
Para citar la (versión muy antigua) de la especificación de HTML5:
Suena genial, ¿verdad? La especificación incluso usa la palabra "procedencia" (que, por casualidad, es la única instancia de procedencia en la especificación). A nivel de la especificación, había un StorageMutex que controlaba el acceso al almacenamiento de bloqueo, como localStorage y las cookies, y esta API ayudaría a liberar ese mutex para que otros scripts no se bloquearan con este StorageMutex. Sin embargo, nunca se implementó, no es compatible con IE ni Gecko, y la implementación de WebKit (y, por lo tanto, de Blink) no ha tenido efecto.
Se quitó de las especificaciones hace bastante tiempo y se quitó por completo de Blink (durante mucho tiempo, no hizo nada, incluso si se llamaba).
En el improbable caso de que tuvieras código que llamara a navigator.getStorageUpdates(), deberás verificar la presencia de la función antes de llamarla.
Object.observe() dejó de estar disponible
TL;DR: Object.observe() dejó de estar disponible porque ya no está en la pista de estandarización y se quitará en una versión futura.
Intención de quitar Seguimiento de Chromestatus Problema de CRBug
En noviembre de 2015, se anunció que Object.Observe se retiraría de TC39. Se dejó de usar en Chrome 49, y verás la siguiente advertencia en la consola si intentas usarlo:
A muchos desarrolladores les gustó esta API, y si la has probado y ahora buscas una ruta de transición, considera usar un polyfill como MaxArt2501/object-observe o una biblioteca de wrapper como polymer/observe-js.