מגע חלק יותר ותואם יותר

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

ארבעה מודלים שונים לעיבוד אירועי מגע?

ההבדלים בהתנהגות בין הדפדפנים מתחלקים לארבעה מודלים.

  1. עיבוד אירועים סינכרוני רגיל

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

    דפדפנים: דפדפן Android‏ (Android 4.0.4, ‏ 4.3), ‏ Mobile Safari‏ (כשגוללים ב-div)

  2. עיבוד אסינכרוני של אירועי touchmove

    אירועי touchmove נשלחים במהלך הגלילה, אבל הגלילה יכולה להתבצע באופן אסינכרוני (אירוע ה-touchmove מתעלם אחרי שהגלילה מתחילה). כתוצאה מכך, יכולה להתרחש 'טיפול כפול' באירועים. לדוגמה, המשך גלילה אחרי שהאתר מבצע פעולה כלשהי עם האירוע touchmove וקורא ל-preventDefault באירוע, כדי להורות לדפדפן לא לטפל בו.

    דפדפנים: Safari לנייד (כשגוללים במסמך), ‏ Firefox

  3. השבתה של תנועת המגע בזמן גלילה

    אירועי touchmove לא נשלחים אחרי שהגלילה מתחילה, והם לא ממשיכים עד אחרי אירוע touchend. במודל הזה קשה להבחין בין מגע נייח לבין גלילה.

    דפדפנים: דפדפן Samsung (אירועי mousemove נשלחים)

  4. ביטול מגע בתחילת הגלילה

    אי אפשר ליהנות משני העולמות – גלילה חלקה ושליטה של המפתחים – והמודל הזה מבהיר את הפשרה בין גלילה חלקה לבין טיפול באירועים, בדומה לסמנטיקה של מפרט Pointer Events. אי אפשר להשתמש בחלק מהתכונות שעשויות לדרוש מעקב אחר האצבע, כמו 'משיכה לרענון'.

    דפדפנים: Chrome למחשב בגרסה M32 ואילך, Chrome ל-Android

למה צריך לשנות?

כרגע, ב-Chrome ל-Android נעשה שימוש במודל הקודם של Chrome: touchcancel בתחילת הגלילה, שמשפר את ביצועי הגלילה אבל מוביל לבלבול בקרב המפתחים. באופן ספציפי, חלק מהמפתחים לא מודעים לאירוע touchcancel או לא יודעים איך לטפל בו, וכתוצאה מכך חלק מהאתרים לא פועלים כראוי. חשוב יותר, קשה או בלתי אפשרי להטמיע בצורה טובה סוג שלם של אפקטים והתנהגויות של גלילה בממשק המשתמש, כמו משיכה לרענון, עמודות מוסתרות ונקודות הצמדה.

במקום להוסיף תכונות ספציפיות שהוגדרו בקוד לצורך תמיכה באפקטים האלה, אנחנו ב-Chrome מתמקדים בהוספת רכיבים בסיסיים לפלטפורמה שמאפשרים למפתחים להטמיע את האפקטים האלה ישירות. A Rational Web Platform הוא מאמר שמספק הסבר כללי על הפילוסופיה הזו.

המודל החדש של Chrome: מודל Touchmove אסינכרוני עם הגבלת קצב

ב-Chrome אנחנו משיקים התנהגות חדשה שנועדה לשפר את התאימות לקוד שנכתב לדפדפנים אחרים בזמן גלילה, וגם לאפשר תרחישים אחרים שמסתמכים על קבלת אירועי touchmove בזמן גלילה. התכונה הזו מופעלת כברירת מחדל, ואפשר להשבית אותה באמצעות הדגל הבא, chrome://flags\#touch-scrolling-mode.

ההתנהגות החדשה היא:

  • אירוע ה-touchmove הראשון נשלח סינכרונית כדי לאפשר ביטול של הגלילה.
  • במהלך גלילה פעילה
    • אירועי touchmove נשלחים באופן אסינכרוני
    • מוגבלת לאירוע אחד לכל 200 אלפיות השנייה, או אם מחריגים מתחום ה-CSS של 15px
    • הערך של Event.cancelable הוא false
  • אחרת, אירועי touchmove מופעלים באופן סינכרוני כרגיל כשהגלילה הפעילה מסתיימת או לא אפשרית כי הגעתם למגבלת הגלילה.
  • אירוע touchend מתרחש תמיד כשהמשתמש מסיר את האצבע

אתם יכולים לנסות את ההדגמה הזו ב-Chrome ל-Android ולהפעיל או להשבית את הדגל chrome://flags\#touch-scrolling-mode כדי לראות את ההבדל.

דעתכם חשובה לנו

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