تريد أنت والمستخدمون استخدام تطبيقات ويب الجوّال التي تتفاعل وتنتقل بسلاسة إلى اللمس. ومن المفترض أن يكون تطويرها أمرًا سهلاً، ولكن للأسف، تُترك طريقة تفاعل متصفِّحات الويب على الأجهزة الجوّالة مع أحداث اللمس أثناء التمرير كتفاصيل تنفيذ في مواصفات TouchEvent. نتيجة لذلك، يمكن تقسيم النُهُج تقريبًا إلى 4 فئات. ويكشف هذا الموقف عن توتر أساسي بين توفير سلاسة التنقل والحفاظ على تحكم مطوري البرامج.
هل هناك أربعة نماذج مختلفة لمعالجة أحداث اللمس؟
وتنقسم الاختلافات السلوكية بين المتصفحات إلى أربعة نماذج.
المعالجة العادية للأحداث المتزامنة
يتم إرسال أحداث Touchmove أثناء التمرير، ويتم حظر كل تحديث من خلال الانتقال إلى أن تكتمل معالجة الانتقال باللمس. وهذا يُعدّ الأبسط من ناحية الفهم والأقوى ولكن الأقوى مع أداء التمرير في الأداء لأنّه يعني أنّ كل إطار أثناء التمرير يجب أن يتم حظره في سلسلة التعليمات الرئيسية.
المتصفّحات: متصفح Android (الإصداران 4.0.4 و4.3 من نظام التشغيل Android)، وMobile Safari (عند التمرير في علامة div)
المعالجة غير المتزامنة للحركة باللمس
يتم إرسال أحداث الانتقال باللمس أثناء التنقّل، ولكن يمكن مواصلة التمرير بشكل غير متزامن (يتم تجاهل حدث "حركة اللمس" بعد بدء التمرير). قد يؤدي ذلك إلى "التعامل المزدوج" مع الأحداث، على سبيل المثال، مواصلة التنقّل بعد أن ينفّذ الموقع الإلكتروني إجراءً من خلال خطوة اللمس واستدعاء preventDefault لهذا الحدث في المتصفّح، مطلبًا من المتصفّح عدم التعامل مع هذه العملية.
المتصفِّحات: Mobile Safari (عند التمرير في المستند) وFirefox
إيقاف ميزة Touchmove أثناء التمرير
لا يتم إرسال أحداث الانتقال باللمس بعد بدء التمرير ولا يتم استئنافها إلا بعد حدث اللمس. من الصعب في هذا النموذج التفريق بين اللمس الثابت والتمرير.
المتصفِّحات: متصفِّح Samsung (تم إرسال أحداث mousemove)
Touchcancel عند بدء الانتقال
ولا يمكنك الحصول على كلا الطريقتين، وهما سلاسة التمرير وتحكُّم مطوّري البرامج، ويوضّح هذا النموذج المفاضلة بين التمرير السلس ومعالجة الأحداث، كما هو الحال مع دلالات مواصفات أحداث المؤشر. ولا يمكن استخدام بعض التجارب التي قد تحتاج إلى تتبُّع الإصبع، مثل السحب لإعادة التحميل.
المتصفِّحات: Chrome Desktop M32 وChromeOS
لماذا التغيير؟
يستخدم Chrome لنظام Android حاليًا النموذج القديم من Chrome وهو: تقنية touchcancel عند بدء التمرير، ما يحسّن أداء التنقل ولكن يربك المطوّرين. على وجه الخصوص، لا يعرف بعض المطوّرين حدث touchcancel أو كيفية التعامل معه، وقد تسبّب هذا في تعطُّل بعض المواقع الإلكترونية. والأهم من ذلك، أنّه من الصعب أو المستحيل تنفيذ فئة كاملة من تأثيرات التمرير في واجهة المستخدم وسلوكياته، مثل سحب للتحديث والأشرطة المخفية ونقاط الالتقاط.
وبدلاً من إضافة ميزات ذات ترميز ثابت محدد لدعم هذه التأثيرات، يهدف Chrome إلى التركيز على إضافة أساسيات النظام الأساسي التي تسمح للمطوّرين بتنفيذ هذه التأثيرات مباشرةً. يمكنك الاطّلاع على A Rational Web Platform للاطّلاع على شرح عام لهذه الفلسفة.
نموذج Chrome الجديد: نموذج Throttled Async Touchmove
يقدّم Chrome سلوكًا جديدًا
مصممًا لتحسين التوافق مع الرموز المكتوبة للمتصفّحات الأخرى عند
التمرير، بالإضافة إلى تفعيل السيناريوهات الأخرى التي تعتمد على الحصول على أحداث touchmove أثناء التمرير. هذه الميزة مفعّلة بشكل تلقائي، ويمكنك إيقافها باستخدام العلامة التالية: chrome://flags\#touch-scrolling-mode.
السلوك الجديد هو:
- يتم إرسال حركة اللمس الأولى بشكلٍ متزامن للسماح بإلغاؤه.
- أثناء التمرير النشط
- إرسال أحداث touchmove بشكل غير متزامن
- throttled إلى حدث واحد لكل 200 ملي ثانية، أو في حال تجاوز منطقة انسيابية بتنسيق CSS 15px
- قيمة Event.cancelable هي false
- بخلاف ذلك، يتم تنشيط أحداث الانتقال باللمس بشكل متزامن كما هو الحال عند إنهاء التمرير النشط أو غير ممكن بسبب الوصول إلى حدّ التمرير.
- يحدث حدث اللمس دائمًا عندما يرفع المستخدم إصبعه.
يمكنك تجربة هذا العرض التوضيحي في Chrome لنظام Android وتبديل علامة chrome://flags\#touch-scrolling-mode لمعرفة الفرق.
يسرنا أن نعرف رأيك
ويمكن تحسين التوافق بين المتصفحات واستخدام فئة جديدة من تأثيرات إيماءات اللمس في نموذج Async Touchmove. يهمّنا معرفة آراء المطوّرين، ومعرفة الأمور الإبداعية التي يمكنك الاستفادة منها.