محضر اتصال CSSWG (2024-08-21) | حيل CSS

تعد عرض الانتقالات واحدة من أكثر الميزات الرائعة التي قدمتها CSS في الآونة الأخيرة. عنوانها واضح بذاته: التحولات بين طرق العرض ممكنة باستخدام CSS فقط، حتى عبر صفحات من نفس الأصل! ما هو أكثر إثارة للاهتمام هو النص الفرعي، حيث ليست هناك حاجة لإنشاء SPA معقد مع التوجيه فقط للحصول على تلك التحولات الجذابة بين الصفحات.

ما يجعل عرض التحولات مدهشًا أيضًا هو مدى سرعة انتقالها من أول مسودة عامة لها في أكتوبر 2022 إلى الشحن في المتصفحات وحتى في بعض سياقات الإنتاج مثل Airbnb – وهو أمر لا يحدث لكل ميزة تأتي إلى CSS، لذلك إنه يوضح مدى تضخيمه بحق.

ومع ذلك، فإن واجهة برمجة التطبيقات (API) لا تزال جديدة، لذلك لا بد أن يتم حل بعض الحالات أو الأخطاء فور ظهورها. إحدى الطرق المثيرة للاهتمام لمواكبة آخر التطورات حول ميزات CSS مثل عرض الانتقالات هي مباشرة من CSS Telecom Minutes (يمكنك الاشتراك فيها على W3C.org).

كانت التحولات هي محور التركيز الأساسي في اجتماع 21 أغسطس، والذي كان له جدول أعمال طويل يجب معالجته. لقد بدأ الأمر بخلل بسيط في Chrome فيما يتعلق بـ navigation الواصف، المستخدم في كل انتقال لعرض المستندات المشتركة للاشتراك في انتقال العرض.

@view-transition {
  navigation: auto | none;
}

حاليًا، تحدد المواصفات التنقل كنوع التعداد (مجموعة من الأنواع المحددة مسبقًا)، لكن Blink يأخذه على أنه CSSOMString (أي سلسلة). على الرغم من أن هذا تم اعتباره خطأً في البداية، إلا أنه من المثير للاهتمام رؤية المحادثة التي أثارها حول مشكلة GitHub:

في الواقع، أعتقد أن هذا أمر قابل للنقاش، فليس لدينا حاليًا قواعد تستخدم التعدادات بهذه الطريقة، وعادةً لا يحاول CSSOM أن يكون آمنًا تمامًا من النوع بهذه الطريقة. على سبيل المثال، إذا أضفنا أنواع تنقل جديدة وكانت بعض المتصفحات لا تدعمها، فسيؤدي ذلك إلى تفسيرها على أنها قواعد غير صالحة بدلاً من قواعد ذات تنقل فارغ.

قد لا يبدو البيان الأخير مثيرا، لكنه يفتح احتمالا جديدا navigation أنواع أبعد من ذلك auto و noneلذا فكر في ما يمكن أن يفعله نوع مختلف من انتقال العرض.

ومن ثم إلى محضر CSSWG:

اميليو: هل من المفيد التفريق بين فقدان تلقائي أو لا شيء؟

نمر: نعم، مهم جدًا للتوافق الأمامي. إذا أضاف أحد المتصفحات نوعًا آخر لم يضيفه المتصفحون الآخرون بعد، فإننا نريد أن نرى أن هناك فرقًا بين لا شيء أو غير صالح

اميليو: ولكن بعد ذلك تحصل على السلوك التلقائي؟

نمر: لا، لا تتم قراءة القيمة غير المعروفة لغرض التنقل. إنه دور vt بدون واصف التنقل ولا توجد قيمة أولية تشبه وجود قاعدة غير صالحة

لذلك في التطبيقات المستقبلية، غير صالح navigation سيتم تجاهل الواصف، ولكن كيف بالضبط لا يزال قيد المناقشة:

نتيم: كيف يختلف عن الملاحة لا شيء؟

نمر: تلقائي مقابل غير صالح ثم تلقائي مقابل لا شيء. لا شيء سوف يحل محل السيارات. له معنى عدم القيام بالتنقل بينما يعتبر غير صالح أمرًا محظورًا.

نتيم: إذن لا شيء يلغي التنقل من المستند السابق؟

نمر: نعم

ال none لديه النية لإلغاء أي انتقالات عرض من مستند سابق، بينما سيتم تجاهل سلسلة غير صالحة أو فارغة. وفي النهاية، قرر إرجاع سلسلة فارغة إذا كانت مفقودة أو غير صالحة.

تم الحل: التنقل عبارة عن سلسلة CSSOMString، فهو يُرجع سلسلة فارغة عندما يكون واصف التنقل مفقودًا أو غير صالح

إلى البند التالي في جدول الأعمال. وذهبت المناقشة إلى view-transition-group الممتلكات وما إذا كان ينبغي أن يكون لها ترتيب الأسبقية. يجب عدم الخلط بينه وبين العنصر الزائف الذي يحمل نفس الاسم (::view-transition-group) ال view-transition-group تم حل الخاصية لإضافتها في مكان ما في المستقبل. اعتبارًا من الآن، فإن شجرة العناصر الزائفة التي تم إنشاؤها بواسطة انتقالات العرض هي بالارض:

::view-transition
├─ ::view-transition-group(name-1)
│  └─ ::view-transition-image-pair(name-1)
│     ├─ ::view-transition-old(name-1)
│     └─ ::view-transition-new(name-1)
├─ ::view-transition-group(name-2)
│  └─ ::view-transition-image-pair(name-2)
│     ├─ ::view-transition-old(name-2)
│     └─ ::view-transition-new(name-2)
│ /* and so one... */

ومع ذلك، قد نرغب في دمج المجموعات الانتقالية مع بعضها البعض لإجراء انتقالات أكثر تعقيدًا، مما يؤدي إلى ظهور شجرة بها ::view-transition-group داخل الآخرين ::view-transition-group، مثل ما يلي:

::view-transition
├─ ::view-transition-group(container-a)
│  ├─ ::view-transition-group(name-1)
│  └─ ::view-transition-group(name-2)
└─ ::view-transition-group(container-b)
    ├─ ::view-transition-group(name-1)
    └─ ::view-transition-group(name-2)

لذلك view-transition-group وُلدت الملكية، أو على وجه الدقة، ستكون في وقت ما. قد يبدو قريبًا من بناء الجملة التالي إذا كنت أتابعه بشكل صحيح:

view-transition-group: normal | <ident> | nearest | contain;

• normal يتم احتواؤه بواسطة الجذر ::view-transition (السلوك الحالي).
• <ident> سيتم احتواؤه بواسطة عنصر ذي مطابقة view-transition-name
• nearest سيتم احتواؤها من قبل أقرب أسلافها مع view-transition-name.
• contain سيحتوي على جميع أحفاده دون تغيير موضع العنصر في الشجرة

تبدو القيم بسيطة، لكنها قد تتعارض مع بعضها البعض. تخيل البنية المتداخلة التالية:

A  /* view-transition-name: foo */
└─ B /* view-transition-group: contain */
   └─ C /* view-transition-group: foo */

هنا، B يريد أن يحتوي C، لكن C يقول صراحة أنه يريد أن يتم احتواؤه من قبل A. إذن، أيهما يفوز؟

فمبستر: فيما يتعلق بالتداخل مع مجموعة انتقال العرض، فإن الأمر يتطلب كلمات رئيسية أو معرفًا. يحتوي على أن جميع العناصر التابعة لانتقال العرض متداخلة. يقول المعرف نفس الشيء ولكن أيضًا العنصر نفسه سوف يتداخل مع الشيء الذي يحمل هذا المعرف. السؤال هو ماذا يحدث إذا كان العنصر يحتوي على مجموعة انتقال عرض بمعرف مخصص ولديه أيضًا سلف تم تعيينه ليحتوي عليه – أين نقوم بدمج هذا؟ تحتوي على واحد أو واحد مع الهوية؟ أنا ونعوم متفقان على أن الهوية يجب أن تفوز على الأرجح، ويبدو الأمر أكثر تحديدًا.

<خوش>: +1

استمرت المحادثات إذا كان ينبغي أن يكون هناك contain الكلمة الرئيسية التي تفوز <ident>

اميليو: توافق على أن هذا يبدو مرغوبا فيه. هل هناك أي حالة استخدام لفرض الاحتواء فعليًا؟ هل نحتاج إلى احتواء قوي؟ أنا لا أعتقد ذلك؟

استيرنز: في مكان ما على طول خط إضافة كلمة رئيسية جديدة مثل تحتوي على معرفات؟

<فانتاساي>: “يحتوي على الكل”

اميليو: نعم، مثل شيء يحتوي على كل شيء ولكنه يحتاج إلى حالة استخدام

ولكن في الوقت الحالي، تم إعداده <ident> أن يكون أكثر خصوصية من contain

القرار المقترح: المعرفات لها الأسبقية على الاحتواء في مجموعة انتقال العرض

استيرنز: اعتراضات أو مخاوف أو أسئلة؟

<فانتاساي>: تماما كما يفعلون من أجل <ident> قيم. (والتي تطبق أيضًا الاحتواء، ولكن فقط على العناصر “العادية”)

تم الحل: المعرفات لها الأسبقية على الاحتواء في مجموعة انتقال العرض

أخيرًا، المسار الرئيسي للمناقشة: ما إذا كان يجب التقاط بعض الخصائص كأنماط بدلاً من التقاطها كلقطة أم لار. في الوقت الحالي، يمكنك عرض التحولات من خلال التقاط لقطة للعرض “القديم” والانتقال إلى الصفحة “الجديدة”. ومع ذلك، لا يتم دمج كل شيء في اللقطة؛ يتم حفظ بعض الخصائص ذات الصلة حتى يمكن تحريكها بعناية أكبر.

من المواصفات:

ومع ذلك، مثل خصائص mix-blend-mode التي تحدد كيفية رسم العنصر عندما يكون مضمنًا لا يمكن تطبيقها على صورته. يتم تطبيق هذه الخصائص على العنصر الزائف ::view-transition-group() المطابق للعنصر، والذي يهدف إلى إنشاء مربع مكافئ للعنصر.

باختصار، يتم تطبيق بعض الخصائص التي تعتمد على حاوية العنصر على ::view-transition-group بدلا من ::view-transition-image-pair(). وبما أننا، في المستقبل، سنتمكن من دمج مجموعات داخل مجموعات، فإن كيفية التقاط هذه الخصائص لديها الكثير من الفروق الدقيقة.

نمر: أكبر مشكلة نريد مناقشتها اليوم هي كيفية التقاط المكونات المتداخلة وعرضها ولكنها تنطبق أيضًا على عناصر انتقال العرض غير المتداخلة المستمدة من المحادثة المتداخلة. عندما نقوم بتداخل المجموعات، فإن بعض خصائص CSS التي لم يكن من المهم التقاطها في السابق أصبحت الآن مهمة جدًا لأنها بخلاف ذلك ستبدو معطلة. مجموعتان: تأثيرات الشجرة مثل العتامة، والقناع، ومسار المقطع، والمرشحات، والمنظور، تنطبق على الشجرة بأكملها؛ الحدود ونصف قطر الحدود لأنه بمجرد أن يكون لديك تسلسل هرمي للمجموعات، ويكون لديك تجاوز، فإن التجاوز يؤثر على الأصل حيث ترسم الحدود والظلال، كما يتم رسمها بعد الخلفيات

نمر: نرى ثلاثة خيارات.

1. قم بتغيير كل شيء افتراضيًا ولا تلتقط لقطة فحسب، بل أضف المزيد من الأشياء التي يتم التقاطها كـ ؟؟ بدلاً من لقطة مسطحة (التعتيم، الفلتر، التحويل، حدود bg). ستتغير الأشياء لأن هذه الأنماط جزء من المجموعة ولكنها غيرت الأشياء من قبل (لكن هذا يختلف لأنه يغير النمط المحسوب الذي يمكن ملاحظته)
2. إضافة خاصية جديدة view-transition-style أو view-transition-capture-mode. من محبي الأول كما يذكرني transform-style.
3. للحصول على هذه الخاصية الجديدة مع إعطائها قيمة تلقائية. إذا كانت المجموعة تحتوي على مجموعات أخرى عندما تحصل على الوضع الجديد، فإن المستخدمين الذين يستخدمون التداخل سيحصلون على الوضع الجديد ولكن يمكن أن يكون لديهم خاصية لتغيير السلوك. إذا أراد الأشخاص سلوك التلاشي القديم، يمكنهم دائمًا القيام بذلك عن طريق تداخل DOM العادي

فيما يتعلق بالخيار الأول حول تغيير كيفية التقاط جميع انتقالات العرض للخصائص افتراضيًا:

براموس: نعم، هذا من شأنه أن ينكسر، لكنه ينكسر بطريقة جيدة. فيما يتعلق باسم الخاصية، إحدى القيم المقترحة هي crossfade، وهي قيمة لا أوصي بها لأن المؤلفين يمكنهم تغيير الرسوم المتحركة، على سبيل المثال للتكبير/التصغير، وما إلى ذلك. أود أن أقترح قيمة مختلفة اسم للعقار، view-transition-capture-mode: flat | layered

وبطبيعة الحال، فإن تغيير كيفية عمل انتقالات العرض يمثل معضلة حقًا فكر في:

نمر: هناك بعض المشاعر تجاه 1 ولكني أشعر أن الناس بحاجة إلى التفكير في هذا الأمر أكثر؟

استيرنز: يمكن أن نحل المشكلة في الخيار 1 ونحاول تجربته لمعرفة مقدار الكسر الموجود وما إذا كان من الممكن التحكم فيه، فنحن في حالة جيدة ونعود إلى هذا الأمر. سيتم حل واحد 1 ما لم يكن ذلك ممكنًا. أفضل عدم تحديد وضع التقاط جديد بدون مفتاح

…لذا كان أفضل مسار للعمل هو جمع المزيد من البيانات واتخاذ القرار:

خوش: عندما نصنع نموذجًا أوليًا سنجد حالات حافة. وسوف نعيدهم إلى مجموعة العمل في هذه الحالة. تريد الحصول على هذا الحق

نمر: أنها تنطوي على الكثير من الدعائم CSS. بعضها تم التقاطه ولم يتم رسمه والبعض الآخر تم رسمه. سيتم تحديد كل تلك العناصر على وجه التحديد

وبعد مزيد من المناقشة، تقرر العودة ببيانات متوافقة من المتصفحات، ويمكنك قراءة المحضر الكامل على موقع W3C.org. أراهن أن هناك الكثير من الأشياء المثيرة للاهتمام التي فاتني، لذا أشجعك على قراءتها.

تم الحل: قم بتغيير وضع الالتقاط لجميع انتقالات العرض وحدد كيفية تأثر كل خاصية بتغيير وضع الالتقاط هذا

تم الحل: قم بوصف تصنيف الخصائص في أقسام تفاعلات الوحدة لكل مواصفات

تم الحل: سيقوم Blink بالتجربة وسيعود بالتغييرات المطلوبة إذا كانت هناك مخاوف تتعلق بالتوافق