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 (Betaversion: 2. Februar 2016. Voraussichtliches stabiles Datum: März 2016).
Die Verwendung des Präfixes „css“ in getComputedStyle(e).cssX wurde eingestellt
TL;DR: Die Verwendung des Präfixes „css“ in getComputedStyle(e) wurde eingestellt, da es nicht Teil der formalen spec war.
getComputedStyle ist eine tolle kleine Funktion. Es werden alle CSS-Werte der Stile des DOM-Elements zurückgegeben, so wie sie vom Rendering-Modul berechnet wurden. Wenn Sie beispielsweise getComputedStyle(_someElement_).height ausführen, wird möglicherweise „224,1px“ zurückgegeben, da dies die Höhe des Elements ist, wie es gerade angezeigt wird.
Es scheint recht praktisch zu sein. Was ändert sich also?
Bevor das Rendering-Modul von Chrome in Blink geändert wurde, wurde es von WebKit betrieben, mit dem Sie dem Anfang einer Property das Präfix "css" voranstellen konnten. Beispiel: getComputedStyle(e).cssHeight anstelle von getComputedStyle(e).height.
Beide würden dieselben Daten zurückgeben, wie sie den gleichen zugrunde liegenden Werten zugeordnet sind. Die Verwendung des Präfixes "css" ist jedoch nicht Standard und wurde verworfen und entfernt.
Hinweis: cssFloat ist eine Standard-Property und von dieser Einstellung nicht betroffen.
Wenn Sie in Chrome 49 auf diese Weise auf eine Property zugreifen, wird undefined zurückgegeben und Sie müssen Ihren Code korrigieren.
Die Verwendung von initTouchEvent wurde eingestellt
Zusammenfassung: initTouchEvent wurde zugunsten von TouchEvent
constructor eingestellt, um die Compliance der Spezifikationen zu verbessern. In Chrome 54 wird es vollständig entfernt.
Entfernungsabsicht Chromestatus Tracker CRBug-Problem
Schon seit Langem ist es möglich, in Chrome mithilfe der initTouchEvent API synthetische Touch-Ereignisse zu erstellen. Diese werden häufig verwendet, um Touch-Ereignisse zu simulieren, entweder zum Testen oder zum Automatisieren einer UI auf Ihrer Website. In Chrome 49 haben wir diese API eingestellt. In Chrome 53 wird die folgende Warnung angezeigt, um sie vollständig zu entfernen.
Es gibt eine Reihe von Gründen, warum diese Änderung gut ist.
Er entspricht auch nicht der Spezifikation für Touch-Ereignisse. Die Chrome-Implementierung von initTouchEvent war überhaupt nicht mit der initTouchEvent API von Safari kompatibel und unterschied sich von Firefox unter Android. Außerdem ist der TouchEvent-Konstruktor viel einfacher zu verwenden.
Es wurde beschlossen, die Spezifikation zu befolgen und keine API beizubehalten, die weder spezifiziert noch mit der einzigen anderen Implementierung kompatibel ist.
Daher wird die Funktion initTouchEvent zuerst eingestellt und dann entfernt. Entwickler müssen dann den TouchEvent-Konstruktor verwenden.
Diese API wird im Internet verwendet, aber wir wissen, dass sie von relativ wenigen Websites verwendet wird. Deshalb entfernen wir sie nicht so schnell, wie es normalerweise der Fall wäre. Wir gehen davon aus, dass einige Funktionen nicht genutzt werden können, weil Websites nicht die Chrome-Version der Signatur verarbeiten.
Da sich die iOS- und Android/Chrome-Implementierungen der initTouchEvent API so stark voneinander unterscheiden, haben Sie häufig Code entsprechend erstellt (und Firefox wurde häufig vergessen).
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: Das ist nicht gut, weil im User-Agent nach „Android“ gesucht wird und Chrome unter Android übereinstimmt und diese Einstellung erreicht wird. Es kann jedoch noch nicht entfernt werden, da es unter Android noch eine Zeit lang andere WebKit- und ältere Blink-basierte Browser gibt, in denen die ältere API unterstützt werden muss.
Damit TouchEvents im Web richtig verarbeitet werden kann, müssen Sie Ihren Code so ändern, dass er Firefox, IE Edge und Chrome unterstützt. Prüfen Sie dazu, ob im Objekt window das Objekt TouchEvent vorhanden ist und ob es eine positive „Länge“ hat, was darauf hinweist, dass es sich um einen Konstruktor handelt, der ein Argument verwendet.
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);
In RTCPeerConnection-Methoden erforderliche Fehler- und Erfolgs-Handler
TL;DR:Die WebRTC-RTCPeerConnection-Methoden createOffer() und createAnswer() erfordern jetzt einen Fehler-Handler sowie einen Erfolgs-Handler. Bisher konnten diese Methoden nur mit einem Erfolgs-Handler aufgerufen werden. Diese Nutzung wurde eingestellt.
In Chrome 49 wurde außerdem eine Warnung hinzugefügt, wenn Sie setLocalDescription() oder setRemoteDescription() ohne Angabe eines Fehler-Handlers aufrufen. Wir planen, das Fehler-Handler-Argument für diese Methoden in Chrome 50 obligatorisch zu machen.
Dies ist Teil der Weichen für die Einführung von Promise für diese Methoden, wie es in der WebRTC-Spezifikation gefordert wird.
Hier ist 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);
}
Beachten Sie, dass sowohl setLocalDescription() als auch setRemoteDescription() immer einen Fehler-Handler-Parameter hatten. Daher ist die einfache Angabe dieses Parameters eine sichere Änderung.
Im Allgemeinen empfehlen wir für WebRTC-Produktionsanwendungen die Verwendung von adapter.js, einem vom WebRTC-Projekt verwalteten Shim, um Anwendungen vor Spezifikationsänderungen und Präfixunterschieden zu isolieren.
„Document.defaultCharset“ wurde eingestellt
Kurzfassung: Document.defaultCharset wurde zur Verbesserung der Spezifikationscompliance eingestellt.
Entfernungsabsicht Chromestatus Tracker CRBug-Problem
Document.defaultCharset ist ein schreibgeschütztes Attribut, das die Standardzeichencodierung des Nutzersystems basierend auf seinen regionalen Einstellungen zurückgibt. Es hat sich nicht als nützlich erwiesen, diesen Wert beizubehalten, da Browser die Zeichencodierungsinformationen in der HTTP-Antwort oder im in die Seite eingebetteten Meta-Tag verwenden.
Mit „document.characterSet“ erhalten Sie den ersten Wert, der im HTTP-Header angegeben ist. Wenn dieser Wert nicht vorhanden ist, erhalten Sie den im Attribut charset des Elements <meta> angegebenen Wert (z. B. <meta charset="utf-8">). Ist keine dieser Optionen verfügbar, wird document.characterSet als Systemeinstellung des Nutzers verwendet.
Gecko hat diese Eigenschaft nicht unterstützt und sie ist nicht klar spezifiziert, sodass sie aus Blink in Chrome 49 (Beta im Januar 2016) eingestellt wird. Die folgende Warnung wird in Ihrer Konsole angezeigt, bis die Property in Chrome 50 entfernt wird:
Weitere Informationen zur Begründung, diese nicht anzugeben, findest du auf GitHub unter https://github.com/whatwg/dom/issues/58.
getStorageUpdates() entfernt
TL;DR: Navigator.getStorageUpdates() wurde entfernt, da sie nicht mehr in der Navigator-Spezifikation enthalten ist.
Entfernungsabsicht Chromestatus Tracker CRBug-Problem
Wenn das jemanden betrifft, werde ich meinen Hut fressen. getStorageUpdates() wurde noch nie (wenn überhaupt) im Web verwendet.
So zitieren Sie die (sehr alte Version) der HTML5-Spezifikation:
Klingt ziemlich cool, oder? In der Spezifikation wird sogar das Wort "whence" verwendet, das in der Spezifikation nur einmal vorkommt. Auf Spezifikationsebene gab es eine StorageMutex, die den Zugriff auf blockierenden Speicher wie localStorage und Cookies steuerte. Diese API würde diesen Mutex freigeben, damit andere Skripts nicht durch diese StorageMutex blockiert werden. Es wurde jedoch nie implementiert und wird in IE oder Gecko nicht unterstützt. Die Implementierung von WebKit (und damit Blink) war völlig managementfrei.
Sie wurde bereits seit geraumer Zeit aus den Spezifikationen entfernt und auch vollständig aus Blink entfernt. Die längste Zeit war es ein Vorgang und hat nichts gemacht, selbst wenn er aufgerufen wird.
In dem unwahrscheinlichen Fall, dass Sie Code haben, der navigator.getStorageUpdates() aufgerufen hat, müssen Sie prüfen, ob die Funktion vorhanden ist, bevor Sie sie aufrufen.
Object.observe() wurde eingestellt
Kurzfassung: Object.observe() wurde eingestellt, da sie sich nicht mehr im Standardisierungs-Track befindet und in einem zukünftigen Release entfernt wird.
Entfernungsabsicht Chromestatus Tracker CRBug-Problem
Im November 2015 wurde bekannt gegeben, dass Object.Observe aus TC39 zurückgezogen wird. Sie wurde in Chrome 49 eingestellt. Wenn Sie versuchen, sie zu verwenden, wird in der Konsole die folgende Warnung angezeigt:
Viele Entwickler mochten diese API. Wenn Sie mit ihr experimentiert haben und nun nach einem Übergangspfad suchen, sollten Sie einen Polyfill wie MaxArt2501/object-observe oder eine Wrapper-Bibliothek wie polymer/observe-js verwenden.