W niemal każdej wersji Chrome wprowadzamy wiele aktualizacji i ulepszeń produktu, jego wydajności, a także możliwości platformy internetowej.
W Chrome 49 (wersja beta z 2 lutego 2016 r.) Szacowana data wprowadzenia wersji stabilnej: marzec 2016 r.) wprowadzono szereg zmian w Chrome.
Użycie prefiksu „css” w metodzie getComputedStyle(e).cssX zostało wycofane
TL;DR: użycie prefiksu „css” w getComputedStyle(e) zostało wycofane, ponieważ nie było częścią formalnej specyfikacji.
getComputedStyle to świetna mała funkcja. Zwróci wszystkie wartości CSS stylów elementu DOM obliczone przez silnik renderujący. Możesz na przykład uruchomić getComputedStyle(_someElement_).height, a funkcja może zwrócić wartość 224,1 piksela, ponieważ jest to wysokość elementu w obecnie wyświetlanej formie.
To bardzo przydatny interfejs API. Co więc zmieniamy?
Zanim silnik renderujący Chrome został zmieniony na Blink, korzystał z WebKit, co umożliwiało dodanie prefiksu „css” na początku właściwości. Na przykład getComputedStyle(e).cssHeight zamiast getComputedStyle(e).height.
Oba zwracałyby te same dane, ponieważ były mapowane na te same wartości bazowe, ale to użycie prefiksu „css” jest niestandardowe i zostało wycofane oraz usunięte.
Uwaga: parametr cssFloat jest standardową właściwością i nie jest objęty wycofaniem.
Jeśli w Chrome 49 uzyskasz dostęp do właściwości w ten sposób, zwróci ona wartość undefined i będziesz musiał(-a) poprawić kod.
Funkcja initTouchEvent została wycofana
W skrócie:
initTouchEvent
został wycofany na rzecz
TouchEvent
constructor, aby zwiększyć zgodność ze specyfikacją. Zostanie całkowicie usunięty w Chrome 54.
Zamiar usunięcia Śledzenie stanu Chrome Problem w CRBug
Od dłuższego czasu możesz tworzyć w Chrome syntetyczne zdarzenia dotyku za pomocą interfejsu initTouchEvent API. Są one często używane do symulowania zdarzeń dotyku na potrzeby testowania lub automatyzowania niektórych elementów interfejsu w witrynie. W Chrome 49 wycofaliśmy ten interfejs API i wyświetlamy to ostrzeżenie. Planujemy całkowicie usunąć go w Chrome 53.
Istnieje wiele powodów, dla których ta zmiana jest korzystna.
Nie ma go też w specyfikacji zdarzeń dotykowych. Implementacja initTouchEvent w Chrome była całkowicie niezgodna z interfejsem initTouchEvent w Safari i różniła się od implementacji w Firefoksie na Androidzie. Poza tym TouchEventkonstruktorTouchEvent jest znacznie łatwiejszy w użyciu.
Postanowiliśmy, że będziemy dążyć do zgodności ze specyfikacją, zamiast utrzymywać interfejs API, który nie jest zgodny ze specyfikacją ani z jedyną inną implementacją.
Dlatego najpierw wycofujemy, a potem usuwamy funkcję initTouchEvent i wymagamy od deweloperów używania konstruktora TouchEvent.
Ten interfejs API jest używany w internecie, ale wiemy, że korzysta z niego stosunkowo niewielka liczba witryn, więc nie usuwamy go tak szybko, jak zwykle. Uważamy, że niektóre przypadki użycia nie działają prawidłowo, ponieważ witryny nie obsługują wersji podpisu Chrome.
Implementacje interfejsu initTouchEvent API w systemach iOS i Android/Chrome tak bardzo się od siebie różniły, że często trzeba było używać kodu podobnego do tego (często zapominając o Firefoxie):
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);
Po pierwsze, jest to niekorzystne, ponieważ wyszukuje ciąg „Android” w User-Agent, a Chrome na Androidzie będzie pasować do tego kryterium i zostanie objęty wycofaniem. Nie można go jeszcze usunąć, ponieważ przez jakiś czas na Androidzie będą działać inne przeglądarki oparte na WebKit i starszych wersjach Blink, które nadal będą wymagać obsługi starszego interfejsu API.
Aby prawidłowo obsługiwać TouchEvents w internecie, zmień kod, aby obsługiwał przeglądarki Firefox, IE Edge i Chrome. W tym celu sprawdź, czy w obiekcie window istnieje TouchEvent, a jeśli ma on dodatnią „długość” (co oznacza, że jest konstruktorem, który przyjmuje argument), użyj go.
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);
W metodach RTCPeerConnection wymagane są procedury obsługi błędów i sukcesów
TL;DR: metody WebRTC RTCPeerConnection createOffer() i createAnswer() wymagają teraz zarówno procedury obsługi błędów, jak i procedury obsługi powodzenia. Wcześniej można było wywoływać te metody tylko za pomocą funkcji obsługi sukcesu. To użycie zostało wycofane.
W Chrome 49 dodaliśmy też ostrzeżenie, które wyświetla się, gdy wywołasz funkcję
setLocalDescription() lub setRemoteDescription()
bez podania procedury obsługi błędów. W Chrome 50 argument error handler
dla tych metod będzie wymagany.
Jest to część przygotowań do wprowadzenia obietnic w tych metodach, zgodnie z wymaganiami specyfikacji WebRTC.
Oto przykład z demonstracji RTCPeerConnection w WebRTC (main.js, wiersz 126):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Pamiętaj, że zarówno setLocalDescription(), jak i setRemoteDescription() zawsze miały parametr procedury obsługi błędów, więc samo określenie tego parametru jest bezpieczną zmianą.
W przypadku aplikacji WebRTC w środowisku produkcyjnym zalecamy używanie adapter.js, czyli warstwy pośredniej utrzymywanej przez projekt WebRTC, aby odizolować aplikacje od zmian specyfikacji i różnic w prefiksach.
Właściwość Document.defaultCharset została wycofana
W skrócie: element Document.defaultCharset został wycofany, aby zwiększyć zgodność ze specyfikacją.
Zamiar usunięcia Śledzenie stanu Chrome Problem w CRBug
Document.defaultCharset to właściwość tylko do odczytu, która zwraca domyślne kodowanie znaków systemu użytkownika na podstawie jego ustawień regionalnych. Utrzymywanie tej wartości nie jest przydatne ze względu na sposób, w jaki przeglądarki używają informacji o kodowaniu znaków w odpowiedzi HTTP lub w metatagu osadzonym na stronie.
Używając document.characterSet, uzyskasz pierwszą wartość określoną w nagłówku HTTP. Jeśli nie ma tego atrybutu, otrzymasz wartość określoną w atrybucie charset elementu <meta> (np. <meta charset="utf-8">). Jeśli żadna z tych wartości nie jest dostępna, document.characterSet będzie ustawieniem systemowym użytkownika.
Gecko nie obsługuje tej właściwości, a jej specyfikacja nie jest jasna, więc zostanie ona wycofana z Blinka w Chrome 49 (wersja beta w styczniu 2016 r.). Do momentu usunięcia tej właściwości w Chrome 50 w konsoli będzie się wyświetlać to ostrzeżenie:
Więcej informacji o powodach, dla których nie warto tego specyfikować, znajdziesz na GitHubie: https://github.com/whatwg/dom/issues/58
Usunięto funkcję getStorageUpdates()
Podsumowanie: element Navigator.getStorageUpdates() został usunięty, ponieważ nie jest już uwzględniony w specyfikacji Navigator.
Zamiar usunięcia Śledzenie stanu Chrome Problem w CRBug
Jeśli ta zmiana na kogoś wpłynie, zjem kapelusz. getStorageUpdates() jest rzadko (lub wcale) używana w internecie.
Zgodnie z (bardzo starą) wersją specyfikacji HTML5:
Brzmi całkiem nieźle, prawda? W specyfikacji użyto nawet słowa „whence” (które jest jedynym wystąpieniem tego słowa w specyfikacji). Na poziomie specyfikacji istniał StorageMutex, który kontrolował dostęp do blokowania pamięci, np. localStorage i plików cookie. Ten interfejs API pomagał zwalniać ten mutex, aby inne skrypty nie były blokowane przez ten StorageMutex. Nie została jednak nigdy wdrożona, nie jest obsługiwana w IE ani Gecko, a implementacja w WebKit (a tym samym w Blink) nie działa.
Od dłuższego czasu nie ma go w specyfikacjach, a został całkowicie usunięty z Blinka (od dawna nie działał i nie robił nic, nawet jeśli był wywoływany).
W mało prawdopodobnym przypadku, gdy masz kod, który wywołuje navigator.getStorageUpdates(), musisz sprawdzić, czy funkcja jest obecna, zanim ją wywołasz.
Funkcja Object.observe() jest wycofana
TL;DR: funkcja Object.observe() została wycofana, ponieważ nie jest już objęta procesem standaryzacji i w przyszłej wersji zostanie usunięta.
Zamiar usunięcia Śledzenie stanu Chrome Problem w CRBug
W listopadzie 2015 r. ogłoszono, że Object.Observe wycofuje się z TC39. Została wycofana w Chrome 49. Jeśli spróbujesz jej użyć, w konsoli zobaczysz to ostrzeżenie:
Wielu programistów lubiło ten interfejs API. Jeśli z nim eksperymentujesz i szukasz teraz sposobu na przejście na inny interfejs, rozważ użycie polyfillu, np. MaxArt2501/object-observe, lub biblioteki otoki, np. polymer/observe-js.