כמעט בכל גרסה של Chrome אנחנו רואים מספר משמעותי של עדכונים ושיפורים במוצר, בביצועים שלו וגם ביכולות של פלטפורמת האינטרנט.
ב-Chrome 49 (בטא מ-2 בפברואר 2016). תאריך יציבות משוער: מרץ 2016) יש מספר שינויים ב-Chrome
השימוש בקידומת css ב-getComputedStyle(e).cssX הוצא משימוש
בקצרה: השימוש בקידומת css ב-getComputedStyle(e) הוצא משימוש כי הוא לא היה חלק מהמפרט הרשמי.
getComputedStyle היא פונקציה קטנה ונהדרת. הפונקציה תחזיר את כל ערכי ה-CSS של הסגנונות של רכיב ה-DOM, כפי שחושבו על ידי מנוע העיבוד. לדוגמה, אם מריצים את הפקודה getComputedStyle(_someElement_).height, יכול להיות שיוחזר הערך 224.1px כי זה הגובה של הרכיב כפי שהוא מוצג כרגע.
נראה שזה API שימושי מאוד. אז מה אנחנו משנים?
לפני שמנוע העיבוד של Chrome השתנה ל-Blink, הוא הופעל על ידי WebKit, וזה אפשר להוסיף את הקידומת css לתחילת מאפיין. לדוגמה, getComputedStyle(e).cssHeight במקום getComputedStyle(e).height.
שתי האפשרויות יחזירו את אותם נתונים כי הן ממופות לאותם ערכים בסיסיים, אבל השימוש בקידומת css לא סטנדרטי, הוא הוצא משימוש והוסר.
הערה – cssFloat הוא נכס רגיל והוצאת התכונה הזו משימוש לא משפיעה עליו.
אם תיגשו למאפיין בדרך הזו ב-Chrome 49, יוחזר הערך undefined ותצטרכו לתקן את הקוד.
השימוש ב-initTouchEvent הוצא משימוש
תקציר:
initTouchEvent
הוצא משימוש והוחלף ב-TouchEvent
constructor כדי לשפר את התאימות למפרט, והוא יוסר לחלוטין ב-Chrome 54.
Intent to Remove Chromestatus Tracker CRBug Issue
במשך זמן רב הייתה אפשרות ליצור אירועי מגע סינתטיים ב-Chrome באמצעות initTouchEvent API. האירועים האלה משמשים לעיתים קרובות כדי לדמות אירועי מגע לצורך בדיקה או אוטומציה של חלק מממשק המשתמש באתר. ב-Chrome 49 הוצאנו את ה-API הזה משימוש, ונציג את האזהרה הבאה במטרה להסיר אותו לחלוטין ב-Chrome 53.
יש כמה סיבות לכך שהשינוי הזה הוא טוב.
היא גם לא מופיעה במפרט של Touch Events. ההטמעה של initTouchEvent ב-Chrome לא הייתה תואמת בכלל לממשק ה-API של initTouchEvent ב-Safari, והייתה שונה מההטמעה ב-Firefox ב-Android. ולבסוף, קל יותר להשתמש בבונה TouchEvent.
הוחלט שננסה לפעול בהתאם למפרט במקום לתחזק API שלא מוגדר במפרט ולא תואם להטמעה היחידה האחרת.
לכן, אנחנו קודם מוציאים משימוש את הפונקציה initTouchEvent ואז מסירים אותה, ומחייבים את המפתחים להשתמש ב-constructor TouchEvent.
יש שימוש ב-API הזה באינטרנט, אבל אנחנו יודעים שמספר האתרים שמשתמשים בו הוא נמוך יחסית, ולכן אנחנו לא מסירים אותו מהר כמו שאנחנו עושים בדרך כלל. אנחנו מאמינים שחלק מהשימוש לא תקין בגלל שאתרים לא מטפלים בגרסה של החתימה ב-Chrome.
מכיוון שההטמעות של initTouchEvent API
ב-iOS וב-Android/Chrome היו שונות מאוד, לעיתים קרובות היה קוד בסגנון (לרוב בלי להתייחס ל-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);
קודם כל, זה לא טוב כי הוא מחפש את המחרוזת Android ב-User-Agent, ודפדפן Chrome ב-Android יתאים ויגיע להוצאה משימוש הזו. אי אפשר להסיר אותו עדיין כי יהיו עוד דפדפנים מבוססי WebKit ו-Blink ישנים יותר ב-Android למשך זמן מה, ותצטרכו להמשיך לתמוך בממשק ה-API הישן.
כדי לטפל נכון ב-TouchEvents באינטרנט, צריך לשנות את הקוד כך שיתמוך ב-Firefox, ב-IE Edge וב-Chrome. לשם כך, צריך לבדוק אם TouchEvent קיים באובייקט window, ואם יש לו ערך חיובי של 'length' (שמציין שהוא בנאי שמקבל ארגומנט), צריך להשתמש בו.
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);
נדרשים מטפלים בשגיאות ובפעולות מוצלחות בשיטות של RTCPeerConnection
בקיצור: ה-methods createOffer() ו-createAnswer() של WebRTC RTCPeerConnection מחייבים עכשיו גם handler לשגיאות וגם handler להצלחה. בעבר היה אפשר לקרוא לשיטות האלה רק עם handler של הצלחה. השימוש הזה הוצא משימוש.
ב-Chrome 49 הוספנו גם אזהרה אם מתקשרים אל
setLocalDescription() או אל setRemoteDescription()
בלי לספק מטפל בשגיאות. אנחנו צפויים להפוך את הארגומנט של מטפל השגיאות
לנדרש בשיטות האלה ב-Chrome 50.
השינוי הזה הוא חלק מההכנות להוספת הבטחות לשיטות האלה, כפי שנדרש במפרט WebRTC.
הנה דוגמה מהדמו של RTCPeerConnection ב-WebRTC (main.js, שורה 126):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
חשוב לשים לב שלשתי הפונקציות setLocalDescription() ו-setRemoteDescription() תמיד היה פרמטר לטיפול בשגיאות, ולכן ציון הפרמטר הזה הוא שינוי בטוח.
באופן כללי, באפליקציות WebRTC לייצור מומלץ להשתמש ב-adapter.js, שהוא shim שמתוחזק על ידי פרויקט WebRTC, כדי לבודד אפליקציות משינויים במפרט ומקידומות שונות.
המאפיין Document.defaultCharset הוצא משימוש
אמ;לק: הוצאנו משימוש את Document.defaultCharset כדי לשפר את התאימות למפרט.
Intent to Remove Chromestatus Tracker CRBug Issue
Document.defaultCharset הוא מאפיין לקריאה בלבד שמחזיר את קידוד ברירת המחדל של התווים במערכת של המשתמש על סמך ההגדרות האזוריות שלו. הערך הזה לא שימושי כי הדפדפנים משתמשים במידע על קידוד התווים בתג התגובה של HTTP או בתג meta שמוטמע בדף.
באמצעות document.characterSet תקבלו את הערך הראשון שצוין בכותרת ה-HTTP. אם הוא לא קיים, המערכת תשתמש בערך שצוין במאפיין charset של רכיב <meta> (לדוגמה, <meta charset="utf-8">). לבסוף, אם אף אחד מהערכים האלה לא זמין, הערך של document.characterSet יהיה הגדרת המערכת של המשתמש.
המאפיין הזה לא נתמך ב-Gecko, והמפרט שלו לא ברור. לכן, המאפיין הזה יוצא משימוש ב-Blink ב-Chrome 49 (גרסת בטא בינואר 2016). האזהרה הבאה תופיע במסוף עד להסרת המאפיין ב-Chrome 50:
דיון נוסף על הסיבות לכך שלא נכלל מפרט בנושא הזה זמין ב-GitHub בכתובת https://github.com/whatwg/dom/issues/58
הוסרה הפונקציה getStorageUpdates()
TL;DR: Navigator.getStorageUpdates() has been removed as it is no longer in the
Navigator spec.
Intent to Remove Chromestatus Tracker CRBug Issue
אם זה ישפיע על מישהו, אני אוכל את הכובע שלי. השם getStorageUpdates() כמעט אף פעם לא היה בשימוש באינטרנט (אם בכלל).
לפי הציטוט מתוך מפרט HTML5 (בגרסה ישנה מאוד):
נשמע מגניב, נכון? במפרט אפילו נעשה שימוש במילה "whence" (שבמקרה היא המופע היחיד של המילה הזו במפרט). ברמת המפרט הייתה StorageMutex ששלטה בגישה לחסימת אחסון כמו localStorage וקובצי Cookie, וממשק ה-API הזה עזר לשחרר את ה-mutex הזה כדי שסקריפטים אחרים לא ייחסמו על ידי ה-StorageMutex הזה. אבל היא אף פעם לא יושמה, היא לא נתמכת ב-IE או ב-Gecko, וההטמעה של WebKit (ולכן גם של Blink) לא פעלה.
הוא הוסר מהמפרטים לפני זמן רב, והוסר לחלוטין מ-Blink (במשך זמן רב הוא לא ביצע פעולה ולא עשה כלום גם אם בוצעה קריאה לפונקציה).
במקרה הלא סביר שהיה לכם קוד שקרא ל-navigator.getStorageUpdates(), תצטרכו לבדוק אם הפונקציה קיימת לפני שתקראו לה.
השיטה Object.observe() הוצאה משימוש
בקיצור: הוצאנו את Object.observe() משימוש כי הוא כבר לא בתהליך של סטנדרטיזציה, והוא יוסר בגרסה עתידית.
Intent to Remove Chromestatus Tracker CRBug Issue
בנובמבר 2015 הודענו ש-Object.Observe יוצא משימוש ב-TC39. הפונקציה הזו הוצאה משימוש ב-Chrome מגרסה 49 ואילך, ואם תנסו להשתמש בה תופיע האזהרה הבאה במסוף:
מפתחים רבים אהבו את ה-API הזה, ואם ניסיתם אותו ואתם מחפשים עכשיו דרך מעבר, כדאי להשתמש ב-polyfill כמו MaxArt2501/object-observe או בספריית wrapper כמו polymer/observe-js.