In fast jeder Version von Chrome gibt es eine beträchtliche Anzahl von Updates und Verbesserungen des Produkts, seiner Leistung und auch der Funktionen der Webplattform.
In Chrome 49 (Beta, 2. Februar 2016) Geschätztes Datum für die stabile Version: März 2016) gibt es eine Reihe von Änderungen an Chrome.
Die Verwendung des Präfix „css“ in „getComputedStyle(e).cssX“ ist veraltet.
Kurzfassung: Die Verwendung des Präfixes „css“ in
getComputedStyle(e)
wurde eingestellt, da es nicht Teil der formalen Spezifikation war.
getComputedStyle ist eine tolle kleine Funktion. Es werden alle CSS-Werte der Stile des DOM-Elements zurückgegeben, wie sie von der Rendering-Engine berechnet wurden. Wenn Sie beispielsweise getComputedStyle(_someElement_).height ausführen, wird möglicherweise 224,1 px zurückgegeben, da dies die Höhe des Elements ist, wie es derzeit angezeigt wird.
Das ist eine sehr praktische API. Was ändert sich?
Bevor die Rendering-Engine von Chrome auf Blink umgestellt wurde, wurde sie von WebKit unterstützt. Dadurch konnten Sie einer Eigenschaft das Präfix „css“ voranstellen. Beispiel: getComputedStyle(e).cssHeight statt getComputedStyle(e).height.
Beide würden dieselben Daten zurückgeben, da sie denselben zugrunde liegenden Werten zugeordnet sind. Die Verwendung des Präfixes „css“ ist jedoch nicht standardmäßig und wurde eingestellt und entfernt.
Hinweis: cssFloat ist eine Standard-Property und ist von dieser Einstellung nicht betroffen.
Wenn Sie in Chrome 49 auf diese Weise auf eine Eigenschaft zugreifen, wird undefined zurückgegeben und Sie müssen Ihren Code korrigieren.
Die Verwendung von „initTouchEvent“ ist veraltet
Kurzfassung:
initTouchEvent
wurde zugunsten von
TouchEvent
constructor eingestellt, um die
Spezifikationskonformität zu verbessern, und wird in Chrome 54 vollständig entfernt.
Absicht zur Entfernung Chromestatus-Tracker CRBug-Problem
Lange Zeit konnten Sie in Chrome mit der initTouchEvent API synthetische Touch-Ereignisse erstellen. Diese werden häufig verwendet, um Touch-Ereignisse entweder zum Testen oder zum Automatisieren einer Benutzeroberfläche auf Ihrer Website zu simulieren. In Chrome 49 haben wir diese API eingestellt und zeigen die folgende Warnung an. In Chrome 53 soll sie vollständig entfernt werden.
Es gibt eine Reihe von Gründen, warum diese Änderung sinnvoll ist.
Sie ist auch nicht in der Touch Events-Spezifikation enthalten. Die Chrome-Implementierung von initTouchEvent war überhaupt nicht mit der initTouchEvent API von Safari kompatibel und unterschied sich von der von Firefox unter Android. Und schließlich ist der TouchEvent-Konstruktor viel einfacher zu verwenden.
Wir haben uns entschieden, uns an die Spezifikation zu halten, anstatt eine API zu pflegen, die weder spezifiziert noch mit der einzigen anderen Implementierung kompatibel ist.
Daher stellen wir die initTouchEvent-Funktion zuerst ein und entfernen sie dann. Entwickler müssen den TouchEvent-Konstruktor verwenden.
Diese API wird im Web verwendet, aber wir wissen, dass sie nur von einer relativ geringen Anzahl von Websites genutzt wird. Daher entfernen wir sie nicht so schnell wie sonst. Wir gehen jedoch davon aus, dass ein Teil der Nutzung aufgrund von Websites, die die Chrome-Version der Signatur nicht verarbeiten, nicht funktioniert.
Da die iOS- und Android-/Chrome-Implementierungen der initTouchEvent API so unterschiedlich waren, hatten Sie oft Code wie diesen (wobei Firefox häufig vergessen wurde):
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);
Erstens ist das schlecht, weil im User-Agent nach „Android“ gesucht wird und Chrome unter Android übereinstimmt und diese Einstellung erreicht. Sie kann jedoch noch nicht entfernt werden, da es auf Android noch eine Weile andere Browser auf Basis von WebKit und älteren Blink-Versionen geben wird, für die Sie die alte API weiterhin unterstützen müssen.
Damit TouchEvents im Web korrekt verarbeitet wird, sollten Sie Ihren Code so ändern, dass Firefox, IE Edge und Chrome unterstützt werden. Prüfen Sie dazu, ob TouchEvent im window-Objekt vorhanden ist. Wenn es eine positive „Länge“ hat (was darauf hindeutet, dass es sich um einen Konstruktor handelt, der ein Argument akzeptiert), sollten Sie es verwenden.
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);
Fehler- und Erfolgshandler in RTCPeerConnection-Methoden erforderlich
Kurzfassung:Für die WebRTC-RTCPeerConnection-Methoden createOffer() und createAnswer() sind jetzt sowohl ein Fehler- als auch ein Erfolgs-Handler erforderlich. Bisher war es möglich, diese Methoden nur mit einem Success-Handler aufzurufen. Diese Verwendung ist veraltet.
In Chrome 49 haben wir außerdem eine Warnung hinzugefügt, die angezeigt wird, wenn Sie setLocalDescription() oder setRemoteDescription() ohne Angabe eines Fehler-Handlers aufrufen. Wir gehen davon aus, dass das Argument für den Fehler-Handler in Chrome 50 für diese Methoden obligatorisch wird.
Dies ist Teil der Vorbereitung für die Einführung von Promises für diese Methoden, wie in der WebRTC-Spezifikation gefordert.
Hier ein Beispiel aus der WebRTC RTCPeerConnection-Demo (main.js, Zeile 126):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Sowohl setLocalDescription() als auch setRemoteDescription() hatten immer einen Fehler-Handler-Parameter. Die Angabe dieses Parameters ist also eine sichere Änderung.
Im Allgemeinen empfehlen wir für WebRTC-Produktionsanwendungen die Verwendung von adapter.js, einem Shim, der vom WebRTC-Projekt verwaltet wird, um Apps vor Spezifikationsänderungen und Präfixunterschieden zu schützen.
Document.defaultCharset ist veraltet
Kurzfassung: Document.defaultCharset wurde eingestellt, um die Einhaltung der Spezifikationen zu verbessern.
Absicht zur Entfernung Chromestatus-Tracker CRBug-Problem
Document.defaultCharset ist eine schreibgeschützte Eigenschaft, die die Standardzeichencodierung des Systems des Nutzers basierend auf seinen regionalen Einstellungen zurückgibt. Es hat sich herausgestellt, dass es nicht sinnvoll ist, diesen Wert beizubehalten, da Browser die Informationen zur Zeichencodierung in der HTTP-Antwort oder im Meta-Tag auf der Seite verwenden.
Mit document.characterSet erhalten Sie den ersten Wert, der im HTTP-Header angegeben ist. Wenn das nicht vorhanden ist, wird der Wert verwendet, der im Attribut charset des Elements <meta> angegeben ist (z. B. <meta charset="utf-8">). Wenn keines dieser Elemente verfügbar ist, wird document.characterSet als Systemeinstellung des Nutzers verwendet.
Gecko hat diese Eigenschaft nicht unterstützt und sie ist nicht sauber spezifiziert. Daher wird diese Eigenschaft in Blink in Chrome 49 (Beta im Januar 2016) eingestellt. Die folgende Warnung wird in der Console angezeigt, bis die Eigenschaft in Chrome 50 entfernt wird:
Weitere Informationen zur Begründung, warum dies nicht spezifiziert werden soll, finden Sie auf GitHub unter https://github.com/whatwg/dom/issues/58.
getStorageUpdates() entfernt
Kurzfassung: Navigator.getStorageUpdates() wurde entfernt, da es nicht mehr in der Navigator-Spezifikation enthalten ist.
Absicht zur Entfernung Chromestatus-Tracker CRBug-Problem
Wenn das jemanden betrifft, fresse ich meinen Hut. getStorageUpdates() wurde im Web kaum oder gar nicht verwendet.
In der (sehr alten Version) der HTML5-Spezifikation heißt es:
Das klingt ziemlich cool, oder? In der Spezifikation wird sogar das Wort „whence“ verwendet (das zufällig die einzige Stelle ist, an der „whence“ in der Spezifikation vorkommt). Auf Spezifikationsebene gab es ein StorageMutex, das den Zugriff auf blockierenden Speicher wie localStorage und Cookies steuerte. Diese API würde helfen, dieses Mutex freizugeben, damit andere Skripts nicht durch dieses StorageMutex blockiert werden. Sie wurde jedoch nie implementiert, wird in IE oder Gecko nicht unterstützt und die Implementierung von WebKit (und damit von Blink) war ein No-Op.
Sie wurde schon vor einiger Zeit aus den Spezifikationen entfernt und ist nun auch vollständig aus Blink entfernt worden. Sie war schon lange ein No-Op und hat auch bei Aufruf nichts bewirkt.
Im unwahrscheinlichen Fall, dass Sie Code hatten, der navigator.getStorageUpdates() aufgerufen hat, müssen Sie vor dem Aufrufen der Funktion prüfen, ob sie vorhanden ist.
Object.observe() ist veraltet
Kurzfassung: Object.observe() wurde eingestellt, da es nicht mehr standardisiert wird und in einer zukünftigen Version entfernt wird.
Absicht zur Entfernung Chromestatus-Tracker CRBug-Problem
Im November 2015 wurde bekannt gegeben, dass Object.Observe von TC39 zurückgezogen wird. Sie wurde in Chrome 49 eingestellt. Wenn Sie sie verwenden, wird in der Konsole die folgende Warnung angezeigt:
Viele Entwickler haben diese API gemocht. Wenn Sie damit experimentiert haben und nun nach einem Übergangspfad suchen, sollten Sie ein Polyfill wie MaxArt2501/object-observe oder eine Wrapper-Bibliothek wie polymer/observe-js verwenden.