כמעט בכל גרסה של Chrome אנחנו רואים מספר משמעותי של עדכונים ושיפורים למוצר, לביצועים שלו וליכולות של פלטפורמת האינטרנט.
ב-Chrome 49 (גרסת בטא, 2 בפברואר 2016). תאריך יציב משוער: מרץ 2016) יש מספר שינויים ב-Chrome
השימוש בקידומת 'css' ב-getComputedStyle(e).cssX הוצא משימוש
TL;DR: השימוש בקידומת 'css' ב-getComputedStyle(e) הוצא משימוש כי היא לא נכללה בspec.
getComputedStyle היא פונקציה קטנה ונהדרת. היא תחזיר את כל ערכי ה-CSS של
הסגנונות של רכיב ה-DOM כפי שחושבו על ידי מנוע העיבוד. לדוגמה, אפשר להריץ את הפקודה getComputedStyle(_someElement_).height והיא עשויה להחזיר 224.1 פיקסלים, כי זה הגובה של הרכיב כפי שהוא מוצג כרגע.
נראה שזה API שימושי. מה אנחנו משנים?
לפני שמנוע העיבוד של Chrome השתנה ל-Blink, הוא הופעל על ידי WebKit והאפשרות הזו אפשרה לכם להוסיף תחילית 'css' להתחלת נכס. למשל getComputedStyle(e).cssHeight במקום getComputedStyle(e).height.
שתיהן יחזירו את אותם נתונים כפי שהן ממופו לאותם ערכי בסיס, אבל מדובר בשימוש לא סטנדרטי בקידומת 'css' והיא הוצאה משימוש והוסרה.
הערה – cssFloat הוא נכס רגיל ולא מושפע מההוצאה משימוש.
אם תיגשו לנכס בצורה הזו ב-Chrome 49, הוא יחזיר את הערך undefined ויהיה עליכם לתקן את הקוד.
השימוש ב-initTouchEvent הוצא משימוש
TL;DR:
initTouchEvent
הוצא משימוש לטובת TouchEvent
constructor כדי לשפר את התאימות למפרטים, והוא יוסר לגמרי ב-Chrome 54.
Intent to Remove Chromestatus tracker בעיית CRBug
במשך זמן רב, אתם יכולים ליצור אירועי מגע סינתטיים ב-Chrome בעזרת ה-API initTouchEvent, ולעיתים קרובות הם משמשים לסימולציה של אירועי מגע לצורך בדיקה או אוטומציה של ממשק משתמש מסוים באתר. ב-Chrome 49 הוצאנו משימוש את ה-API הזה, ונציג את האזהרה הבאה עם כוונה להסיר אותו לחלוטין ב-Chrome 53.
יש כמה סיבות לכך שהשינוי הזה לטובה.
היא גם לא מופיעה במפרט אירועי Touch. ההטמעה של Chrome של
initTouchEvent לא הייתה תואמת בכלל ל-API של initTouchEvent ב-Safari,
והייתה שונה מ-Firefox ב-Android. לבסוף, הרבה יותר קל להשתמש
ב-constructor של TouchEvent.
הוחלט לנסות לפעול בהתאם למפרט ולא לתחזק API שלא צוין או תואם להטמעה היחידה האחרת.
לכן אנחנו קודם מוציאים משימוש את הפונקציה initTouchEvent ואז מסירים אותה מהמפתחים ומחייבים אותם להשתמש ב-constructor של TouchEvent.
ה-API הזה משתמש באינטרנט, אבל אנחנו יודעים שהוא נמצא בשימוש במספר נמוך יחסית של אתרים, ולכן אנחנו לא מסירים אותו באותה מהירות שבה אנחנו עשויים להסיר אותו. לדעתנו, חלק מהשימוש לא תקין בגלל שאתרים לא מטפלים בגרסת החתימה של Chrome.
ההטמעות של ה-API initTouchEvent ב-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" בסוכן המשתמש ל-Chrome ב-Android ואז הוא יצא משימוש. עדיין לא ניתן להסיר אותה, מכיוון שב-Android יהיו במשך תקופה מסוימת דפדפנים אחרים המבוססים על WebKit ודפדפנים ישנים יותר של Blink, שעדיין תצטרכו לתמוך בממשק ה-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);
רכיבי handler של שגיאות והצלחה שנדרשים בשיטות RTCPeerConnection
TL;DR: השיטות של WebRTC
RTCPeerConnection createOffer() ו-createAnswer() מחייבות עכשיו גם handler של שגיאות וגם handler של הצלחה. בעבר הייתה אפשרות לקרוא לשיטות האלה רק עם handler שהצליח. השימוש הזה הוצא משימוש.
ב-Chrome 49 הוספנו אזהרה גם במקרה של קריאה ל-setLocalDescription()
או ל-setRemoteDescription() בלי לספק handler של שגיאות. אנחנו מצפים שהארגומנט של הגורם המטפל בשגיאות יהיה חובה עבור שיטות אלה ב-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 הוצא משימוש
TL;DR: כדי לשפר את התאימות למפרט, Document.defaultCharset הוצא משימוש.
Intent to Remove Chromestatus tracker בעיית CRBug
Document.defaultCharset הוא מאפיין לקריאה בלבד שמחזיר את קידוד התווים שמוגדר כברירת מחדל במערכת של המשתמש על סמך ההגדרות האזוריות שלו. לא מועיל לשמור את הערך הזה בגלל האופן שבו דפדפנים משתמשים בפרטי קידוד התווים בתגובת ה-HTTP או במטא תג שמוטמעים בדף.
אם תשתמש ב-document.characterSet, תקבל את הערך הראשון המצוין בכותרת ה-HTTP. אם הוא לא קיים, הערך שצוין במאפיין charset של הרכיב <meta> (לדוגמה, <meta charset="utf-8">).
אם אף אחת מהאפשרויות האלה לא זמינה, הערך של document.characterSet יהיה הגדרת המערכת של המשתמש.
Gecko לא תמכה בנכס הזה ולא צוין בבירור, ולכן הנכס הזה יצא משימוש ב-Blink ב-Chrome 49 (בטא בינואר 2016). האזהרה הבאה תופיע במסוף עד להסרת הנכס ב-Chrome 50:
אפשר לקרוא ב-github.com/whatwg/dom/issue/58 את הסיבה לדיון נוסף בסיבות שלא לפרט את זהhttps://github.com/whatwg/dom/issues/58
getStorageUpdates() הוסר
TL;DR: Navigator.getStorageUpdates() הוסר כי הוא כבר לא מופיע במפרט Navigator.
Intent to Remove Chromestatus tracker בעיית CRBug
אם זה ישפיע על מישהו, אני אוכל את הכובע שלי. כמעט שלא נעשה שימוש
ב-getStorageUpdates() באינטרנט (אם בכלל).
כדי לצטט את הגרסה (גרסה ישנה מאוד) של מפרט HTML5:
נשמע די מגניב, נכון? במפרט נעשה שימוש גם במילה "whence" (במקרה שהיא האירוע היחיד שמופיע במפרט). ברמת המפרט היה StorageMutex ששולט בגישה לחסימה של אחסון, כמו localStorage וקובצי cookie, וה-API הזה עזר לשחרר את ה-mutex כך שסקריפטים אחרים לא ייחסמו על ידי StorageMutex. אבל היא מעולם לא הוטמעה, היא לא נתמכת ב-IE וב-Gecko, וההטמעה של WebKit (ולכן גם של Blink)
לא הייתה משימה בכלל.
הוא הוסר מהמפרטים כבר זמן רב והוסר לחלוטין מ-Blink (במשך תקופה ארוכה ביותר לא הייתה פעילות, גם אם הוא לא נקרא).
במקרה הלא-סביר שבו היה קוד שהתקשר אל navigator.getStorageUpdates(),
צריך לבדוק אם הפונקציה קיימת לפני שמפעילים אותה.
Object.observe() הוצא משימוש
TL;DR: Object.observe() הוצא משימוש כי הוא לא נמצא יותר במסלול של תקינה ותוסר בגרסה עתידית.
Intent to Remove Chromestatus tracker בעיית CRBug
בנובמבר 2015 הוכרז שObject.Observe יוסר מ-TC39. הוא הוצא משימוש מ-Chrome 49, ותוכלו לראות את האזהרה הבאה במסוף אם תנסו להשתמש בו:
מפתחים רבים אהבו את ה-API הזה, ואם ניסיתם אותו ואתם מחפשים עכשיו מסלול מעבר, כדאי להשתמש ב-Polyfill כמו MaxArt2501/object-observe או בספריית wrapper כמו polymer/observe-js.