Dans presque toutes les versions de Chrome, nous constatons un nombre important de mises à jour et d'améliorations apportées au produit, à ses performances et aux fonctionnalités de la plate-forme Web.
Dans Chrome 49 (version bêta du 2 février 2016) : (date de sortie de la version stable estimée : mars 2016). Un certain nombre de modifications ont été apportées à Chrome.
L'utilisation du préfixe "css" dans getComputedStyle(e).cssX est obsolète
En bref : L'utilisation du préfixe "css" dans getComputedStyle(e) est obsolète, car il ne faisait pas partie de la spécification formelle.
getComputedStyle est une petite fonction très utile. Elle renvoie toutes les valeurs CSS des styles de l'élément DOM telles qu'elles ont été calculées par le moteur de rendu. Par exemple, vous pouvez exécuter getComputedStyle(_someElement_).height et obtenir 224,1 px, car il s'agit de la hauteur de l'élément tel qu'il est actuellement affiché.
Il semble que ce soit une API très pratique. Qu'est-ce qui change ?
Avant que le moteur de rendu de Chrome ne passe à Blink, il était alimenté par WebKit, ce qui vous permettait de préfixer "css" au début d'une propriété. Par exemple, getComputedStyle(e).cssHeight au lieu de getComputedStyle(e).height.
Les deux renverraient les mêmes données, car ils sont mappés sur les mêmes valeurs sous-jacentes. Toutefois, c'est l'utilisation du préfixe "css" qui n'est pas standard, et qui a été abandonnée et supprimée.
Remarque : cssFloat est une propriété standard et n'est pas concernée par cet abandon.
Si vous accédez à une propriété de cette manière dans Chrome 49, la valeur undefined sera renvoyée et vous devrez corriger votre code.
L'utilisation de initTouchEvent est obsolète
En bref :
initTouchEvent
a été abandonné au profit de
TouchEvent
constructor pour améliorer
la conformité aux spécifications et sera complètement supprimé dans Chrome 54.
Intention de suppression Outil de suivi Chromestatus Problème CRBug
Depuis longtemps, vous pouvez créer des événements tactiles synthétiques dans Chrome à l'aide de l'API initTouchEvent. Ils sont fréquemment utilisés pour simuler des événements tactiles, que ce soit pour tester ou automatiser une partie de l'UI de votre site. Dans Chrome 49, nous avons abandonné cette API et afficherons l'avertissement suivant dans l'intention de la supprimer complètement dans Chrome 53.
Il existe plusieurs raisons pour lesquelles ce changement est positif.
Elle ne figure pas non plus dans la spécification des événements tactiles. L'implémentation initTouchEvent de Chrome n'était pas du tout compatible avec l'API initTouchEvent de Safari et était différente de celle de Firefox sur Android. Enfin, le constructeur TouchEvent est beaucoup plus facile à utiliser.
Nous avons décidé de suivre la spécification plutôt que de maintenir une API qui n'est ni spécifiée ni compatible avec la seule autre implémentation.
Par conséquent, nous allons d'abord abandonner la fonction initTouchEvent, puis la supprimer. Les développeurs devront utiliser le constructeur TouchEvent.
Cette API est utilisée sur le Web, mais nous savons qu'elle l'est par un nombre relativement faible de sites. Nous ne la supprimons donc pas aussi rapidement que nous le ferions normalement. Nous pensons qu'une partie de l'utilisation est interrompue, car les sites ne gèrent pas la version de la signature de Chrome.
Étant donné que les implémentations iOS et Android/Chrome de l'API initTouchEvent étaient très différentes, vous aviez souvent du code du type suivant (en oubliant souvent 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);
Tout d'abord, c'est une mauvaise pratique, car elle recherche "Android" dans l'User-Agent. Chrome sur Android correspondra et atteindra cette obsolescence. Toutefois, vous ne pouvez pas encore le supprimer, car d'autres navigateurs basés sur WebKit et d'anciennes versions de Blink seront disponibles sur Android pendant un certain temps. Vous devrez donc toujours prendre en charge l'ancienne API.
Pour gérer correctement TouchEvents sur le Web, vous devez modifier votre code pour qu'il soit compatible avec Firefox, IE Edge et Chrome. Pour ce faire, vérifiez l'existence de TouchEvent sur l'objet window. Si sa "longueur" est positive (ce qui indique qu'il s'agit d'un constructeur qui accepte un argument), vous devez l'utiliser.
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);
Gestionnaires d'erreurs et de réussite requis dans les méthodes RTCPeerConnection
En bref : Les méthodes createOffer() et createAnswer() de WebRTC RTCPeerConnection nécessitent désormais un gestionnaire d'erreurs ainsi qu'un gestionnaire de réussite. Auparavant, il était possible d'appeler ces méthodes avec un seul gestionnaire de réussite. Cette utilisation est obsolète.
Dans Chrome 49, nous avons également ajouté un avertissement si vous appelez
setLocalDescription()
ou setRemoteDescription()
sans fournir de gestionnaire d'erreurs. Nous prévoyons de rendre l'argument du gestionnaire d'erreurs obligatoire pour ces méthodes dans Chrome 50.
Cela permet de préparer l'introduction de promesses sur ces méthodes, comme l'exige la spécification WebRTC.
Voici un exemple tiré de la démonstration RTCPeerConnection de WebRTC (main.js, ligne 126) :
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Notez que setLocalDescription() et setRemoteDescription() ont toujours eu un paramètre de gestion des erreurs. Il est donc sûr de simplement spécifier ce paramètre.
En général, pour les applications WebRTC de production, nous vous recommandons d'utiliser adapter.js, un shim géré par le projet WebRTC, pour isoler les applications des modifications de spécifications et des différences de préfixes.
Document.defaultCharset est obsolète
Résumé : Document.defaultCharset a été abandonné pour améliorer la conformité aux spécifications.
Intention de suppression Outil de suivi Chromestatus Problème CRBug
Document.defaultCharset est une propriété en lecture seule qui renvoie l'encodage de caractères par défaut du système de l'utilisateur en fonction de ses paramètres régionaux. Il n'a pas été jugé utile de conserver cette valeur en raison de la façon dont les navigateurs utilisent les informations d'encodage des caractères dans la réponse HTTP ou dans la balise Meta intégrée à la page.
En utilisant document.characterSet, vous obtiendrez la première valeur spécifiée dans l'en-tête HTTP. Si ce n'est pas le cas, vous obtiendrez la valeur spécifiée dans l'attribut charset de l'élément <meta> (par exemple, <meta charset="utf-8">). Enfin, si aucune de ces valeurs n'est disponible, document.characterSet correspondra au paramètre système de l'utilisateur.
Gecko n'a jamais pris en charge cette propriété, et elle n'est pas spécifiée de manière claire. Elle sera donc obsolète dans Blink à partir de Chrome 49 (bêta en janvier 2016). L'avertissement suivant s'affichera dans votre console jusqu'à la suppression de la propriété dans Chrome 50 :
Pour en savoir plus sur les raisons pour lesquelles cette fonctionnalité n'est pas spécifiée, consultez la page GitHub https://github.com/whatwg/dom/issues/58.
Suppression de getStorageUpdates()
En bref : Navigator.getStorageUpdates() a été supprimé, car il ne figure plus dans la spécification Navigator.
Intention de suppression Outil de suivi Chromestatus Problème CRBug
Si cela a une incidence sur qui que ce soit, je mangerai mon chapeau. getStorageUpdates() n'a presque jamais été utilisé sur le Web.
Pour citer la (très ancienne version) de la spécification HTML5 :
Plutôt cool, non ? La spécification utilise même le mot "whence" (qui, par hasard, est la seule instance de "whence" dans la spécification). Au niveau de la spécification, il existait un StorageMutex qui contrôlait l'accès au stockage bloquant tel que localStorage et les cookies. Cette API permettrait de libérer ce mutex afin que d'autres scripts ne soient pas bloqués par ce StorageMutex. Mais elle n'a jamais été implémentée, n'est pas prise en charge dans IE ni dans Gecko, et l'implémentation de WebKit (et donc de Blink) n'a jamais fonctionné.
Elle a été supprimée des spécifications depuis un certain temps et a été complètement supprimée de Blink (elle n'avait plus aucun effet depuis longtemps, même si elle était appelée).
Dans le cas peu probable où vous auriez du code qui appelle navigator.getStorageUpdates(), vous devrez vérifier la présence de la fonction avant de l'appeler.
Object.observe() est obsolète
En bref : Object.observe() est obsolète, car il n'est plus en cours de normalisation et sera supprimé dans une prochaine version.
Intention de suppression Outil de suivi Chromestatus Problème CRBug
En novembre 2015, il a été annoncé que Object.Observe serait retiré de TC39. Il a été abandonné dans Chrome 49. L'avertissement suivant s'affiche dans la console si vous essayez de l'utiliser :
De nombreux développeurs ont apprécié cette API. Si vous l'avez testée et que vous cherchez maintenant une méthode de transition, envisagez d'utiliser un polyfill tel que MaxArt2501/object-observe ou une bibliothèque wrapper telle que polymer/observe-js.