In vrijwel elke versie van Chrome zien we een aanzienlijk aantal updates en verbeteringen aan het product, de prestaties en ook de mogelijkheden van het webplatform.
In Chrome 49 (bètaversie 2 februari 2016. Geschatte stabiele datum: maart 2016) zijn er een aantal wijzigingen in Chrome
Het gebruik van het voorvoegsel "css" in getComputedStyle(e).cssX is verouderd
TL;DR : Het gebruik van het voorvoegsel "css" in getComputedStyle(e) is verouderd omdat het geen deel uitmaakte van de formele specificatie .
getComputedStyle is een geweldige kleine functie. Het retourneert alle CSS-waarden van de stijlen van het DOM-element zoals berekend door de rendering engine. Je kunt bijvoorbeeld getComputedStyle(_someElement_).height uitvoeren en het retourneert mogelijk 224,1 px, omdat dat de hoogte is van het element zoals het momenteel wordt weergegeven.
Het lijkt een behoorlijk handige API. Wat veranderen we?
Voordat de rendering engine van Chrome overschakelde naar Blink, werd deze aangestuurd door WebKit. Daarmee kon je "css" aan het begin van een eigenschap toevoegen. Bijvoorbeeld getComputedStyle(e).cssHeight in plaats van getComputedStyle(e).height . Beide gaven dezelfde gegevens terug omdat ze aan dezelfde onderliggende waarden waren gekoppeld. Maar juist dit gebruik van het "css"-voorvoegsel is niet standaard en is verouderd en verwijderd.
Let op: cssFloat is een standaard eigenschap en wordt niet beïnvloed door deze veroudering.
Als u op deze manier een eigenschap benadert in Chrome 49, wordt undefined geretourneerd en moet u uw code aanpassen.
Het gebruik van initTouchEvent is verouderd
TL;DR : initTouchEvent is verouderd en vervangen door de TouchEvent constructor om de specificatie-naleving te verbeteren. Deze constructor wordt volledig verwijderd in Chrome 54.
Intentie om het CRBug-probleem van Chromestatus Tracker te verwijderen
U kunt al lange tijd synthetische aanraakgebeurtenissen in Chrome aanmaken met behulp van de initTouchEvent API. Deze worden vaak gebruikt om aanraakgebeurtenissen te simuleren, bijvoorbeeld voor het testen of automatiseren van de gebruikersinterface van uw site. In Chrome 49 hebben we deze API afgeschaft en geven we de volgende waarschuwing weer met de intentie deze volledig te verwijderen in Chrome 53.
Er zijn een aantal redenen waarom deze wijziging goed is . Hij staat ook niet in de Touch Events-specificatie. De Chrome-implementatie van initTouchEvent was helemaal niet compatibel met Safari's initTouchEvent API en verschilde van die van Firefox op Android. Tot slot is de TouchEvent constructor veel gebruiksvriendelijker.
Er is besloten dat we de specificatie zullen volgen in plaats van een API te onderhouden die noch gespecificeerd noch compatibel is met de enige andere implementatie. Daarom zullen we eerst de initTouchEvent -functie afschaffen en vervolgens verwijderen en ontwikkelaars verplichten de TouchEvent constructor te gebruiken.
Deze API wordt wel gebruikt op het web, maar we weten dat deze door een relatief klein aantal sites wordt gebruikt. Daarom verwijderen we deze niet zo snel als normaal. We vermoeden dat een deel van het gebruik niet werkt omdat sites de Chrome-versie van de handtekening niet gebruiken.
Omdat de iOS- en Android/Chrome-implementaties van de initTouchEvent API zo enorm van elkaar verschilden, had je vaak code in de trant van (en vergat vaak 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);
Ten eerste is dit slecht, omdat het in de user-agent naar "Android" zoekt en Chrome op Android deze veroudering zal herkennen en tegenkomen. Het kan echter nog niet worden verwijderd, omdat er nog een tijdje andere WebKit- en oudere Blink-gebaseerde browsers op Android zullen zijn die de oudere API moeten ondersteunen.
Om TouchEvents op het web correct te verwerken, moet u uw code aanpassen om Firefox, IE Edge en Chrome te ondersteunen. Controleer hiervoor of TouchEvent aanwezig is in het window . Als het object een positieve "lengte" heeft (wat aangeeft dat het een constructor is die een argument accepteert), moet u dat gebruiken.
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);
Fout- en succeshandlers vereist in RTCPeerConnection-methoden
TL;DR: De WebRTC RTCPeerConnection-methoden createOffer() en createAnswer() vereisen nu zowel een error handler als een success handler. Voorheen was het mogelijk om deze methoden aan te roepen met alleen een success handler. Dit gebruik is verouderd.
In Chrome 49 hebben we ook een waarschuwing toegevoegd als je setLocalDescription() of setRemoteDescription() aanroept zonder een error handler mee te geven. We verwachten het error handler-argument verplicht te maken voor deze methoden in Chrome 50.
Dit maakt deel uit van het vrijmaken van de weg voor het introduceren van beloftes op deze methoden, zoals vereist door de WebRTC-specificatie .
Hier is een voorbeeld uit de WebRTC RTCPeerConnection-demo ( main.js, regel 126 ):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Houd er rekening mee dat zowel setLocalDescription() als setRemoteDescription() altijd een parameter voor de foutafhandeling hebben. Het opgeven van die parameter is dus een veilige wijziging.
Over het algemeen raden we u aan om voor WebRTC-productietoepassingen adapter.js te gebruiken. Dit is een shim die wordt onderhouden door het WebRTC-project. Hiermee kunt u apps beschermen tegen specificatiewijzigingen en prefixverschillen.
Document.defaultCharset is verouderd
TL;DR : Document.defaultCharset is verouderd om de specificatienaleving te verbeteren.
Intentie om het CRBug-probleem van Chromestatus Tracker te verwijderen
Document.defaultCharset is een alleen-lezen eigenschap die de standaardtekencodering van het systeem van de gebruiker retourneert op basis van de regionale instellingen. Het is niet zinvol gebleken deze waarde te behouden vanwege de manier waarop browsers de tekencoderingsinformatie gebruiken in de HTTP-respons of in de metatag die in de pagina is ingesloten.
Door document.characterSet te gebruiken, krijgt u de eerste waarde die in de HTTP-header is opgegeven. Als deze niet aanwezig is, krijgt u de waarde die is opgegeven in het charset attribuut van het <meta> -element (bijvoorbeeld <meta charset="utf-8"> ). Als geen van deze beschikbaar is, wordt document.characterSet de systeeminstelling van de gebruiker.
Gecko ondersteunt deze eigenschap niet en deze is niet duidelijk gespecificeerd. Deze eigenschap wordt daarom niet meer ondersteund in Blink in Chrome 49 (bètaversie in januari 2016). De volgende waarschuwing verschijnt in uw console totdat de eigenschap in Chrome 50 is verwijderd:
Meer informatie over de redenering om dit niet te specificeren is te lezen op github https://github.com/whatwg/dom/issues/58
getStorageUpdates() verwijderd
TL;DR : Navigator.getStorageUpdates() is verwijderd omdat het niet langer in de Navigator-specificatie staat.
Intentie om het CRBug-probleem van Chromestatus Tracker te verwijderen
Als dit iemand overkomt, eet ik mijn hoed op. getStorageUpdates() is nauwelijks (of helemaal niet) gebruikt op het web.
Om de (zeer oude versie) van de HTML5-specificatie te citeren:
Klinkt best cool, toch? De specificatie gebruikt zelfs het woord "whence" (wat toevallig de enige keer is dat whence in de specificatie voorkomt). Op specificatieniveau was er een StorageMutex die de toegang tot blokkerende opslag, zoals localStorage en cookies, regelde, en deze API zou die mutex vrijgeven, zodat andere scripts niet door deze StorageMutex zouden worden geblokkeerd. Maar het is nooit geïmplementeerd, het wordt niet ondersteund in IE of Gecko, en de implementatie van WebKit (en dus ook die van Blink) is een no-op gebleken.
Het is al een tijdje uit de specificaties verwijderd en is zelfs volledig uit Blink verwijderd (het was lange tijd een no-op en deed niets, zelfs niet als het werd aangeroepen).
In het onwaarschijnlijke geval dat u code hebt die navigator.getStorageUpdates() aanroept, moet u controleren of de functie aanwezig is voordat u deze aanroept.
Object.observe() is verouderd
TL;DR : Object.observe() is verouderd omdat het niet langer op het standaardisatiepad staat en zal in een toekomstige release worden verwijderd.
Intentie om het CRBug-probleem van Chromestatus Tracker te verwijderen
In november 2015 werd aangekondigd dat Object.Observe uit TC39 zou worden verwijderd . Het is verouderd in Chrome 49 en u ziet de volgende waarschuwing in de console als u het probeert te gebruiken:
Veel ontwikkelaars zijn enthousiast over deze API. Als u ermee hebt geëxperimenteerd en nu op zoek bent naar een overgangspad, overweeg dan om een polyfill te gebruiken, zoals MaxArt2501/object-observe of een wrapperbibliotheek zoals polymer/observe-js .