Dans presque chaque version de Chrome, un grand nombre de mises à jour et d'améliorations ont été 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 stabilité estimée: mars 2016), plusieurs modifications sont apportées à Chrome.
L'utilisation du préfixe "css" dans getComputedStyle(e).cssX est obsolète.
Résumé: L'utilisation du préfixe "css" dans getComputedStyle(e) est obsolète, car elle ne faisait pas partie de la spec formelle.
getComputedStyle est une excellente petite fonction. Il renvoie toutes les valeurs CSS des styles de l'élément DOM tels qu'ils ont été calculés par le moteur de rendu. Par exemple, vous pouvez exécuter getComputedStyle(_someElement_).height et renvoyer 224,1 px, car il s'agit de la hauteur de l'élément tel qu'il est actuellement affiché.
Cette API semble très pratique. Alors, que changeons-nous ?
Avant que le moteur de rendu de Chrome ne passe à Blink, il était fourni par WebKit et permettait d'ajouter le préfixe "css" au début d'une propriété. Par exemple, getComputedStyle(e).cssHeight au lieu de getComputedStyle(e).height.
Les deux renvoient les mêmes données qu'elles sont mappées avec les mêmes valeurs sous-jacentes, mais cette utilisation du préfixe "css" est non standard et 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, elle renvoie undefined, et vous devez corriger votre code.
Utilisation d'initTouchEvent obsolète
Résumé : initTouchEvent a été abandonné au profit de TouchEvent
constructor pour améliorer la conformité des spécifications. Cet élément sera entièrement supprimé dans Chrome 54.
Intention de suppression Outil de suivi de l'état Chrome Problème CRBug
Pendant longtemps, vous pouviez 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 certaines interfaces utilisateur de votre site. Dans Chrome 49, nous avons abandonné cette API. Nous afficherons l'avertissement suivant dans le but de la supprimer complètement dans Chrome 53.
Ce changement est bénéfique pour plusieurs raisons.
Elle ne figure pas non plus dans la spécification des événements tactiles. L'implémentation Chrome de initTouchEvent n'était pas du tout compatible avec l'API initTouchEvent de Safari et était différente de Firefox sur Android. Enfin, le constructeur TouchEvent est beaucoup plus facile à utiliser.
Il a été décidé de respecter les spécifications plutôt que de gérer une API qui n'est ni spécifiée, ni compatible avec l'autre implémentation.
Par conséquent, nous allons d'abord abandonner, puis supprimer la fonction initTouchEvent, et demander aux développeurs d'utiliser le constructeur TouchEvent.
Cette API est utilisée sur le Web, mais nous savons qu'elle est utilisée par un nombre relativement faible de sites. Nous ne la supprimons donc pas aussi rapidement que d'habitude. Nous pensons qu'une partie de l'utilisation n'est pas optimale, car des sites ne gèrent pas la version de la signature de Chrome.
Comme les implémentations iOS et Android/Chrome de l'API initTouchEvent étaient très différentes, vous auriez souvent du code similaire à celui de (on oubliait fréquemment 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, ce n'est pas le cas, car il recherche "Android" dans le user-agent et Chrome sur Android correspondra à cet abandon. Il n'est pas encore possible de la supprimer, car d'autres navigateurs WebKit et d'anciens navigateurs basés sur Blink sur Android resteront compatibles avec l'ancienne API pendant un certain temps.
Pour gérer correctement TouchEvents sur le Web, vous devez modifier votre code afin 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 (indiquant qu'il s'agit d'un constructeur qui accepte un argument), utilisez-la.
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
Résumé:Les méthodes RTCCPeerConnection WebRTC createOffer() et createAnswer() nécessitent désormais un gestionnaire d'erreurs ainsi qu'un gestionnaire de réussite. Auparavant, il était possible d'appeler ces méthodes uniquement avec un 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 d'éliminer le moyen d'introduire des promesses sur ces méthodes, comme l'exige la spécification WebRTC.
Voici un exemple tiré de la démonstration RTCCPeerConnection 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() comportent toujours un paramètre de gestionnaire d'erreurs. Par conséquent, il est préférable de spécifier simplement ce paramètre comme une modification sûre.
En général, pour les applications WebRTC en 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é des spécifications.
Intention de suppression Outil de suivi de l'état Chrome Problème CRBug
Document.defaultCharset est une propriété en lecture seule qui renvoie l'encodage des caractères par défaut du système de l'utilisateur en fonction de ses paramètres régionaux. Il s'avère qu'il n'est pas utile de conserver cette valeur en raison de la manière 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 obtenez 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 options n'est disponible, document.characterSet sera le paramètre système de l'utilisateur.
Gecko n'est pas compatible avec cette propriété et n'est pas correctement spécifiée. Elle sera donc abandonnée de Blink dans 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 le raisonnement de ne pas spécifier cette méthode, consultez GitHub à l'adresse https://github.com/whatwg/dom/issues/58.
Suppression de getStorageUpdates()
Résumé: Navigator.getStorageUpdates() a été supprimé, car il ne figure plus dans la spécification du navigateur.
Intention de suppression Outil de suivi de l'état Chrome Problème CRBug
Si cela concerne quelqu'un, je vais manger mon chapeau. getStorageUpdates() n'a jamais été utilisé sur le Web (voire aucune).
Pour citer l'ancienne version de la spécification HTML5:
Plutôt cool, non ? La spécification utilise même le mot "whence" (qui est la seule instance de moment dans la spécification). Au niveau de la spécification, une StorageMutex contrôlait l'accès au stockage bloquant tel que localStorage et les cookies. Cette API permettrait de libérer ce mutex afin que les autres scripts ne soient pas bloqués par cette StorageMutex. Mais il n'a jamais été implémenté, n'est pas pris en charge dans IE ni Gecko, et l'implémentation de WebKit (et donc de Blink) est une opération no-op.
Elle a été supprimée des spécifications depuis un certain temps et complètement supprimée de Blink (pendant la très longue période, il s'agissait d'une opération no-op et n'a rien donné, même s'il était appelé).
Dans le cas peu probable où vous possédiez 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
Résumé: Object.observe() est obsolète, car il n'est plus sur le canal de standardisation et sera supprimé dans une prochaine version.
Intention de suppression Outil de suivi de l'état Chrome Problème CRBug
En novembre 2015, il a été annoncé que Object.Observe allait être retiré de TC39. Elle est obsolète depuis Chrome 49 et l'avertissement suivant s'affichera dans la console si vous essayez de l'utiliser:
De nombreux développeurs ont apprécié cette API. Si vous l'avez expérimentée et que vous recherchez maintenant un chemin de transition, envisagez d'utiliser un polyfill comme MaxArt2501/object-observe ou une bibliothèque de wrappers comme polymer/observe-js.