תאימות דפדפנים - איך מתמודדים עם ההבדלים בין הדפדפנים¶
"אצלי זה עובד" היא אולי המשפט הכי מתסכל בפיתוח פרונטאנד, כי הוא כמעט תמיד נכון - וזו בדיוק הבעיה. הקוד שלכם עובד מצוין בכרום שלכם, ואז מגיע דוח באג ממישהו שמשתמש בספארי או בדפדפן ישן יותר, ופתאום כלום לא עובד כמו שציפיתם. זה לא באג במובן הרגיל, זה תאימות דפדפנים, והיא חלק בלתי נמנע מעבודה בפרונטאנד.
למה זה בכלל קורה¶
לכל דפדפן יש מנוע רינדור משלו - כרום ואדג' מבוססים על Chromium, פיירפוקס משתמש במנוע משלו, וספארי במנוע אחר לגמרי. כל מנוע כזה מיישם את תקני ה-HTML, CSS ו-JavaScript בקצב משלו. פיצ'ר חדש שהתפרסם בתקן יכול להיתמך בכרום חודשים או שנים לפני שהוא נתמך בכל הדפדפנים האחרים. וזה לא רק עניין של "דפדפן ישן מול חדש" - גם בין גרסאות עדכניות של דפדפנים שונים יש הבדלים בפרטים קטנים, בעיקר ב-CSS.
זה אומר שקוד שנכתב תוך הסתמכות על פיצ'ר חדש, בלי לבדוק תמיכה, יכול להתנהג אחרת לגמרי בין דפדפן לדפדפן - מ"נראה קצת שונה" ועד "לא עובד בכלל".
הבדיקה שצריך לעשות לפני שסומכים על פיצ'ר - caniuse.com¶
לפני שאתם בונים על פיצ'ר CSS או JavaScript חדש שאתם לא בטוחים לגביו, ההרגל הכי חשוב הוא לבדוק תמיכה מראש באתר caniuse.com. מחפשים את שם הפיצ'ר, ומקבלים טבלה שמראה בדיוק באילו דפדפנים ובאילו גרסאות הוא נתמך. זה לוקח שלושים שניות ויכול לחסוך שעות של דיבוג מאוחר יותר, כשמתברר שהפיצ'ר שהתבססתם עליו פשוט לא קיים אצל חלק מהמשתמשים שלכם.
ההרגל הזה חשוב במיוחד כשעובדים בצוות עם קהל יעד מגוון - אם אתם יודעים שחלק ניכר מהמשתמשים שלכם עדיין על דפדפנים ישנים יותר, הבדיקה הזו הופכת מ"נחמד לבדוק" ל"חובה" לפני כל החלטה טכנית משמעותית.
פתרון אוטומטי לתחיליות ספק - autoprefixer ו-PostCSS¶
בעבר, כדי ש-CSS מסוים יעבוד בכל הדפדפנים, הייתם צריכים לכתוב כל כלל כמה פעמים עם תחיליות ספק שונות, כמו -webkit- או -moz-, כל אחת עבור מנוע דפדפן אחר. לכתוב את זה ידנית בכל מקום הוא גם מייגע וגם קל לטעות בו.
הכלי autoprefixer רץ כחלק מתהליך הבנייה (בדרך כלל דרך PostCSS) ומוסיף את התחיליות האלה אוטומטית, על סמך רשימת הדפדפנים שאתם מגדירים כיעד. אתם כותבים CSS רגיל ותקני, והכלי דואג להוסיף מה שצריך מאחורי הקלעים. זה אומר שאתם לא צריכים לזכור אילו תחיליות רלוונטיות לאיזה פיצ'ר - הכלי עושה את זה בשבילכם, ומתעדכן ככל שהתמיכה בדפדפנים משתנה.
פוליפילים - כשפיצ'ר JavaScript פשוט לא קיים¶
לפעמים הבעיה היא לא תחילית CSS חסרה, אלא פונקציונליות JavaScript שלמה שלא קיימת בדפדפן מסוים. פוליפיל הוא קטע קוד שממש "משתיל" את הפונקציונליות החסרה בדפדפן שבו היא לא קיימת מטבעו, כך שהקוד שלכם יכול להשתמש ב-API בביטחון בלי לבדוק כל פעם אם הוא באמת שם.
חשוב לזכור שפוליפיל לא הופך פיצ'ר איטי למהיר, או פיצ'ר מורכב לפשוט - הוא רק ממלא את הפער כדי שהקוד לא יקרוס בדפדפן שחסר לו התמיכה המקורית. כלי הבנייה המודרניים יכולים גם לזהות אוטומטית אילו פוליפילים נחוצים על סמך הדפדפנים שאתם תומכים בהם, כך שאתם לא טוענים פוליפילים מיותרים למשתמשים שכבר תומכים בפיצ'ר באופן טבעי.
זיהוי תכונות - הגישה הנכונה, לא זיהוי דפדפן¶
כשקוד JavaScript צריך להחליט אם להשתמש בפיצ'ר מסוים, יש שתי גישות אפשריות. הגישה השבירה היא "זיהוי דפדפן" (user-agent sniffing) - לבדוק את המחרוזת שהדפדפן שולח שמזהה את עצמו, ולהחליט לפי זה. הבעיה היא שמחרוזות האלה לא אמינות, קל לזייף אותן, ודפדפנים חדשים או גרסאות עתידיות עלולים לשבור את ההנחות שביססתם עליהן קוד ישן.
הגישה הנכונה היא זיהוי תכונות (feature detection) - במקום לשאול "איזה דפדפן זה?", שואלים ישירות "האם היכולת הספציפית הזו קיימת?" ובודקים את זה בקוד עצמו לפני שמשתמשים בה. הגישה הזו עמידה הרבה יותר לאורך זמן, כי היא לא מניחה שום דבר על מי כתב את הדפדפן, רק בודקת בפועל אם היכולת שאתם צריכים זמינה.
תמיד לבדוק ביותר מדפדפן אחד¶
הרגל אחרון שקל לדלג עליו כשלוחצים בזמן: לפני שמשחררים פיצ'ר, לבדוק אותו לפחות בשני דפדפנים שונים, ועדיף שלושה. זה לא צריך להיות בדיקה מלאה בכל דפדפן שקיים, אבל בדיקה מהירה בכרום ובספארי, למשל, כבר תופסת חלק גדול מהבעיות הנפוצות ביותר. זה עיקרון שמלמדים עליו בקורס צד לקוח - ההרגל של לבדוק במגוון סביבות לפני שילוח, לא אחרי שמתקבלת תלונה ראשונה ממשתמש.
לסיכום¶
תאימות דפדפנים היא לא בעיה שנפתרת פעם אחת, היא הרגל עבודה מתמשך - בודקים תמיכה מראש, נותנים לכלים אוטומטיים לטפל בתחיליות ובפערים, ובוחרים תמיד בזיהוי תכונות על פני הנחות שבירות. ברגע שההרגלים האלה נכנסים לשגרה, "אצלי זה עובד" הופך הרבה פחות רלוונטי.
נתקלתם בהבדל מוזר בין דפדפנים שתקע אתכם? ספרו לנו בדיסקורד.