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

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

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

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

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

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

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

  2. עיבוד Touchmove אסינכרוני

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

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

  3. ביטול המגע מבוטל בזמן הגלילה

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

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

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

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

    דפדפנים: Chrome Desktop M32 ואילך, Chrome Android

למה כדאי לשנות?

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

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

הדגם החדש של Chrome: מודל Touchmove אסינכרוני

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

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

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

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

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

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