תגית: Internet Explorer

אבני הבנין של האינטרנט: SOP ותקשורת Cross-Domain

כלל ה Same Origin Policy, או בקיצור SOP, הופיע לראשונה בדפדפן Netscape 2.0. הוא הופיע בד-בבד עם שפת התכנות JavaScript וה (Document Object Model (DOM. כמו JavaScript וה DOM, הוא הפך לחלק בלתי-נפרד מהדפדפן המודרני.

SOP הוא עקרון האבטחה, כנראה המרכזי ביותר בדפדפן. הרעיון הוא דיי פשוט: שני Execution Contexts שונים של ג’אווהסקריפט לא יוכלו לגשת על ה DOM אחד של השני אם הם לא מגיעים מאותו המקור (origin).
מתי יש לנו Execution Contexts שונים? כאשר יש iFrames שונים או טאבים שונים.

איך מוגדר origin? שילוב של שלושה אלמנטים:

  • סכמה / פרוטוקול (למשל http או https)
  • Fully Qualified Domain Name (בקיצור: FQDN, למשל news.google.co.il)
  • מספר port [א].

SOP מונע מצב בו פתחנו 2 חלונות: אחד לאתר לגיטימי והשני לאתר זדוני (בטעות), והאתר הזדוני עושה באתר הלגיטימי כרצונו. בנוסף יש לנו כלי בשם iFrame – כלי ל isolation, כך שאנו יכולים לפתוח בדף שלנו iFrame לאתר חיצוני לא מוכר ולדעת שאנו מוגנים בפניו.

עולם האינטרנט השתנה מאז 1995, והיום יש הרבה יותר אינטראקציה משותפת (mashups) בין אתרים שונים. SOP מגביל את היכולת שלנו לשתף מידע בין מקורות שונים.

אז מה עושים? האם נחרץ גורלו של האתר שלנו להיות מוגן, אך מבודד – לעד?

בפוסט זה נבין מה מדיניות ה SOP בדיוק אומרת, ונסקור מספר טכניקות נפוצות לבצע שיתוף מידע.

פוסט זה שייך לסדרה אבני הבניין של האינטרנט.

תזכירו לי מה המשמעות של SOP?

נניח שדף ה HTML של האפליקציה / אתר שלנו נטען מהכתובת http://www.example.com/home/index.html.
משמע: ה origin הנוכחי שלנו הוא http://www.example.com:80.

הנה המשמעות של מדיניות ה SOP בנוגע לגישה ל origins אחרים (“Compared URL”):

מקור: http://en.wikipedia.org/wiki/Same_origin_policy

הערה מעניינת: SOP, כמו מנגנוני הגנה אחרים של הדפדפן, מתבססים על ה FQDN ללא אימות מול ה IP Address. המשמעות היא שפריצה לשרת DNS יכולה להשבית את ה SOP ולאפשר קשת רחבה ויצירתית של התקפות על המשתמש.

SOP הוגדר במקור עבור גישה ל DOM בלבד, אך עם השנים הוא הורחב:

XMLHttpRequest (המשמש לקריאות Ajax) מוגבל גם הוא. קריאות Ajax יוגבלו רק ל origin ממנו נטען המסמך (כלומר: קובץ ה HTML). בנוסף, בעקבות היסטוריה של התקפות שהתבססו על “זיוף” קריאות ל origin הלגיטימי עם Headers מטעים – נוספו מספר מגבלות על Headers אותם ניתן לשנות בקריאות Ajax (למשל: Referer או Content-Length וכו’).

Local Storage (יכולת חדשה ב HTML5 לשמור נתונים באופן קבוע על הדפדפן) גם היא מוגבלת ע”פ ה SOP. לכל origin יש storage שלו ולא ניתן לגשת ל storage של origin אחר.

Cookies – האמת שמגבלות על Cookies החלו במקביל להתפתחות ה SOP. התוצאה: סט מגבלות דומה, אך מעט שונה. הדפדפן לא ישלח Cookies לדומיין אחר (למשל evil.com) אך הוא ישלח את ה cookies לתת-domain למשל:
evil.www.example.com, תת-domain של www.example.com.
בדפדפנים שאינם Internet Explorer, ניתן לדרוש אכיפה של domain מדויק ע”י השמטה של פרמטר ה domain (תיעוד ב MDN, קראו את התיאור של הפרמטר domain).

כיוון ש Cookie יכולים להכיל מידע רגיש מבחינת אבטחת מידע (למשל: אישור גישה לשרת), הוסיפו עליהם עוד 2 מנגנוני הגנה נוספים:
httponly – פרמטר ב HTTP header של set-cookie שהשרת יכול לסמן, המונע גישה מקוד ג’אווהסקריפט בצד-הלקוח ל cookie שטמן השרת. כלומר: ה cookie רק יעבור הלוך וחזור בין השרת לדפדפן, בלי שלקוד הג’אווהסקריפט תהיה גישה אליו.
secure – פרמטר בצד הג’אווהסקריפט של יצירת cookie (שוב, התיעוד ב MDN) שאם נקבע ל true – יגרום לדפדפן להעביר את ה cookie רק על גבי תקשורת HTTPS (כלומר: מוצפנת).

Java Applet, Flash ו Silverlight כוללים כללים שונים ומשונים הנוגעים ל SOP. חבורה זו היא זן נכחד – ולכן אני מדלג על הדיון בעניינה.

SOP מתיר חופש במקרים הבאים:

Cross domain resource loading – שימו לב, זהו כלל חשוב: הדפדפן כן מאפשר לטעון קבצים מ domains אחרים. לדוגמה: קבצי ג’אווהסקריפט, תמונות, פונטים (בעזרת font-face@) או קבצי וידאו. על קבצי CSS יש כמה מגבלות [ב]. כלומר: האתר שלנו, http://www.example.com יכול בלי בעיה לטעון קובץ ג’אווהסקריפט מאתר אחר suspicious.com. טעינת הג’אווהסקריפט הינה הצהרת אמון במקור – ועל כן קוד הג’אווהסקריפט שנטען מקבל את ה origin שלנו ועל כן הוא יכול לגשת ל DOM שלנו ללא מגבלה. מצד שני: הוא אינו יכול לגשת ל DOM של iFrame אחר שמקורו מ suspicious.com או לבצע קריאות Ajax ל suspicious.com – למרות שהוא נטען משם.

הערה: אשתמש מעתה לסירוגין במונחים “frame” ו “iFrame”, ע”פ הביטוי הספציפי וכיצד שנהוג להשתמש בו. לצורך הדיון בפוסט זה, הכוונה היא לאותו הדבר.

Location – סקריפט שמגיע מ origin שונה מורשה לבצע פעולות השמה (אך לא קריאה) על אובייקט ה Location (ה URL הנוכחי של ה frame) כגון ()location.replace. זה נשמע מעט מוזר, אך הסיבה לכך היא לאפשר שימוש בטכניקה בשם iFrame busting הנועדה להילחם בהתקפה בשם clickjacking. כלומר: כדי להבטיח שאתר זדוני לא מארח את האתר שלנו ומראה רק חלקים מסוימים ממנו כחלק מהונאה, מותר לנו לגשת לכל frame אחר בדף (למשל ה Top Frame) ולהפוך אותו לכתובת האתר שלנו. התוצאה: האתר המארח יוחלף באתר שלנו – ללא אירוח.
דרך מודרנית יותר למניעת clickjacking היא שימוש ב HTTP Header בשם X-Frame-Options.

מתקפת clickjacking בפעולה. מקור.

באופן לא מפתיע יש הרבה יוצאי דופן בין הדפדפנים השונים. מקור עיון מעולה לנושא זה הוא מדריך האבטחה של כרום.

טכניקות התמודדות

עם השנים התבססו מספר טכניקות מוכרות “לעקוף” את מגבלות ה SOP, במצבים בהם אנו מעוניינים בכך. חלק מהיכולות אופשרו ע”י הדפדפנים, ואחרים ניצלו “פרצות” בחוקי ה SOP בכדי לבצע את העבודה.

רשימת הטכניקות אותן נסקור בפוסט זה
בגדול ניתן לחלק את הטכניקות ל2 משפחות:
  1. תקשורת בין Frames מ Origins שונים באותו הדף.
  2. תקשורת בין לקוח לשרת ב Origin שונה (כלומר: קריאות Ajax).
אני אפתח במשפחה הראשונה, למרות שהשימוש בה פחות נפוץ בימנו – מכיוון שחלק מהטכניקות שלה מהוות בסיס לטכניקות במשפחה השנייה.

Cross-Origin inter-Frame Communication




להלן נסקור מספר טכניקות מקובלות כדי לתקשר בין iFrames מ origins (או domains) שונים.


Domain Relaxation – הטכניקה הזו אופשרה ע”י הדפדפנים.
בטכניקה זו קוד הג’אווהסקריפט משנה את ה origin הנוכחי ע”י השמת ערך חדש למשתנה: document.domain.
המגבלה: הוא יכול רק “לקצץ” תתי-domains ולא להחליף את ה domain לגמרי. לדוגמה:
  • מ “login.example.com” ל “example.com” – מותר.
  • מ “login.example.com” ל “login.com” – אסור.
  • כמו כן, מ “login.example.com” ל “com” – מותר, אבל מסוכן!!
התוצאה של פעולת ה domain relaxation היא הבעת אמון גדולה בכל אתר מה domain המעודכן, והרשאה לג’אווהסקריפט של אותו האתר לערוך את ה DOM שלנו. אם אפליקציה זדונית שאנו מארחים ב iFrame, מסוגלת לבצע Domain Relaxation לאותו Relaxed Domain כמו שלנו – היא יכולה לגשת ל DOM שלנו ללא מגבלה.
חשוב לציין ש Domain Relaxation לא משפיע על אובייקט ה XmlHttpRequest. קריאות Ajax יתאפשרו רק ל origin המקורי ממנו נטען ה Document שלנו.
בנוסף, בחלק מהדפדפנים Domain Relaxation ישפיע רק על גישה בין Frames באותו הטאב ולא על גישה בין טאבים נפרדים.
סיכום: Domain Relaxation היא טכניקה נוחה בתוך ארגון בו כל המחשבים הם תחת דומיין-על אחיד, אך היא לא נחשבת לבטוחה במיוחד. שימוש ב Domain Relaxation פותח פתח למרחב לא ידוע של תתי-domains שאנו לא מכירים – לגשת ל DOM שלנו.

Encoding Messaged on the URL Fragment Id

טריק מלוכלך זה מתבסס על 2 עובדות:

  • SOP מתיר ל Frame אחד לשנות את ה Location (כלומר URL) של Frame כלשהו אחר בדף.
  • שינוי של FragmentID (החלק ב URL שלאחר סימן ה #) לא גורם ל reload של המסמך (כפי שהסברנו בפוסט על ה URL)
התרגיל עובד כך: פריים (frame) א’ משנה את ה FID (קיצור של Fragment ID) של פריים ב’. הוא מקודד הודעה כלשהי שהוא רוצה להעביר.
פריים ב’ מאזין לשינויים ב FID שלו, מפענח את ההודעה ומחזיר תשובה ע”י קידוד הודעה ע”י שינוי ה FID של פריים ב’.
וריאציה נוספת של הטכניקה הזו היא שכל פריים משנה את ה window.name של עצמו. SOP מתיר ל frames שונים לקרוא את ה property הזה מ frames אחרים ללא הגבלה.
סיכום: מלוכלך, מוגבל, לא בטוח (אני לא ידוע מי באמת שינה לי את ה FID) – אבל יכול לעבוד.
ישנן עוד כמה טכניקות דומות (בעזרת Flash, למשל) – אך אני אדלג עליהן.

Post Message

בשלב מסוים החליטו הדפדפנים לשים סוף לבאלגן. כשהרבה מפתחים משתמשים בטכניקות כגון ה Encoding על ה FID, עדיף פשוט לאפשר להם דרך פשוטה ובטוחה. כאן נכנסת לתמונה יכולת ה “Post Message”, שהוצגה כחלק מ HTML5.

יכולת זו נתמכת החל מ IE8 (כולל), ועל כן היא רלוונטית עבור הרוב הגדול של הדפדפנים שבשימוש היום.

מנגנון ה Post Message (בקיצור: PM) מאפשר לשלוח הודעות טקסט בין iFrames או חלונות שונים בדפדפן, בתוספת מנגנון אבטחה שמגביל את שליחת / קבלת ההודעות ל domain ידוע מראש.

הנה דוגמה:

כדאי לציין שניתן לשלוח הודעה עם target domain של “*” (“לכל מען דבעי”). לא ברור לי מדוע איפשרו יכולת זו – אבל היא מדלגת על מנגנון האבטחה החשוב של PM. כמו כן חשוב לבצע בדיקת domain בקבלה ולבדוק רק Domain מדויק.
מימוש אפשרי הוא בדיקה חלקית, למשל:

if (msg.origin.indexOf(“.example.com”) != -1) { … }

מזהים מה הבעיה פה?
תוקף מ Domain בשם example.com.dr-evil.com (השייך לחלוטין לדומיין dr-evil.com) יוכל גם הוא לשלוח לנו הודעות!

סיכום: טכניקה בטוחה וקלה לשימוש. כדאי תמיד להעדיף אותה – אם היא זמינה.

שווה לציין ספריה בשם EasyXDM לשליחת הודעות Cross Domain.
EasyXDM ישתמש ב Post Message, אם הוא זמין (IE8+) או יבצע fallback למגוון שיטות היכולות לעבוד על IE6 ו IE7 – אם אין לו ברירה. מומלץ להשתמש רק אם תמיכה ב IE6-7 היא חובה.

Cross-Origin Client-To-Server Communication

סקרנו את המשפחה הראשונה של הטכניקות: תקשורת בין Frames בדפדפן. טכניקות אלו שימושית כאשר אנו מארחים אפליקציות או widgets ב iFrame.

הצורך הנפוץ יותר הוא בביצוע קריאות לשרת שנמצא ב origin שונה. תזכורת: אם האפליקציה שלנו נטענה מ origin A והיא תנסה לבצע קריאת Ajax ל origin B – הקריאה לא תצא, הדפדפן יחסום אותה.

בואו נעבור על מספר טכניקות מקובלות המאפשרות לבצע קריאת Ajax ל originB – וננסה לעשות זאת בצורה מאובטחת ככל האפשר.

Server Proxy

כאשר יש לנו דף / document המשויך ל Domain A, אין לו בעיה לייצר קריאות Ajax ל Domain A – הרי זה ה origin שלו. אם אנו מנסים להוציא קריאת Ajax ל Domain B (כלומר: domain אחר), הדפדפן יחסום את הקריאה כחלק ממדיניות ה SOP:

אפשרות אחת להתמודד עם הבעיה היא לבקש מהשרת ב Domain A, לשמש עבורנו כ “Proxy” ולבצע עבורנו את הקריאה:

לשרת אין מדיניות SOP, ולכן אין לו מגבלה לתקשר מול שרת אחר שנמצא ב Domain B. אין משמעות הדבר שאין סיכון בתקשורת לשרת אחר – פשוט אין אכיפה. על שרת A לממש את מנגנוני האבטחה בעצמו ולהחליט באילו שרתים אחרים הוא בוטח.

וריאציה אחרת של שיטה זו היא להציב Reverse Proxy בין הדפדפן ל 2 השרתים. ניתן לקבוע חוקים ב Reverse Proxy שייגרמו ל-2 השרתים להראות כאילו הם באותו ה Domain.

גישת ה Server Proxy היא פשוטה, אולם יש לה כמה חסרונות:

  • השרת צריך לבצע עבודה נוספת של העברת הודעות בין הדפדפן לשרת ב’ , מה שיכול בהחלט לפגוע לו ב Scalability (עוד חומרה = עוד כסף). במקרה של Reverse Proxy – העלות הנוספת היא ברורה יותר.
  • שרת ה Proxy שלנו הוא לא דפדפן, הוא לא יעביר באופן טבעי User Agent או Cookies, אלא אם נוסיף קוד שיעשה זאת.
  • “הערמנו” על הדפדפן ועל מנגנון האבטחה שלו, אבל האם יצרנו אלטרנטיבה בטוחה מספיק? (האם יצרנו בכלל אלטרנטיבה בטוחה במידה כלשהי?)
סיכום: פתרון פשוט אבל בעייתי: יש לשים לב למחיר הנוסף ב Scalability, ולוודא שלא יצרנו פרצת-אבטחה.
JSONP (קיצור של JSON with Padding)
טכניקת ה JSONP מבוססת על העובדה הבאה:

  • SOP לא מגביל אותנו לטעון קבצי JavaScript מ Domains אחרים.

מה היה קורה אם קוד הג’אווהסקריפט, שנטען מ Domain אחר, היה כולל קוד שיוצר במיוחד עבור הקריאה שלנו? למשל, קוד המבצע השמה של שורת נתונים לתוך משתנה גלובלי שאנו יכולים לגשת אליו? – משמע שהצלחנו להעביר נתונים, Cross-domain, לדפדפן!

הנה דוגמת קוד כיצד אנו קוראים מצד-הלקוח ל API מסוג JSONP:

והנה התשובה שהשרת מייצר (דינמית) = הקובץ info.js:

הערך “jsonpCallBack” הגיע כפרטמר על ה URL של ה Request, ושאר הנתונים הגיעו מהשרת (מבנה נתונים, DB וכו’).
הקוד הנוסף שעוטף את ה data, בין אם זו השמה למשתנה גלובלי או קריאה ל callback ששמו נשלח – נקרא “Padding”. זהו ה P בשם JSONP.
לרוב אנו נעדיף Padding מסוג callback, מכיוון ש callback מייצר trigger ברגע המידע חזר מהשרת. כאשר משתמשים ב Padding מסוג “השמה למשתנה גלובלי” אנו נאלץ לדגום את המשתנה שוב ושוב בכדי לדעת מתי הוא השתנה…

ל JSONP יש מספר חסרונות:

  • נדרשת תמיכה מהשרת: על השרת לייצר Padding מתאים לנתונים. ה Padding חייב לקרות בצד השרת ואין דרך “להשלים” אותו בצד הלקוח עבור קובץ ג’אווהסקריפט שלא כולל אותו.
  • מכיוון שלא ניתן לטעון קובץ ג’אווהסקריפט יותר מפעם אחת, אם אנו רוצים לבצע מספר קריאות JSONP יהיה עלינו לייצר שם חדש לקובץ ה script בכל קריאה = מעמסה.
  • JSNOP מוגבל לפעולות HTTP GET בלבד (לא ניתן לטעון scripts במתודת HTTP אחרת) – עובדה שמונעת מאתנו להשתמש ב JSONP כדי לקרוא ל REST API.
  • אין Error Handling. אם קובץ הג’אווהסקריפט לא נטען (404, 500 וכו’) – אין לנו שום דרך לדעת זאת. פשוט לא יקרה שום דבר.
  • אבטחת מידע: השרת ממנו אני טוען את הנתונים ב JSONP לא מעביר רק נתונים – הוא מעביר קוד להרצה. אני צריך לסמוך על השרת הזה שלא ישלח לי קוד זדוני.

יתרון משמעותי של JSONP הוא הפשטות (היחסית) כאשר יש לנו קריאה בודדת והעובדה שהוא יעבוד גם עם דפדפנים ישנים. ניתן למצוא הרבה WEB APIs של חברות חשובות כגון גוגל או טוויטר – החשופים ב JSONP.

סיכום: אופציה סבירה כאשר יש תקשורת מועטה ואנו סומכים על שרת היעד.

iFrame Proxy / Relay
טכניקת ה iFrame Proxy (או iFrame Relay) מבוססת על תקשורת בין iFrames, וספציפית על Post Messages.
המנגנון עובד כך:

  1. פתח iFrame שה URL שלו מצביע עד דף (שהכנו מראש) הנמצא על הדומיין איתו אנו רוצים לתקשר. ה origin של המסמך ב iFrame יהיה אותו ה domain.
  2. הדף הנ”ל יטען קובץ ג’אווהסקריפט (שהכנו מראש), נקרא לו proxy.js.
  3. נבצע קריאות Post-Message ל iFrame שייצרנו. proxy.js יאזין לקריאות אלו, כאשר מנגנון ה Post-Message מספק לנו אבטחה.
  4. proxy.js יבצע קריאת Ajax לדומיין המרוחק, אין לו מגבלות – כי הדומיין הזה הוא ה origin שלו.
אם השרת מחזיר תשובה, היא תגיע ל Proxy.js.
  1. proxy.js מקבל את התשובה מהשרת ומבצע Post-Message בחרזה ל Frame / לקוד שלנו.
לגישת ה iFrame Proxy יש כמה חסרונות:
  • היא מורכבת למימוש.
  • נדרשת תמיכה מצד השרת.
  • היא דורשת תמיכה ב PM, קרי IE8+.
מצד שני היא טובה מבחינת Security:
  • בעזרת מנגנון ה PM אנו מוודאים ש proxy.js מגיע מה domain הרצוי.
  • proxy.js מבודד בתוך iFrame ואינו יכול להשפיע על הקוד שלנו – כך שלא חייבים לסמוך ב 100% על שרת היעד.
סיכום: אופציה מורכבת למימוש – אך טובה מבחינת Security.

CORS (קיצור של Cross Origin Resource Sharing)
מאחר ו JSONP ו iFrame Proxy הם אלתורים, החליטו הדפדפנים לפתור את בעיית הקריאה לשרת cross-domain בצורה שיטתית. התוצאה היא פרוטוקול ה CORS.

CORS מאפשר לנו בקלות יחסית לבצע קריאת “Ajax” לשרת בדומיין אחר. השרת צריך לממש מצדו את הפרוטוקול (כמה כללי התנהגות ו Headers על גבי HTTP).

דרך הפעולה הפנימית של CORS היא מעט מורכבת – ואינני רוצה לפרט אותה. ניתן למצוא בלינק הבא הסבר על דרך העבודה, כיצד לממש צד-שרת וכיצד לממש צד-לקוח עם jQuery.

הבעיה העיקרית של CORS היא בעיה של תמיכה. מייקרוסופט התנגדה לתקן ה CORS בטענה שהוא מורכב מדי לשימוש. ב IE8 הם שחררו מנגנון דומה בשם XCrossDomain. באופן דיי מפתיע, נראה שמייקרוסופט צדקה והמנגנון שלה פשוט יותר ובטוח יותר. אולם, הקונצנזוס בקרב שאר יצרני הדפדפנים הכריע – ו CORS הפך לתקן דה-פאקטו.

גרסת ה IE הראשונה שממשה את CORS היא IE10 (וגם לו יש באג משמעותי – הוא לא שולח cookies כמו שצריך).
בפועל התמיכה ב CORS מתחילה מ IE10 אם אינכם זקוקים ל cookies, ואם אתם זקוקים ל Cookies – היא מתחילה ב IE11. סוג האפליקציות שיכולות להסתדר עם תנאי סף שכאלו הם בעיקר אפליקציות מובייל.

עדיין אפשר לבצע מימוש יותר מורכב שישתמש ב XDomainRequest ב IE8-10 וב CORS בכל שאר המקרים.

חסרונות סה”כ:

  • ה API של CORS מעט מסורבל, מימוש בצד השרת דורש מעט עבודה.
  • CORS עשוי להזדקק ל 2 HTTP Requests (מה שנקרא “preflight”) בכדי להשלים קריאה בודדת. אלו הדקויות של המימוש הפנימי.
  • התמיכה של IE היא בעייתית.
ל CORS יש גם יתרונות:
  • סטנדרטי
  • אבטחה טובה
  • לא מצריך להמציא מנגנון שלם, כגון iFrame Proxy.
סיכום: אופציה טובה, שתהיה טובה יותר בעוד מספר שנים.

סיכום

למדנו על מנגנון ה Same Origin Policy, מנגנון אבטחה מרכזי בדפדפנים המגן עלינו מפני התקפות רבות, אך משפיע רבות על היכולת של האפליקציה / אתר שלנו לתקשר עם העולם.

סקרנו והשוונו את הטכניקות הנפוצות לביצוע תקשורת Cross-Domain תחת מנגנון ה SOP, טכניקות מ-2 משפחות:

  • תקשורת בין iFrame ל iFrame.
  • תקשורת מול שרת ב Domain אחר.
סה”כ, הבנת נושא ה SOP היא חשובה למדי עבור מערכות המתקשרות בין Domains שונים, צורך ההולך וגובר עם השנים.
שיהיה בהצלחה!
—-

[א] דפדפן IE לא מחשיב את ה port כחלק מה origin עבור גישה ל DOM. בפועל נדירים מ המקרים בהם דף HTML ייטען מ port לא סטנדרטי.

[ב] המגבלות שונות מדפדפן לדפדפן: IE, פיירפוקס, כרום, ספארי (יש לגלול ל CVE-2010-0051) ואופרה (לפני השימוש ב blink). אינני מתחייב שהרשימה מלאה ו/או מעודכנת.

בלי הרבה מילים: מצב הדפדפנים לאחר שנה

בפוסט שפרסמתי לפני כשנה, מה הבעיה של אינטרנט אקספלורר?, הצגתי כמה בעיות של הדפדפן:

  • אימוץ אטי של גרסאות חדשות (גם בשל הרבה משתמשי חלונות XP)
  • תמיכה ב HTML5 – הרבה מאחורי שאר הדפדפנים.
  • כלים למפתח (בתוך הדפדפן), המפגרים הרבה אחרי המתחרים.
עברה שנה. חלונות 8 שוחררה ובקרוב תשוחרר חלונות 8.1.
IE10 זמין למשתמשי Windows 7 ויש כבר גרסת בטא של IE11.

אז מה השתנה?

הנה כמה נתונים:

(המסגרת הורודה מתארת את חלון הזמן של השנה האחרונה)

מקור

כפי שציינתי בפוסט ההוא, StatCounter נחשב למקור המאוזן ביותר בניתוח פלח השוק של הדפדפנים. ע\”פ StatCounter נראה שכרום רק הולך וצומח ללא הפרעה.

מקורות נוספים:

  • W3C Counter
  • Clicky – שימו לב ש IE נופל בסוף השבוע לטובת כרום (בית) ואז בתחילת השבוע חוזר לעצמו (עבודה).
  • NetMarketShare (קיצוני לטובת IE. לא מאוזן).
  • W3Schools (קיצוני לטובת כרום, לא מאוזן).

ומה עם גרסאות IE השונות?

נראה ש IE10 תפס את הבכורה בקרב גרסאות ה IE! (חיזוק נוסף) – בעיקר על חשבון IE9 (כנראה משתמשי חלונות 7).
זו בשורה טובה למפתחים!

ידוע לנו שבשוק הארגוני מגמת השינוי היא מתונה בהרבה – אבל לא ייתכן שהנתונים שאנו רואים כאן לא משקפים משהו גם ממה שקורה בתוך הארגונים. יש לי מעט נתונים על השוק הארגוני (ממדגם לא גדול במיוחד = אין אחריות). הנתונים אומרים:

  • כ 45% ל IE (חלוקה לגרסאות: 50% IE8, כ 3% ל IE10 וכל השאר מתחלק שווה בשווה בין IE7 ל IE9).
  • כ 25% ל כרום (עליה משמעותית!)
  • כ 20% ל FF.

אפשר לומר שהארגונים מתארים מצב שהיה קיים בשוק הכללי לפני כשנתיים.
כלומר: יותר IE8 מסה\”כ FF ורק מעט פחות מכרום. חבל.

אולי שווה להתבונן בחלוקה למערכות הפעלה בכדי להבין כיצד IE8 שורד:

מקור

להזכיר: IE8 הוא דפדפן ברירת המחדל של Window 7 + ה IE המתקדם ביותר שניתן להתקין על Windows XP.

תמיכה ב HTML5 הוא בחלט משהו שבמייקרוסופט שמו עליו דגש, אולם IE עדיין קצת מפגר מאחור.

מקור

הבשורה הטובה היא שהמכנה המשותף של HTML5 Support עלה בצורה משמעותית.
גם יש יותר דפדפני IE10, וגם התאימות של IE10 היא כבר \”במשחק\”. ברגע ש IE11 ישוחרר לחלונות 7 ו 8 (לאחר זמן מה – מייקרוסופט אישרה) – יש סיכוי טוב שהוא יהפוך לגרסת ה IE הנפוצה ביותר וכך תהיה עוד עליית מדרגה.

IE11 מציג שיפור משמעותי מול IE10 בסט הכלים למפתחים, אך הם עדיין בפיגור מורגש מאחורי Chrome או Firefox.

באשר למובייל:

אנדרואיד עברה כמעט מהפיכה בגרסאות שנמצאות בשימוש.
לאחר כשנתיים ש Gingerbread ו Froyo (גרסאות 2.2 עד 2.3) היו הרוב הגדול של השוק גרסת Jelly Bean (מספר 4.1 עד 4.3 שתשוחרר מיד) הפכה להיות הגרסה הנפוצה ביותר.

הנה מצב גרסאות האנדרואיד לפני שנה אחת, ואחורה:

אימוץ אטי מאוד של גרסאות אנדרואיד – בעיקר בשם היצרנים / המפעילים שלא מיהרו להתאים גרסאות חדשות למכשירים ישנים.

והמצב היום:

מקור: http://developer.android.com/about/dashboards/index.html

הנה פיזור הדפדפנים (החשובים) במובייל:

מקור

עדיין הדפדפן הנפוץ בעולם האנדרואיד הוא ה Android Browser הגוסס ולא כרום.
יש הבדל גדול ביכולות בין Android Browser של אנדרואיד 2 ל Android Browser של אנדרואיד 4 – חבל ש StatCounter לא מבחינים בניהם. עוד כמה נקודות לשים לב אליהן:

  • Chrome ל iOS הוא רק מעטפת ל Safari ולא באמת Chromium (בשל מגבלות שמציבה אפל) – אני מניח ש StatCounter סופרים אותו כספארי.
  • משתמשי iOS גולשים כפול בממוצע ממשתמשי Android – בעיקר בגלל שמכשירים רבים של אנדרואיד נקנים למדינות מתפתחות / ילדים, או פשוט החומרה החלשה שלהם הופכת גלישה לאטית בצורה לא סבירה.
  • למרות ניסיונות של גוגל, Chrome הוא דפדפן ברירת המחדל על Android בעיקר בקו Nexus – כלומר \”הטלפונים של גוגל\”.

עוד לינק מעניין הוא השוואת User Experience בין iOS 7 ל Jelly Bean. המסקנה מהכתבה: אפל היא כבר לא מובילת-חדשנות יחידה: היא מעתיקה לא פחות ממה שהיא מועתקת.

שיהיה בהצלחה!

קללת התאימות לאחור של Internet Explorer

עדכון 20 יוני: פוסט זה עבר שיפור כללי. תודה לר’ שהתקילה אותי בשאלות ועזרה לי לסדר את הנושא יותר טוב בראש  – סדר שאני מקווה שישתקף בשינוי שביצעתי.

את כתיבת הפוסט שאתם קוראים עכשיו התחלתי בעבר. הבנתי שחסר קצת רקע, והתחלתי להרחיב אותו. הרקע התארך והפך לפוסט בפני עצמו.

בפוסט זה אני רוצה לסכם כמה תובנות לגבי התמודדות עם קוד ישן של IE. בסופו של דבר הידע הוא לא מדע טילים, אך השקעתי שעות רבות על מנת “לדוג” אותו ממקורות שונים. כרגיל, אני מנסה לכתוב פוסטים שאני הייתי שמח מאוד לקרוא לו היו זמינים לי כשהייתי צריך אותם.

חלק גדול ממה שאכתוב פה על Quirks Mode נכון גם ל Firefox או אופרה – אבל עד היום לא נתקלתי באף אחד שהתעסק בנושאים אלו בדפדפן שאינו IE – ולכן אדבר רק על IE.

אם אתם לא כותבים קוד שנדרש לרוץ ב IE8 או גרסאות ישנות יותר, או שאתם יכולים פשוט להגדיר את Chrome Frame [א] שיפתור לכם את הבעיות – רוב הבעיות שיוצגו פה הן כנראה לא בעיות שלכם. אלו נושאים שגרמו סבל ללא מעט אנשים.
המניע לעיסוק המחודש בנושא זה הוא השחרור הקרוב של IE10 (במסגרת Windows 8).
בסוף הפוסט כללתי פרטים גם על גרסה זו.

נתחיל בשאלה, “מדוע מייקרוסופט תומכת לאחור בדפי אינטרנט ישנים ועקומים?”.

הערכה של ג’ון רזיג על היחס עלות / תועלת בתמיכה בדפדפנים. פילוח השוק של הדפדפנים שונה ממה שאני מכיר. מקור: http://www.manning.com/resig/resig_meapch1.pdf

מדוע מייקרוסופט תומכת לאחור בדפי אינטרנט ישנים ועקומים?
למייקרוסופט יש מדיניות ארוכת שנים של Backward Compatibility. בזמן שמתחרים כאלו ואחרים שברו את ה Backward Compatibility (אשתמש מעתה בקיצור המשעשע BC) של המוצרים שלהם, וכך שברו את ליבותיהם של אנשי ה IT שנאלצו להתמודד עם הצרה – מייקרוסופט תמיד הייתה שם בשבילם ותמכה לאחור. אפשר לומר שBC הוא Value Proposition או אפילו ערך מרכזי של החברה. ערך זה מתורגם כמובן למעשים:

Microsoft will offer a minimum of 10 years of support for Business and Developer products. Mainstream Support for Business and Developer products will be provided for 5 years or for 2 years after the successor product (N+1) is released, whichever is longer. Microsoft will also provide Extended Support for the 5 years following Mainstream support or for 2 years after the second successor product (N+2) is released, whichever is longer. Finally, most Business and Developer products will receive at least 10 years of online self-help support.

מקור

הנה כמה דוגמאות:

  • Silverlight 5, טכנולוגיה שנראה שמייקרוסופט רוצה לזנוח – תיתמך עד 2021.
  • Windows Vista הבעייתית תיתמך עד 2017. 5 שנים נוספות מעכשיו.
  • IE8, שהמהדורה אחרונה שלו (עם Bing כ Default) שוחררה ב 2010 – ייתמך עד 2020.
  • כיצד ניתן להסביר שמייקרוסופט הפסיקה לתמוך בIE6 המפורסם כבר לפני שנה?? האא… הוא שוחרר בשנת 2001.

שלא תבינו לא נכון: כמובן שיש ערך עסקי משמעותי בתמיכה לאחור. עבור רוב המשתמשים מוצרים ששוחררו לפני עשור (נאמר Office 2000) הם מספיק טובים ושדרוג הם כאב-ראש ועלויות מיותרות. העניין הוא שיש ערך כספי, לעתים רב, בשחרור גרסאות חדשות (למשל, אופיס) ואז נוצרת קשת של גרסאות שונות שזמינות בשוק – ומי שמפתח מוצר צד שלישי נאלץ להתאים את עצמו למספר גרסאות.

“העולם שלנו לא נעשה איטי יותר – להיפך”. שחרור של גרסה פעם בשלוש-ארבע שנים יצאה לה מהאופנה וברגע שמייקרוסופט מתחילה לשחרר מוצרים, למשל את IE, פעם בשנה – 10 שנות תמיכה היא תקורה משמעותית מאוד להתמודד איתה.

בשנת 2020 מייקרוסופט עתידה לתמוך ב 11 גרסאות שונות של אינטרנט אקספלורר: IE8, IE9, IE10, IE11, IE12, IE13, IE14, IE15, IE16, IE17 ו IE18 [ד]. בסוף פוסט זה תראו שכל גרסה של IE היא סיפור בפני עצמו.

כך עובדים ערכים של חברה: הם מחלחלים לכל פינה. לטוב ולרע.

ה”תאימות לאחור” מתחילה להסתבך
עד כמה שידוע לי הגרסה הראשונה של IE שידעה לרנדר (render) דף HTML ביותר מצורה אחת היא IE6. מייקרוסופט קוראת למודים אלו Document Modes, אני אשתמש בפוסט זה בשם Rendering Mode שנראה לי פחות מבלבל. החלק בדפדפן שאחראי על ציור הדף נקרא Rendering Engine או Layout Engine. הוא מפענח את ה HTML וה CSS, בונה בזיכרון את ה DOM מה-HTML ו Style Tree מה-CSS, מרכיב אותם אחד על השני ומצייר את התוצאה על המסך. המנוע בו IE ל Windows משתמש נקרא Trident (= קלשון, בעברית).



מנוע הרינדור של IE6 הוסיף תמיכה תקנית ב Box Model (הוסבר בפוסט הקודם) – שינוי די משמעותי ש”שובר” דפים שעבדו ב Box Model הישן. על מנת לתמוך “גם וגם” הוא הגדיר 2 מודים:

  • IE6 Standards Mode – שהציג את ה Box Model בצורה התקנית.
  • Quirks Mode – שהציג את הדפים כפי שעבדו בגרסה הקודמת (IE 5.5) – ע”פ ה Box Model של IE.
וכיצד הדפדפן יודע אם מדובר בדף שנכתב עם Box Model “ישן” או “חדש”?
הבעיה הייתה לא רק של IE, אלא גם של FF ואופרה, ו W3C הגדיר פתרון: שימוש בתוית בשם DOCTYPE.
הפתרון, בהפשטה מסוימת, הוא כזה: אם הדף הוא מסוג “חדש”, כלומר פועל ע”פ הסטנדרטים של W3C בכל הנוגע ל Box Model ובכלל – הוא יסומך בעזרת תוית DOCTYPE, שממוקמת בראש הדף, מעל תג ה HTML.
 
אם לדף לא הייתה תגית DOCTYPE – מניחים שמדובר בדף ישן מאוד ולכן IE יריץ אותו ב Quirks Mode. גישה זו שמרה על תאימות טובה לאחור, מכיוון שלא היה צריך לבצע שינויים בדפים ישנים: פשוט לא הייתה בהם תגית DOCTYPE [ה].
יש לציין ש IE6 Standards Mode הוא המוד של IE6 לתמיכה בסטנדרטים, על אף שהתמיכה שהוא מספק היא חלקית למדי.

 
IE7 שיפר את מנוע הרינדור. הוא תיקן סטיות רבות מתקן ה CSS שהמפורסמת בהן היא תמיכה בשקיפות של קובצי PNG.
מוד הרינדור של IE6 פשוט שופר והוחלף והוא נקרא IE7 Standards Mode.
IE8 כבר עבר את מבחן ה ACID2 (לבדיקת תאימות של דפדפנים לסטנדרטים), אחרי שנים ש IE נכשל במבחן בנחרצות. הוא הוסיף תמיכה, כמעט מלאה, ב CSS 2.1.
CSS 2.1 הוסיף מורכבות חדשה. הוא הגדיר את הדרך בה נקבע הגובה של תאים בטבלה, דרך ששונה ממה ש IE נהג לחשב. שימוש בטבלאות “בלתי נראות” לצורך עימוד הדף היה מאוד נפוץ באותה תקופה – ודפים שנכתבו עבור IE6 או IE7 והוצגו ע”פ הצורה הסטנדרטית של CSS 2.1 – שובשו קשות.
W3C שוב בא לעזרה והגדיר תקן ל Almost Standards Mode, מוד בו הדפדפן מציג דף ע”פ התקן, חוץ מחישוב גובה התאים בטבלה – שמחושב בצורה בה IE נהג לחשב אותה בעבר.
מוד זה נתמך ב IE כמובן, אך גם על גבי פיירפוקס וכרום.


וכיצד הדפדפן יודע “עבור איזה דפדפן נכתב דף ה HTML שמורץ כרגע”?
– W3C הוסיפו הגדרת DTD (אימות מבנה הדף) על תג ה DOCTYPE. סימון Strict Mode מעיד על תמיכה בתקן החדש ו Loose או Transitional הם מודים “רכים” שעובדים ע”פ ההגדרות הישנות.


בניגוד להוספת ה DOCTYPE המקורי, שדף ישן לא דרש שינוי (מכיוון שאין לו Doctype) – במקרה זה אם לא מצוין DTD ההנחה היא שהדף הוא “חדש”.


מייקרוסופט, שמחויבותה לתאימות לאחור – גבוהה, החליטה להתעלם מהתקן ולהתייחס לDOCTYPE ללא DTD כדפים ישנים (כלומר Almost Standards Mode) אולם החלטתה יצרה מהומה לא קטנה שבסופה היא התקפלה והחליטה לפעול ע”פ התקן. על פניו, נראה שהגישה של מייקרוסופט הייתה עדיפה מקומית, אך לאורך זמן קיומו של תקן אחיד הוא חשוב אפילו יותר.

הצורך לחזור ולשנות את ה Markup (או קוד, אם מדובר בדף דינאמי) של דפים קיימים על מנת שיוצגו בצורה טובה היה בלתי נסבל עבור מייקרוסופט. מייקרוסופט התמודדה עם הבעיה בעזרת הצגה של תווית META חדשה (שניתן להגדיר גם ברמת פרוטוקול ה HTTP) שדורסת את ההחלטה של ה DOCTYPE לגבי המוד בו יש לרנדר את הדף. Application Servers היו יכולים בדרך זו לשתול את התגית החדשה ברמת ה HTML HEAD או ה HTTP וכך לגרום לדפים שתוכננו עבור IE7 להתרנדר ב Almost Standards Mode – כך שייראו היטב. התגית ה META נראית כך:

<meta http-equiv="X-UA-Compatible" content="IE=7" />
ל IE8 כבר יש אלגוריתם לא פשוט לבחירה ב Rendering Mode (מתוך ה 4 הקיימים). תוכלו למצוא תרשים זרימה וועוד מקור המתארים את האלגוריתם.

עוד השפעות של התאימות לאחור ב IE8 (המשפיעות גם על IE9 ו IE10)

בניגוד ל IE7, שלא שמרה על תאימות מדוייקת ל IE6 Standards Mode, החליטה מייקרוסופט החל מ IE8 (אולי בגלל תלונות של לקוחות) לשמור העתק מדוייק של הדרך בה הדפדפן הקודם רינדר את הדף. זהו ה IE7 Standards Mode שקיים ב IE8. אפילו כאשר מייקרוסופט מציגה מנוע רינדור משופר – הדפדפן יידע להציג את הדף בדיוק רב מאוד לצורה בה הדפדפן הקודם והפחות מוצלח הציג אותו.

החלטה הזו תקפה לא רק על ה Rendering Engine אלא גם על ה JavaScript Engine: באגים וחוסרי תאימות שהיו קיימים ב IE7 נשמרו במנוע הג’אווהסקריפט של IE8 (והלאה). אם הדף מרונדר ב IE7 Standards Mode, מנוע הג’אווהסקריפט החדש יפעיל את משפטי ה IF [ו] המתאימים ויתנהג בדיוק כמו שהתנהג ב IE7.


הערה: מפתחים שרוצים לדעת איזו גרסה אמיתית של IE רצה מולם נתקלים בקושי: ה BC גורם לדפדפן להתנהג בדיוק כמו דפדפן ישן יותר וזה כולל User Agent, יכולות נתמכות ואפילו מנוע ה JavaScript ש”משחזר” באגים ישנים. הדרך האמינה לדעת מול איזה גרסה של IE אתם עובדים היא לתשאל את גרסת ה JavaScript Engine. שלא תזדקקו לזה.

בנוסף, מייקורוסופט לא סומכת רק על ה DOCTYPE ותוית ה X-UA-Compatible שיידעו כיצד על הדף להתרנדר. מייקרוסופט מנהלת רשימה של Domains של אתרים פופולריים וה Rendering Modes של IE בהם הם רצים בצורה הטובה ביותר. רשימה שנוצרה ומתוחזקת בצורה ידנית, כנראה. IE קורא את הרשימה ומגיב אליה.
מייקרוסופט מאפשרת לארגונים לנהל רשימה נוספת משלהם שתשפיע על כל דפדפני ה IE בארגון שלהם.
תוכלו למצוא כיצד רשימות אלו משתלבות באלגוריתם הבחירה בתרשים הזרימה שקישרתי למעלה.

התאימות לאחור ממשיכה להסתבך: IE9
בעת פיתוח IE9, ניצב בפני מייקרוסופט אתגר חדש: התמיכה בשרשרת תקנים שאנו מכירים אותם כיום כ HTML5 ו CSS3. תקנים אלו הם עליית מדרגה מול היכולות שהיו בדפדפנים עד כה. נראה שהמפתחים של IE החליטו שעל מנת לתמוך בתקנים אלו, בצורה Preformant, יש עליהם לכתוב את מנוע הרינדור מחדש.
מה עושים עם התאימות לאחור? אין ברירה. משלבים בדפדפן החדש, IE9, שני מנועי רינדור שונים: מנוע ישן (של IE8) ומנוע חדש שיתמוך בתקנים החדשים:

כל טאב ב IE9 מתרנדר או במנוע החדש או במנוע הישן – אך אף פעם לא בשניהם ביחד.
אם יש דף עם iFrames ייתכן והדף החיצוני (מה שנקרא topFrame) מרונדר במוד אחד (נאמר IE9 Standards) בעוד ה iFrame הפנימי מרונדר במוד אחר (נאמר QME). אולם, בניגוד ל IE6 עד IE8 בהם יכול היה הדפדפן לבחור עבור כל iFrame כל מוד מהרשימה הנתמכת, ב IE9 יש בחירה של מנוע הרינדור ומאותו הרגע הבחירה למוד עבור על Frame מוגבלת למודים הזמינים עבור אותו מנוע רינדור.

הבחירה במנוע הרינדור היא דיי פשוטה: בפעם הראשונה שהדפדפן מזהה סימן שמעיד טיפוס הדף (יהיה זה X-UA-Compatible ברמת ה HTTP או תג Doctype) – הוא בחור את המוד המתאים מכל הרשימה. מנוע הרינדור שיודע לצייר מוד זה הוא מנוע הרינדור ש IE ישתמש בו לשאר הדף.

ריבוי ה Rendering Engines, אם כן, משפיע רק על דפים הכוללים Frames או iFrames. במקרים אלו ה Top Frame יכתיב את מנוע הרינדור עבור ה iFrames שהוא מארח.

הנה הדגמה של התנהגות זו בפועל:
כתבתי דף פשוט בשם page.html שידמה אפליקציה עסקית (הוספתי Source Code בתחתית הפוסט [ג]). הדף מכיל מספר אלמנטים שבהם יש בעיות של תאימות לאחור:

  • עיגול המצוייר ב SVG (תכונה של HTML5)
  • תיבה עם צבע שהוגדר פעמיים: פעם בצורה תקנית (כתום) ופעם נוספת בצורה לא תקרנית (טורקיז).
  • אזור אפור (border עבה במיוחד) שגובהו יהיה חצי מהתיבה ע”פ ה IE Box Model ושליש מהתיבה ע”פ ה W3C Box Model.
אם אני שם בראש דף זה תגית DOCTYPE הוא ייראה שונה למדי מאשר אם לא תהיה תגית כזו. אם יש תגית Doctype אזי IE ייבחר מוד רינדור שונה מזה בו אין Doctype.
ייתרה מכך, אם אשים 2 עותקים של הדף page.html בתוך דף מארח (topframe) – ה Doctype של הדף המארח ייבחר עבורי מנוע רינדור כך שהצורה בה ירונדר הדף תושפע פעם נוספת.
במקרה 1 למטה – הדף המארח מפעיל את מנוע הרינדור החדש (ומריץ את האפליקציה פעם במוד IE9 Standars ופעם ב QME).
במקרה 2 למטה – הדף המארח מפעיל את מנוע הרינדור הישן (ומריץ את האפליקציה פעם במוד IE8 Standards ופעם במוד Quirks Mode)
ההבדל היחיד בקוד בין מקרה 1 למקרה 2 הוא ה Doctype של ה topframe. התוצאות לפניכם:


חתיכת הבדל בשביל Doctype – לא?

אתם יכולים להבחין ב Scrollbars שונים בשני המקרים שנובעים מ Defaults שונים בין המודים השונים. הבדלים אלו אמורים להתאפס בעקבות CSS Reset.

השלכה משמעותית של ההפרדה ל 2 מנועי רינדור שונים אי חוסר היכולת (בעזרת ifלהציג HTML5 באותו הדף עם תאימות מלאה לדפים ישנים מאוד (Old Quirks Mode) – שיש רבים כאלו במערכות עסקיות.

כיצד מתמודדים עם זה? מייקרוסופט הוסיפה מוד בשם (QME (Quirks Mode Emulation שתואם, במידה רבה, לתקן של W3C כיצד יש לרנדר Quirks Mode – כלומר דפים ישנים מאוד.

ה QME לא מתועד בצורה ברורה כמוד של IE9. לקח לי כמעט חודש של התעסקות בנושא עד שהבנתי שהוא קיים. מייקרוסופט לעיתים קוראת לו “Quirks Layout” (נשמע כמו מימד אחר של פונקציונליות) או Quirks within IE9 Engine – שיכול בקלות לבלבל עם ה Quirks Mode שקיים במנוע הישן. ב Dev Tools של IE10 הוא נקרא פשוט “Quirks Mode” בנוסף ל “Explorer 5 Quirks” שקיים שם. בקיצור: מבלבל. רק לאחרונה אני נתקל במונח QME בצורה יותר מפורשת וברורה.

הנה תיעוד שמציין את קיום ה QME – הייתי זקוק לו בכדי להיות בטוח שאני לא מדמיין. הסיבה שהמוד לא מפורט ברשימת ה modes של הדפדפן קשורה כנראה לכך שIE9 לא מאפשר להשתמש במוד זה ב topmost Frame – כלומר הוא מותיר להשתמש בו רק בתוך iFrames. 
הנה תיאור של ההבדלים בהתנהגות של QME. גם לדפדפנים אחרים יש QME . הנה הגדרת ההתנהגות של QME ב FF.

כשמפעילים את כלי הפיתוח של IE (לחיצה על F12), יש אפשרות לדרוס בכוח את המוד בו ירוץ הדפדפן. אין פה QME או Almost Standards Mode. אליהם ניתן להגיע רק בעזרת אלגוריתם ההחלטה של ה Rendering Modes. האלגוריתם שונה בין הגרסאות של הדפדפן ולכן בכלי הפיתוח ניתן לבחור Browser Mode שהוא קובע באיזו גרסה של האלגוריתם להשתמש. נסו להבין את זה לבד : )

הנה תיאור האלגוריתם בעזרתו IE9 מחשב באיזה Rendering Mode להריץ את הדף. דיי דומה ל IE8 – אך השפעותיו  משמעותיות יותר. 

התאימות לאחור עושה קאמבק (קטן): IE10

בניגוד ל IE9 בו התמיכה ב HTML5 ו CSS3 היא דיי בסיסית, IE10 תומך בתקנים אלו בצורה דיי יפה. ניתן לומר שהוא כמעט in line ביחד עם שאר הדפדפנים בתחום זה.

ב IE10 בוצעו כמה שינויים שמשפיעים על ה BC:

ה Default Rendering Mode עבור מסמך ללא Doctype הוא QME ולא IE5.5 Quirks Mode – מקור. התנהגות זו רצויה, אך היא תגרום לדפי Quirks Mode שרצו יפה ב IE9 – לרוץ פחות יפה ב IE10.
פתרון פשוט: להוסיף תג X-UA-COMPATIBLE, ie=7 בכדי להכריח את מנוע ה rendering הישן לרוץ.
פתרון נכון: לתקן את הדפים לעבוד ב QME, לא לדחות את ההתנתקות מ IE5.5 לנצח! ההבדלים העיקריים בין Quirks Mode ל QME הם מסביב לטבלאות, Box-Model (ניתן לתקן בקלות בעזרת CSS) והדבר הכי קשה: באגים שהיו ב IE5.5, תאימותם נשמרה עד ל IE8 – אך הם תוקנו ב QME.

QME נתמך גם ב topframe, בשונה מה IE9 – אך בדומה לFF או כרום. נראה גם שהיישום של QME קרוב יותר לסטנדרט מאשר IE9 – אך קשה לומר בוודאות לפני ש IE10 ישוחרר ויהיה יותר נסיון לקהילה איתו.

ביטול התמיכה ב Conditional Comments (כגון  <!–[if IE]>).
ביטויים אלו נמצאים בשימוש בכמה ספריות מודרניות כגון ie7.js ו html5shim – אך אלו ספריות של תאימות לאחור שלא יזדקקו, כנראה, ליכולת זו ב IE10. אם הקוד שלכם עושה כאלו בדיקות (נו, נו, נו!) – הזהרו.

בראייה ארוכת טווח, זו כמובן החלטה טובה של מייקרוסופט.

Windows 8 מציגה שני סוגים של “סביבות עבודה”: Metro ו Desktop.
Metro הוא ברירת המחדל והעתיד. אופיס 2013 יקבל ממשק מטרו, למשל. מטרו הוא Touch Enabled ויהיה הסביבה היחידה על Windows 8 Tablet.
Desktop היא הסביבה שאנו מכירים מאז Windows 95 ועד Windows 7. סרגל משימות, תפריט “התחל” וכו’.

חווית השימוש ב IE10 בסביבת המטרו היא שונה מסביבת העבודה של ה Desktop. למשל, Plug-Ins ו ActiveX לא ירוצו בסביבת המטרו. פלאש דווקא כן. אם יש לכם דף שמכיל Plug-Ins ואתם רצים על בסביבת המטרו – הדפדפן יפנה אתכם לסביבת ה Desktop. לא בהכרח התנהגות BC מלאה, אך אני מוצא אותה סבירה. ב Tablet כנראה תהיה סתם הערת שגיאה או פשוט התעלמות.

תעשו חיים!

מקורות נוספים בנושא:

–

[א] Chrome Frame[ב], למי שלא מכיר, הוא Plug-In של גוגל ל IE שכולל את מנוע ה Rendering של Chrome ויכול, ע”פ תג Meta במסמך ה HTML – להפעיל את הדף, מעשית, בכרום[א]. התקנתו לא דורשת הרשאות Administrator והוא יכול להריץ את הגרסה האחרונה של Chrome (כלומר מנוע HTML5 מעולה) בתוך IE6 המיושן. טקטיקה מקובלת היא “לתמוך ב IE6 ו IE7 בעזרת Chrome Frame”, כלומר: להפעיל עבור משתמשי IE ישנים את כרום מאחורי הקלעים. יש לשיטה זו כמה מגבלות בכל הנוגע לתקשורת בין iFrames.

[ב] יש לבטא “קרום” ולא “ח-רום” – כפי שישראלים רבים נוהגים.

[ג] 

[ד] נשמע לי קצת מופרך לתאר משהו שיקרה 8 שנים מעכשיו: עידן ועידנים. אני מניח שמשהו יקרה וזו לא תהיה התוצאה בפועל.

[ה] התקן ביקש מבעלי דפים ישנים, כגון HTML 3.2 לסמן את הדפים שלהם ב DOCTYPE מסוים (ש IE ידע להתעלם ממנו) – אך לא הייתה לבעלי הדפים מוטיבציה אמיתית לבצע סימון שכזה.

[ו] אני מניח ומקווה שהשתמשו ב Strategy Design Pattern ולא באמת במשפטי IF.

–>

מה הבעיה של Internet Explorer?

בשבוע האחרון הייתה חגיגה רבתי ברחבי האינטרנט: דפדפן כרום עקף את דפדפן האינטרנט אקספלורר בנתח הגלישה.

האמנם כך? אם כן – מדוע אתרים כגון Stat Owl עדיין טוענים שIE מחזיק את הכתר בבטחה?

ובכן, איסוף נתוני גלישה היא משימה לא פשוטה ולא מדויקת:

  • במשך השבוע האנשים גולשים בעיקר ממקומות העבודה, שם IE (אינטרנט אקספלורר) הוא הדומיננטי[א] ובסוף השבוע הם גולשים מהבית בעיקר בכרום או FF. ההבדלים במדידות בין יום ראשון (יום חופש) ויום שני (יום עבודה) הם דרמטיים.
  • זהות הדפדפן הנפוץ היא שונה למדי בין צפון אמריקה, אירופה, דרום אמריקה וסין.
  • האם מדובר על התקנות או על שימוש? למשל, על מכשירי טלפון יש הכי הרבה התקנות של דפדפן Opera (לרוב מכשירים זולים או ישנים – יש הרבה כאלה במדינות מתפתחות) . לא ברור בכלל איזה אחוז מבעלי הטלפונים האלה השתמש איי פעם בדפדפן שלו. אם מודדים את תעבורת הרשת – אז עיקר התעבורה נעשית מספארי (של אפל).
  • איך מודדים גלישה? זמן שהדפדפן פתוח? תעבורת רשת או מספר page views?
בהינתן שלכל אחד מהמקורות שמציגים נתונים על נתח השוק של הדפדפנים יש בסה\”כ מדגם סטטיסטי, ובהינתן השאלות הנ\”ל, ניתן להבין כיצד גופי מחקר שונים יכולים להגיע לתוצאות שונות כ\”כ. נתח השוק של IE יכול לנוע בין 25% ל 55% – תלוי במקור.
בכל זאת יש מספר מצומצם של מקורות שנחשבים מקובלים ואמינים יותר מהאחרים, ששיטת הבדיקה שלהם נכונה יותר. הידוע בניהם הוא StatCounter ולפני שבוע הוא הכריז רשמית שכרום עקף את IE גם בימי העבודה [ה] – כלומר בימים בהם ל IE יש יתרון.
הדפדפן הנפוץ – ע\”פ מדינה. כחול = IE, ירוק = כרום, כתום = FF, אדום = Opera. מקור: wikipedia
תחת אווירה עוינת וכמה הצהרות תקשורתיות ומיליטנטיות, ניתן לחשוב ש IE כבר אינו רלוונטי. ב SAP אנו עדיין תומכים ב IE גרסה 6 במוצרים חדשים, אולי בקרוב נתמוך \”רק ב IE7\”. עד עתה הנחתי שהבעיות שנוגעות ל IE שאני מתמודד איתן הן נקודתיות ולא רלוונטיות לכלל ציבור המפתחים. מה שקצת שינה את דעתי הוא הסקר הזה (יש לענות על מנת לראות את התוצאות).
מסתבר שכמה חברות הפונות לשוק הפרטי תומכות בגרסאות ישנות של IE כדי לא לאבד את נתח השוק הקטן שהן מייצגות ושיש לא מעט מפתחים שעדיין מתעסקים עם IE עבור ארגונים. ועוד מדובר בסקר של Paul Irish – המייצג את הפלח החדשן של מפתחי הווב.
קצת היסטוריה: מאיפה הגיע ה Quirks Mode וה Standards Mode?
בשנות ה-90 דפדפן אינטרנט הייתה תוכנה ייעודית עבור אלו שהתעסקו ב\”אינטרנט\”, לא משהו מובן מאליו[ד]. היו מספר דפדפנים חינמיים (מבוססים על מנוע בשם מוזאיק, שפותח ע\”י גוף ממשלתי של ארה\”ב) אך הדפדפן שהתבלט היה  Netscape Navigator – שפותח ע\”י חברה מסחרית קטנה שזה היה כל עיסוקה.
Netscape שיפרה את חווית הגלישה והפכה אותה לנוחה יותר. היא למשל פיתחה את קונספט ה \”bookmarks\” שזכה להצלחה רבה. השיפורים הללו הקנו לה יתרון ומשתמשים החלו לשלם כסף עבור \”דפדפן יותר טוב\”. Netscape Navigator הפך לדפדפן הנפוץ ביותר בעולם.

השחקנית הרצינית הבאה שנכנסה למערכה היא לא אחרת מאשר הגורילה מרדמונד, הלא היא מייקרוסופט. מייקרוסופט החליטה שהיא רוצה ליצור דפדפן נפוץ והיו לה את כל הכלים לעשות זאת: היא לא הייתה זקוקה לרווחים ויכלה לחלק את הדפדפן שלה בחינם, היה לה גוף פיתוח רציני, אבל הכי חשוב: היא שחררה את הדפדפן כחלק ממערכת ההפעלה, כך שהמשתמש הפשוט לא היה צריך לחפש \”איזה דפדפן לקנות או להתקין\” – הוא פשוט היה שם והוא עבד היטב. הדפדפן של מייקרוסופט נקרא Internet Explorer – בקיצור IE.

אמנם ל Netscape היה יתרון שכבר היה לה מוצר קיים, אך תוך שנתיים מרגע השחרור של IE1 מייקרוסופט שחררה את IE4 שכבר נחשב למוצלח יותר מזה של חברת Netscape. הדפדפן של Netscape היה מבוסס על \”קוד ספאגטי\” והפיתוח על בסיס בקוד הקיים היה קשה. גרסה 5 של הדפדפן בוטלה לאחר שהפיתוח שלו התמשך והתמשך ללא תוצאות. ה Technical Debt הגדול הכריע את חברת Netscape והיא החלה לפתח דפדפן חדש מאפס. במקביל היא ביצעה כמה צעדים, נואשים אולי, על מנת להתמודד עם מייקרוסופט, ביניהם תרומה של הגרעין של הקוד שלה לארגון Open Source שהוקם בשם מוזילה (על מנת לאפשר ייצורם של \”תואמי Netscape\” חינמיים שיזנבו ב IE) ומיזוג לתוך חברת התקשורת AOL.

הפיתוח של Netscape Navigator 6.0 התמשכה והתמשכה והפכה לבדיחה בתעשייה: דוגמה לסכנה הטמונה בפרויקט Next-Generation. מייקרוסופט שחררה בינתיים את IE5 וסיימה את כיבוש שוק הדפדפנים.
Netscape Navigator 6.0 ששוחרר בשנת 2000 כבר איחר את המועד ולא הצליח להתרומם. מייקרוסופט מחצה את התחרות.

נתח השוק של דפדפנים בין 96 ל 2009. מקור: wikipedia

עם נתח שוק של בערך 90% מייקרוסופט לא ראתה אף אחד ממטר. היא הגדירה הרחבות לא סטנדרטיות ל HTML, DOM ועוד ועודדה את המפתחים בעולם להשתמש בהם. ניתן להניח שזו הייתה דרך לבצע \”Lock-In\” של המפתחים ל IE.
בנוסף לכך, מייקרוסופט לא הצטיינה בהצמדות לסטנדרטים. אמנם הדפדפן שלה היה עדיף על זה של Netscape – אך עושר ה Features הוא מה שיצר את הייתרון – לא הדיוק בסטנדרט. נוצר בפועל סטנדרט חדש: \”כמו-IE\”.

חשוב להסביר שמייקרוסופט לא רק עשתה \”מה שבראש שלה\”. היו חלקים בסטנדרט שלא היו מוגדרים היטב והמפתחים של מייקרוסופט, ממש כמו המפתחים של Netscape, פירשו את התקן בצורה שנראתה להם הנכונה ביותר.

הנה דוגמה מפורסמת: לתיבה ב HTML (נאמר, אלמנט div) יש רוחב וגובה. ניתן להוסיף לתיבה margin ו padding – שהם ריווחים מבפנים ומבחוץ, וגם מסגרת בעלת עובי. אם קבעתי תיבה ברוחב 100 פיקסלים והוספתי לה מסגרת בעובי 2 פיקסלים (מכל צד) – האם היא תתרחב לרוחב כולל של 104 פיקסלים, או האם התוכן בתוך התיבה יצטמק ל 96 פיקסלים? זה עניין של פרשנות. המתכנתים של מייקרוסופט ושל Netscape פירשו זאת בצורה שונה.

פרשנות שונה ל box model, ע\”פ Netscape (שהפך לתקן ה W3C) ומייקרוסופט. מקור: wikipedia

ספציפית במקרה זה, אני (ועוד כמה אחרים) חושב שהמודל של מייקרוסופט היה מוצלח יותר. אבל גוף התקינה דווקא החליט להשתמש בפרשנות של לNetscape והפך אותו לחלק מהתקן [ב].

עלייתו של השועל
הסיאוב שנובע ממונופול לא פסח על מייקרוסופט. מייקרוסופט התעלמה מחלקים מסוימים בתקן, ולא מיהרה לאמץ חלקים חדשים. היה ברור לה איך צריך לבנות דפי אינטרנט: בדרך ש IE6 אוהב לאכול אותם, כמובן. אפילו יותר גרוע: לאחר גרסה IE6 היא הפסיקה להשקיע בפיתוח IE ובמשך 5 השנים הבאות שוחררו רק כמה תיקוני באגים ועדכוני אבטחה.

זוכרים את הקוד ש Netscape תרמה לארגון מוזילה? ארגון מוזילה המשיך, בשקט בשקט, לפתח את הקוד ובשנת 2004 מוזילה שחררה דפדפן חדש בשם פיירפוקס (שועל האש). פיירפוקס הכיל חידושיים אמיתיים בחווית הגלישה, כשהבולטים בהם הם השימוש בטאבים והקלות בפיתוח Plug-Ins. מייקרוסופט מצידה נרדמה בשמירה והצהירה ש FF לא מהווה איום עליה. רק בגרסה 3, בערך (שנת 2008), FF היה מספיק בוגר ומהיר על מנת שייחשב כעליון על IE6. אחד המאפיינים הבולטים שלו היו מהירות גבוהה, מהירות שגרמה ל IE6 להראות כמו מוצר שנזנח במשך חצי עשור.

נראה שמייקרוסופט התעוררה בסוף 2007, כשגרסאות בטא של FF3 היו זמינות בשוק – והיתרון של FF היה ברור. היא הסירה את הדרישה לבדיקות רישיון חוקי (Windows Genuine Advantage) כתנאי להתקנת IE7 (כל הישראלים היו תקועים עד אז עם IE6) והעירה את צוות הפיתוח שלה מתרדמת ארוכה והחלה לפתח את IE8 במרץ. IE8 סיפק תמיכה טובה בהרבה מ IE7 בסטנדרטים (כלומר: תמיכה סבירה) ומייקרוסופט ניסתה את מזלה ביצירת חווית גלישה חדשה בעזרת  ה Accelerators – ניסיון שנכשל.

ה Popup המעצבן הזה היה אמור להיות החוויה החדשה של גלישה בווב. למרות שנכשל חרוצות – אני עדיין מעריך את מייקרוסופט על שניסו.

מוזילה, בניגוד למייקרוסופט, הייתה קפדנית מאוד בהצמדות לתקנים. היא חרטה את התאימות לתקנים על דגלה והצליחה להביך את מייקרוסופט לא פעם. המשתמשים בחרו בפיירפוקס כיוון שהיה מהיר יותר, נוח יותר ומגניב יותר – אך הדיון בצורך בתקנים והתאמה של אתרים לדפדפנים שאינם IE חזרה לתודעה הכללית.
IE6, וכל גרסאות IE שיצאו אחריו, עדיין מאפשרים להריץ דפי אינטרנט בדיוק כפי שרצו על IE5.5 – דפדפן משנת 2000. למייקרוסופט הייתה חשובה התאימות לאחור והיכולת להריץ כהלכה דפי אינטרנט ישנים. מוד הרצה זה נקרא \”Quirks Mode\”. הוא זמין רק על גבי דפדפני IE, למרות שאופרה ו FF מספקים Quirks Mode Emulation (בקיצור QME) – מצב שבו דפדפנים אלו מציגים \”בקירוב\” דפים ישנים של IE.

עד היום FF הוא הדפדפן המחמיר ביותר בהצמדות לתקן. אפילו Chrome \”מוכן לוותר לפעמים למפתחים\”. הנה דוגמה פשוטה: URLs לתמונות בתוך קבצי CSS מחושבים יחסית למיקום של קובץ ה CSS. פיירפוקס לא יאפשר לנהוג אחרת. ספארי, כרום וIE ינקטו גישה מקלה ואם הם לא מוצאים את התמונה במקום המצופה, הם ינסו שוב בהנחה שה URL הוא יחסית לדף ה HTML – טעות נפוצה של מפתחים. האם הקלה בתקן היא דבר טוב? היא חוסכת מהמפתחים לתקן את הקוד שלהם – אך מאפשרת יצירה של דפי אינטרנט לא תקניים. A Tradeoff.

בחזרה לעתיד: שנת 2010
אם פיירפוקס הצליח להפתיע את מייקרוסופט, הרי נראה שאת משמעויות כניסתה של גוגל למשחק מייקרוסופט לא עכלה לגמרי עד היום. גוגל הקימה צוות-על לפיתוח דפדפן-על בשל כרום בו וחרטה על דגלה ממשק משתמש מינימליסטי \”The invisible Browser\” ומהירות גבוהה. למשך תקופה, כרום היה כ\”כ מהיר כך שהמהירות של FF נראתה כמו בדיחה. במקביל, גוגל הזרימה מאות מליוני דולרים ותמכה ב FF – ועזרה לו להגיע לשיאים חדשים. ע\”פ גוגל, בעלות על הדפדפן הנפוץ בעולם זה נחמד – אך זו אינה המטרה. לגוגל חשוב אפילו יותר שהאינטרנט יהיה נוח לשימוש – כך שחברות ימשיכו להסתמך עליו בפיתוח המערכות והאתרים שלהן, ותואם לסטנדרטים – כך שיהיה קל לחפש בו.

כרום ופיירפוקס קיבלו בברכה את תקן ה HTML5 המתהווה והן משפרות את התמיכה בו ללא הרף. מייקרוסופט משקיע הרבה מאמצים בשנתיים האחרונות בתאימות לתקן – אך היא עדיין משתרכת מאחור. כאשר מייקרוסופט תשחרר את IE10 – דפדפן שהשקיעה בו המון, הוא עדיין יהיה במקום האחרון בתמיכה ב HTML5. זה עוד לא הכל:

1. מייקרוסופט משחררת דפדפנים לאט. לאחרונה עדכנה את המדיניות שלה לעדכון פעם בשנה – צעד מהפכני מבחינתה. אולם, פיירפוקס וכרום משחררים גרסה כל 6 שבועות, והמשתמשים שלהם משפרים את יכולות הדפדפן שלהם כל הזמן. בין שחרור גרסה לגרסה של מייקרוסופט – משתמשי כרום וFF יעדכנו את הדפדפן שלהם 9 פעמים בממוצע ויהנו במשך תקופה מעוד ועוד תמיכה ב HTML5. 
תאימות של דפדפנים ל HTML5. מקור: html5test.com

2. בעוד כרום ופיירפוקס מעדכנים את גרסת הדפדפן אוטומטית, IE יתעדכן רק בעקבות הסכמה מפורשת של המשתמש.
בנוסף לזאת, IE מציבה קשיים בעדכון של גרסאות חדשות: אם אתם רוצים את IE9 עליכם להיות בעלי Windows Vista SP2 ומעלה. עבור IE10 תאלצו להיות בעלי Windows 7 ומעלה.

הווה אומר: משתמשי Windows XP, שהם עדיין רוב משתמשי ה Windows בעולם, לא מסוגלים לשדרג ל IE9 – הדפדפן הראשון של מייקרוסופט שניתן לייחס לו תמיכה סבירה ב HTML5. מצד שני, אין להם בעיה להשתמש בגרסאות האחרונות של כרום או פיירפוקס – מה שמצביע שההחלטה של מייקרוסופט נובעת משיקולים עסקיים. נראה שIE נדרש \”לדחוף\” שדרוגים של מערכת ההפעלה Windows, ואינו חופשי להתחרות בצורה \”חופשית לחלוטין\” מול הדפדפנים האחרים.

קצב השדרוג של גרסאות IE מול גרסאות כרום – הבדל דרמטי וקריטי. מקור: ArsTechnica

אם משווים את התמיכה ב HTML5 עבור ה\”משתמש הממוצע של כרום\” מול תמיכה ב HTML5 עבור ה\”משתמש הממוצע של IE\” הפער הוא אדיר. הרכיבו את שני התרשימים האחרונים בכדי להבין את גודל הפער.

תופעת לוואי נוספת של הקושי של משתמשי IE בלשדרג את הדפרפן שלהם היא שעל מפתחי מוצרי הווב לתמוך ב 4 (ובקרוב 5) גרסאות שונות של IE, בעוד בכרום או פיירפוקס הצהרה מקובלת היא \”גרסה אחרונה בלבד\”. אפילו SharePoint של מייקרוסופט אמצה מדיניות זו. לא פלא שמפתחים רבים מתוסכלים מהתמיכה בדפדפן IE.

יש פה משהו לא הוגן כלפי מייקרוסופט: התמיכה של IE בגרסאות ישנות נובעת מלקוחותיה שדורשים זאת. מייקרוסופט מחויבת לתמוך בכל מוצריה 10 שנים מרגע ששוחררו. ארגונים המפתחים תוכנות ארגוניות (בניהם גם SAP) לא רוצים לבצע בדיקות, כל 6 שבועות, שהתוכנה עובדת שלהם כמו שצריך. בפעמים רבות מדובר ב\”מסכים\” ישנים שאף אחד לא נגע בקוד שלהם במשך שנים – אך הם עדיין שימושיים. גרסה יציבה וידועה של הדפדפן חוסכת מכותבי התוכנה את הצורך בבדיקות רגרסיה מול גרסאות חדשות, ומהלקוח את מפח הנפש כאשר משהו לא יעבוד.
ולמה שמשהו לא יעבוד? חחחחח….. זו שאלה מצחיקה. IE6 למשל, הוא רחוק למדי מהסטנדרטים. עצם המעבר לתמיכה בסטנדרט עשויה לגרום לקוד הישן, הלא סטנדרטי, להפסיק לעבוד.
התמיכה של IE אחורה היא חרב פיפיות: ארגונים רבים לא נוטשים את IE בגלל התמיכה הזו, ומצד שני התמיכה הזו מקשה על IE להפוך לסטנדרטי ולהתקדם קדימה.

אם כן, מה האלטרנטיבות של מייקרוסופט? מה היא יכולה לעשות?
למוזילה יש תוכניות לספק \”גרסה יציבה\” של FF – מה שייקרא ESR, שתעודכן כל שנה – בדיוק לצרכים אלו. גרסה שתוכל לחיות side-by-side על אותו המחשב עם הגרסה העדכנית ביותר ולשרת שימוש בתוכנות ארגוניות ישנות.
היו קולות שקראו למייקרוסופט לנקוט גישה דומה, אך לא שמעתי אף שמועה על רמז לתגובה מצידה של מייקרוסופט. חבל מאוד.

Internet Explorer 10
אז אולי למייקרוסופט לא יהיה את הדפדפן הנפוץ או הטוב ביותר בשוק – מה הבעיה?

  • פגיעה במנוע החיפוש Bing. גם כאשר הוא מנוע החיפוש המסופק כברירת מחדל ב IE, משתמשים שונים מחליפים אותו ל Google. פחות חיפושים => פחות הכנסות מפרסום.
  • מוצרים רבים של מייקרוסופט הם מוצרי ווב. למשל: Office 365 ו Azure. הבעלות על דפדפן, והיכולת לקדם \”סטנדרטים\” בדפדפנים הם רוח גבית שמסייעת לשלמות של פתרונות הווב של מייקרוסופט. מגמה של אתרים שיפסיקו לתמוך ב IE, אם תהיה כזו, תפגע קשה ביכולת של מייקרוסופט לקדם מוצרים בעזרת הדפדפן.
  • Windows 8 הופך להיות מבוסס ווב ו JavaScript. השינוי הארכיטקטוני הגדול של מייקרוסופט ב Windows Vista (שהיה אסטרטגי, אך לא עניין את המשתמשים) היה לעבור ל Kernel מצומצם יותר ולהפוך את ה CLI (ה virtual machine של .NET) לסביבת ההרצה העקרית של Windows. חזון יפה ושאפתני.
    אבל מאז מחשבי הטאבלט הפכו למציאות ארגונית בה למייקרוסופט אין כרגע נוכחות. ההשקעה בפתרונות התלויים ב.NET ולא יכולים לרוץ על מחשבי טאבלט של אפל או אנדרואיד היא החלטה מגבילה למדי עבור ארגונים רבים. מייקרוסופט נאלצה להתכופף ברגע האחרון ולהפוך את JavaScript ו HTML5 ל \”First Class Citizens\” של Windows 8, אולי אפילו על חשבון טכנולוגיות .NET (נוכל לדעת זאת עם הזמן). הדבר העצוב עבור מייקרוסופט הוא ש IE10 שיתמוך באסטרטגיה הזו עתיד להיות בעת השקתו דפדפן בינוני למדי – יחסית לשאר הדפדפנים הזמינים [ג].

הגיע הזמן שמייקרוסופט תבין שאם היא רוצה בעלות על דפדפן מרכזי היא צריכה לשחרר את IE, ולאפשר לו להתחרות בפני עצמו, מבלי לקדם את Windows או מוצרים אחרים של החברה. אפשרות אחרת היא לקנות את קרן מוזילה – Opera תמכר כבר לפייסבוק – כך נראה.

שיהיה להם בהצלחה!

—-

קישורים רלוונטיים:
ההיסטוריה של אינטרנט אקספלורר (מפורט)

—-

[א] ההערכה שאני מכיר היא שבתוך ארגונים IE מהווה בערך 70% מסך הדפדפנים. זוהי הערכה פנימית ששמעתי במסגרת העבודה. אין לי מקורות חיצוניים ע\”מ לחזק אותה.

[ב] כיום, כשתמיכה בסטנדרטים היא פופולארית ואנו רגילים לנגח במייקרוסופט, לא מפליא למצוא ערך בוויקיפדיה כמו Internet_Explorer_box_model_bug

[ג] מייקרוסופט תטען אחרת, כנראה. אחד הגורמים שבהם מייקרוסופט מנסה \”למכור\” לנו את העליונות של IE10 היא בדיקות ביצועים של Canvas (כתיבה ישירה ל\”מסך\”) ו WebGL. דפדפן IE אכן נהנה מיתרון בכל הנוגע ל Hardware Acceleration במערכות Windows – אך זה רק מימד אחד ולא כ\”כ קריטי לדעתי.

[ד] הדפדפן הראשון, אגב, נקרא WorldWideWeb ונכתב ב Objective-C – שפה לא-חדשה בעליל.

[ה] הנה תגובתה של מייקרוסופט. http://windowsteamblog.com/ie/b/ie/archive/2012/03/18/understanding-browser-usage-share-data.aspx.