המשתמשים שלך רוצים שאפליקציות אינטרנט לנייד מגיבות וגוללות בצורה חלקה למגע. הפיתוח שלהם אמור להיות קל, אבל לצערנו, האופן שבו דפדפני אינטרנט לנייד מגיבים לאירועי מגע במהלך הגלילה מופיע כפירוט של היישום במפרט TouchEvent. כך אפשר לחלק את הגישות ל-4 קטגוריות, פחות או יותר. המצב הזה חושף מתח מהותי בין היכולת לגלול בצורה חלקה לבין שמירה על שליטה של המפתחים.
ארבעה מודלים שונים של עיבוד אירועי מגע?
הבדלי ההתנהגות בין הדפדפנים מתחלקים לארבעה מודלים.
עיבוד אירועים סינכרוניים רגילים
אירועי Touchmove נשלחים במהלך גלילה וכל עדכון גלילה חוסמת עד להשלמת הטיפול ב-Touchmove. זו האפשרות הפשוטה ביותר להבנה והחזקה ביותר, אבל גם מזיקה לביצועי הגלילה, כי המשמעות היא שכל פריים במהלך הגלילה צריך לחסום ב-thread הראשי.
דפדפנים: דפדפן Android (Android 4.0.4, 4.3), Safari בנייד (בזמן גלילה div)
עיבוד touchmove אסינכרוני
אירועי Touchmove נשלחים במהלך הגלילה, אך הגלילה יכולה להמשיך באופן אסינכרוני (המערכת מתעלמת מאירוע touchmove לאחר הגלילה). הדבר עלול לגרום ל'טיפול כפול' באירועים. לדוגמה, המשך הגלילה אחרי שהאתר מבצע פעולה כלשהי באמצעות touchmove וקורא ל-preventDefault באירוע, כדי ליידע את הדפדפן שלא לטפל בו.
דפדפנים: Mobile Safari (בזמן גלילה במסמך), Firefox
Touchmove מבוטל בזמן הגלילה
אירועי Touchmove לא נשלחים לאחר התחלת הגלילה ולא ממשיכים לפעול עד לאחר אירוע קצה המגע. במודל הזה קשה להבחין בהבדל בין מגע נייח לבין גלילה.
דפדפנים: דפדפן Samsung (אירועי Mousemove שנשלחו)
ביטול נגיעה בהתחלת הגלילה
אי אפשר להשתמש בשתי השיטות - מהירות גלילה ושליטה למפתחים - והמודל הזה מבהיר את האיזון בין גלילה חלקה לטיפול באירועים, בדומה לסמנטיקה של המפרט של אירועי מצביע. לא ניתן לבצע פעולות מסוימות שקשורות למעקב אחר האצבע, כמו משיכה לרענון.
דפדפנים: Chrome Desktop M32 ואילך, Chrome Android
למה לשנות?
Chrome ל-Android משתמש כרגע במודל ישן של Chrome: ביטול מגע בהתחלת הגלילה, דבר שמשפר את ביצועי הגלילה, אך גורם למפתחים לבלבול. באופן ספציפי, מפתחים מסוימים לא מודעים לאירוע Touchcancel או איך לטפל בו, מה שגרם לשיבושים בפעילות של אתרים מסוימים. יותר מזה, קשה או בלתי אפשרי להטמיע היטב כל מיני אפקטים והתנהגויות של גלילה בממשק המשתמש, כמו משיכה לרענון, סרגלים נסתרים ונקודות עצירה.
במקום להוסיף תכונות ספציפיות שנכתבו בתוך הקוד כדי לתמוך באפקטים האלה, Chrome שואף להתמקד בהוספת פרימיטיבים לפלטפורמה שמאפשרים למפתחים להטמיע את האפקטים האלה ישירות. במאמר פלטפורמת אינטרנט רציונלית תוכלו לראות הסברים כלליים על הפילוסופיה הזו.
הדגם החדש של Chrome: דגם Touchmove אסינכרוני (throttled Touchmove)
Chrome מציג התנהגות חדשה שנועדה לשפר את התאימות לקוד שנכתב עבור דפדפנים אחרים במהלך גלילה, וכן מפעיל תרחישים אחרים שתלויים בקבלת אירועי touchmove בזמן הגלילה. התכונה הזו מופעלת כברירת מחדל ואפשר להשבית אותה באמצעות הדגל הבא, chrome://flags\#touch-scrolling-mode.
ההתנהגות החדשה היא:
- פעולת ה-Touchmove הראשונה נשלחת באופן סינכרוני כדי לאפשר ביטול של הגלילה
- במהלך הגלילה הפעילה
- אירועי touchmove נשלחים באופן אסינכרוני
- throttled לאירוע אחד לכל 200 אלפיות שנייה, או במקרה של חריגה מאזור סלוליפ של 15px ב-CSS
- הערך של Event.cancelable הוא false
- אחרת, אירועי touchmove מופעלים באופן סינכרוני כרגיל כאשר הגלילה הפעילה מסתיימת או אינה אפשרית מפני שמגבלת הגלילה הגיעה
- אירוע במגע תמיד מתרחש כשהמשתמש מרים את האצבע
תוכלו לנסות את ההדגמה הזו ב-Chrome ל-Android ולהפעיל את הדגל chrome://flags\#touch-scrolling-mode כדי לראות את ההבדל.
דעתכם חשובה לנו
למודל Async Touchmove יש פוטנציאל לשפר את התאימות לדפדפנים שונים, ולהפעיל סוג חדש של אפקטים של תנועות מגע. אנחנו מעוניינים לשמוע מה המפתחים חושבים, ולדעת אילו דברים יצירתיים אפשר לעשות בעזרת הכלי.