تتيح لك واجهة برمجة تطبيقات View Transition API تحديث نموذج العناصر في المستند (DOM) في خطوة واحدة، مع إنشاء انتقال متحرك بين الحالتين.
كانت أنواع عمليات الانتقال هذه مطلوبة بشكل متكرر من المطوّرين بمن فيهم أنا، وأعتقد أننا تمكّنا من تطويرها بطريقة توازن بين الإعدادات التلقائية الجيدة وقابلية التوسّع والتخصيص. يبدو أنّنا نستمتع كثيرًا، ولكن كانت ملاحظات المطوّرين عاملاً أساسيًا لتصميم هذه الميزة. كان النموذج الأولي السابق لهذه الميزة أقل مرونة، فالأشخاص (مثلك) الذين خصّصوا الوقت الكافي للعب بالنماذج الأولية وتقديم الملاحظات أعادوا التفكير بشكل كامل. شكرًا
للتعرّف على هذه الميزة وتجربة بعض العروض التوضيحية، راجِع دليلنا. إذا كنت تشعر أنّ هناك مشكلة غير مذكورة في هذا المجال، يُرجى التواصل معنا على Twitter أو Mastodon أو عبر البريد الإلكتروني.
لا تتوفر واجهة برمجة تطبيقات View Transition API حاليًا إلا في متصفّح Chrome، ولحسن الحظ يمكن استخدامها كتحسين تدريجي. يتضمّن هذا الدليل وظيفة مساعِدة يمكنك استخدامها في مختلف المتصفّحات، ولكن لن يتم تشغيل الصور المتحركة إلا في المتصفّحات التي تتيح الانتقالات بين طرق العرض.
لقد طوّرنا هذه الميزة ضمن "مجموعة عمل CSS" بالاستعانة ببيانات مورّدين آخرين حول المتصفّح ومن جهات مستقلة. لا نعرف ما إذا كانت المتصفحات الأخرى ستستخدم "انتقالات العرض" أم لا، ولكن عليك مراقبة وضع معايير Mozilla وموضع معايير WebKit.
لكننا لم ننتهي بعد!
إنّ توفير الوظائف في Chrome 111 هو الإصدار الأول فقط. نأمل أن نكون قد كنّا قد عثرنا على كل الأخطاء، ولكن يُرجى الإبلاغ عن أي مشاكل تجدها على crbug.com، ويُفضَّل أن تكون من خلال إصدار تجريبي مخفَّض. إذا لم يكُن الأمر مألوفًا لديك أو مريحًا لك، يمكنك التواصل معي على Twitter أو Mastodon أو عبر البريد الإلكتروني، وسنساعدك.
هذا الإصدار هو جزء صغير ولكنه مفيد من صورة أكبر. لقد رسمنا بعض الإضافات لهذه الميزة لضمان توافق الأجزاء التي نشحنها اليوم في المستقبل.
فيما يلي نظرة سريعة على ما نفكر به. هذه ليست حسب الأولوية (قد تكون الأولى الأكثر أهمية بالنسبة إلى الكثير من المستخدمين)، لذا نود تلقّي تعليقات حول الإضافات الأكثر أهمية بالنسبة إليك.
عمليات النقل بين المستندات
هذا هو أعتقد أن معظم المطورين يريدون منا العمل عليه بعد ذلك، والخبر السار أننا نعمل على ذلك بالفعل.
تم تصميم واجهة برمجة التطبيقات View Transitions API كي تعمل في المستندات ذات المصدر نفسه. والفرق الوحيد هو أنّه بدلاً من استخدام startViewTransition للإشارة إلى تغيير حالة DOM، سيشير التنقّل نفسه إلى ذلك التغيير.
نموذجنا الأولي من وراء العلامة chrome://flags/#view-transition-on-navigation. إليك عرضًا توضيحيًا بسيطًا للغاية وعرضًا توضيحيًا أكثر تعقيدًا.
وللمضي قدمًا في ذلك، نحتاج إلى معرفة كيفية اشتراك كل صفحة في عملية النقل. نستخدم في الوقت الحالي العلامة الوصفية <meta name="view-transition" content="same-origin">، ولكننا نعتقد أنّ لغة CSS هي المكان الأفضل لإجراء ذلك. ونسعى أيضًا إلى تسهيل معرفة نوع الصفحة التي تنتقل منها، ويفضل أن يكون ذلك بدون الحاجة إلى كتابة JavaScript.
هناك الكثير من العمل الذي يجب القيام به، ونحن نفضل أن نحققها "بشكل صحيح" بدلاً من "سريع"، ولكنها بالتأكيد أولوية بالنسبة لنا.
الرسوم المتحركة التي تعتمد على التركيب
لقد اخترنا إضافة تأثيرات حركية إلى العرض والارتفاع في مجموعات الانتقال بشكل تلقائي، لأنّه أصبح من السهل جدًا التخصيص. مع ذلك، يعني ذلك أنّ الصورة المتحركة يتم تنفيذها في سلسلة التعليمات الرئيسية، وهي ليست الأفضل، خاصةً أثناء عمليات تحميل الصفحات.
نخطط لرصد الرسوم المتحركة التلقائية والتخصيصات الشائعة، ثم إعادة تفسيرها كرسوم متحركة تستند إلى التركيب لتحسين الأداء بشكلٍ رائع.
عمليات النقل المُفصَّلة
في الوقت الحالي، يتم تحديد نطاق عمليات نقل SPA على المستند بأكمله، ويمكن تنفيذ عملية نقل واحدة فقط في كل مرة. نريد تقديم ميزة تسمح بتحديد نطاق الانتقالات إلى عنصر معين بحيث يمكن لمكونات صفحات متعددة تشغيل الانتقالات بشكل مستقل.
على سبيل المثال، يسمح هذا لمشغّل الفيديو المضمّن باستخدام الانتقالات بين طرق العرض والظهور في الوقت نفسه كأداة محادثة مضمّنة.
مجموعات النقل المدمَجة
في الوقت الحالي، كل ::view-transition-group أشقاء. وهذا أمر جيد في أغلب الأحيان، لأنه يتيح انتقال العروض من حاوية إلى أخرى، ولا داعي للقلق بشأن الاقتصاص.
مع ذلك، قد تحتاج أحيانًا إلى اقتطاع عرض معيّن من قِبل بعض الوالدَين، ما قد يؤثر أيضًا في عملية النقل.
نريد التحقيق في تفعيل يضع ::view-transition-group معيّنًا ضمن ::view-transition-group أخرى.
فئات الانتقالات
يجب أن يكون كل view-transition-name فريدًا. وهذه هي الطريقة التي نحدد بها أنّ عنصرًا معيّنًا هو "مشابه" من الناحية النظرية على أيّ من جانبَي تغيير DOM، حتى لو لم يكن العنصر نفسه حرفيًا.
مع ذلك، يجب أحيانًا استخدام نوع الحركة نفسه على العناصر التي تتضمّن view-transition-name مختلفة. يعني ذلك في الوقت الحالي إضافة قاعدة أداة اختيار كل view-transition-name.
ونود إضافة طريقة لإنشاء فئات الانتقالات للتغلب على هذا القيد.
تجاهل العناصر خارج الشاشة
إذا منحت أحد العناصر السمة view-transition-name، سيتم تضمينه في عملية النقل بصفته مجموعته الخاصة. في بعض الأحيان لا يكون هذا الإجراء مثاليًا. على سبيل المثال، إذا منحت العنوان view-transition-name، وانتقلت من حالة يتم تمريرها للأسفل بمقدار 2,000 بكسل، إلى أعلى الصفحة، سيتحرك العنوان من مسافة 2,000 بكسل، الأمر الذي يبدو خاطئًا من حيث التوقيت.
بدلاً من ذلك، نريد إضافة خيار يتيح تجاهل عنصر، كما لو أنّه لا يتضمّن view-transition-name، وذلك إذا كان خارج إطار العرض تمامًا.
ويمكن إجراء ذلك باستخدام JavaScript من خلال الإعداد الديناميكي لـ style.viewTransitionName، ولكن يبدو أنه يجب أن يكون لدينا حل تعريفي لذلك.
الصور المتحركة المستندة إلى requestAnimationFrame
يمكنك حاليًا إنشاء صور متحركة لنقل العرض باستخدام JavaScript من خلال واجهة برمجة تطبيقات الصور المتحركة على الويب، ولكن تحتاج أحيانًا إلى قيادة العناصر كل إطار على حدة باستخدام requestAnimationFrame.
يمكنك إجراء ذلك بالفعل، ولكنه ينطوي على بعض التشويش. إليك عرض توضيحي يتضمن بعض أدوات المساعدة التي قد تكون مفيدة لك. نحن نريد أن نجعله غير ابتكاري!
سنفعل ذلك في جزأين. الأولى، من خلال توفير واجهة برمجة تطبيقات للإشارة إلى وقت انتهاء الصورة المتحركة والثاني، من خلال توفير إمكانية الوصول إلى العناصر الزائفة باستخدام JavaScript. قد يكون هذا الجزء الثاني عملاً كبيرًا للغاية، لكنه يبدو أنه التصرف الصحيح الذي ينبغي القيام به على المدى الطويل.
لننتقل الآن لإجراء بعض الانتقالات الرائعة في طريقة العرض!
آمل، مثلي، أن تكون متحمسًا لمستقبل هذه الميزة وحاضرها. إذا كانت لديك أي ملاحظات، أو أردت فقط عرض بعض التغييرات التي أجريتها على طرق العرض، سواء كانت سلسة وفعّالة أو بسيطة ساخرة، يُرجى التواصل معي على Twitter أو Mastodon.