اقتراح بديل لتصميم CSS

Rachel Andrew

يحرص فريق Chrome على تنفيذ تنسيقات من النوع "مطابخ مفتوحة" على الويب. مع ذلك، نرى أنّ تنفيذها كجزء من مواصفات CSS Grid كما هو مقترَح في المشاركة الأخيرة في WebKit سيكون خطأً. نعتقد أيضًا أنّ مشاركة WebKit كانت تعارض إصدارًا من التنسيق لم يقترحه أحد.

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

• يحرص فريق Chrome على إزالة حظر تنسيق "العرض المربّع"، لأنّنا نعلم أنّه أحد التنسيقات التي يريدها المطوّرون.
• تؤدي إضافة تنسيق "العرض على شكل كتل" إلى مواصفات الشبكة إلى حدوث مشاكل لعدة أسباب، بغض النظر عمّا إذا كنت تعتقد أنّ تنسيق "العرض على شكل كتل" هو شبكة أم لا.
• إنّ تحديد تنسيق "العرض على الشاشة" خارج مواصفات الشبكة لا يمنع استخدام أحجام مسارات متعددة لتنسيق "العرض على الشاشة" أو استخدام سمات مثل المحاذاة أو الفجوات أو أي ميزات أخرى مستخدَمة في تنسيق الشبكة.

هل يجب أن تكون العناصر المركّبة جزءًا من الشبكة؟

يرى فريق Chrome أنّ تنسيق "المرصوص" يجب أن يكون طريقة تنسيق منفصلة، يتم تحديدها باستخدام display: masonry (أو كلمة رئيسية أخرى في حال تم تحديد اسم أفضل ). يمكنك الاطّلاع في وقت لاحق من هذا المنشور على بعض الأمثلة على شكل ذلك في الرمز البرمجي.

هناك سببان مرتبطان يدفعاننا إلى الاعتقاد بأنّه من الأفضل استخدام تنسيق "المرفقات" خارج تنسيق "الشبكة": احتمالية حدوث مشاكل في أداء التنسيق، وكون تنسيقَي "المرفقات" و"الشبكة" يتضمّنان ميزات منطقية في طريقة تنسيق واحدة ولكن ليس في الأخرى.

الأداء

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

لذلك، إذا كان لديك تنسيق عرض مُجمّع مع تعريف مسار هو grid-template-columns: 200px auto 200px، وهو أمر شائع جدًا في الشبكة، ستبدأ في مواجهة مشاكل. تتفاقم هذه المشاكل بشكل كبير بعد إضافة شبكات فرعية.

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

ما الذي نفعله بشأن العناصر التي لا تبدو منطقية في كل طريقة تنسيق؟

عندما أصبح flexbox وgrid جزءًا من CSS، لاحظ المطوّرون غالبًا أنّهما يعملان بطريقة غير متّسقة. كان عدم الاتساق الذي كانوا يواجهونه هو بسبب الافتراضات القديمة حول آلية عمل التنسيق، استنادًا إلى تنسيق الكتل. مع مرور الوقت، بدأ المطوّرون في فهم سياقات التنسيق. عند التبديل إلى سياق تنسيق شبكة أو تنسيق مرن، تتغيّر سلوك بعض العناصر. على سبيل المثال، عندما تكون في المربّع المرن، لا تتوفّر كل methods methods من طرق المحاذاة، لأنّ المربّع المرن أحادي البعد.

يؤدي تجميع تنسيق "العرض المربّع" في شبكة إلى كسر هذا الرابط الواضح بين سياق التنسيق و توفّر عناصر مثل سمات المحاذاة، والتي يتم تحديدها في مواصفات محاذاة المربّع لكل سياق تنسيق.

إذا قرّرنا التعامل مع مشكلة الأداء الموضّحة سابقًا من خلال جعل تعريفات المسارات الثابتة والجوهرية المختلطة غير قانونية في تنسيق "العرض على الشاشة"، عليك تذكُّر أنّ أحد الأنماط الشائعة جدًا لتنسيقات الشبكة لا يعمل مع تنسيق "العرض على الشاشة".

هناك أيضًا أنماط مناسبة للاستخدام في تنسيق "العرض المربّع"، مثل grid-template-columns: repeat(auto-fill, max-content)، لأنّه ليس لديك قيود متقاطعة، ولكن يجب أن تظل غير صالحة في الشبكة. في ما يلي قائمة بالخصائص التي نتوقّع أن تتصرّف بشكل مختلف أو أن تتضمّن قيمًا صالحة مختلفة.

• grid-template-areas: في البناء المركّب، يمكنك تحديد الصف الأول فقط في اتجاه غير البناء المركّب.
• grid-template: يجب أن يراعي الاختصار جميع الاختلافات.
• تتبُّع قيم المقاييس لكلّ من grid-template-columns و grid-template-rows بسبب الاختلافات في القيم القانونية
• لا ينطبق grid-auto-flow على تنسيق "الحوائط" ولا ينطبق masonry-auto-flow على تنسيق "الشبكة". سيؤدي دمجهما إلى حدوث مشاكل في العناصر غير الصالحة بسبب طريقة التنسيق التي تستخدمها.
• تحتوي الشبكة على أربعة عناصر مواضع إعلان (grid-column-start وما إلى ذلك)، بينما تحتوي طريقة العرض على شبكة منتظمة على عنصرَين فقط.
• يمكن أن يستخدم التنسيق الشبكي جميع السمات الستة لسمات justify-* وalign-* ، ولكن لا يستخدم التنسيق "مظهر مُرصّد" سوى مجموعة فرعية مثل flexbox.

سيكون هناك أيضًا شرط لتحديد ما يحدث في جميع حالات الخطأ الجديدة التي يتسبب فيها المطوّرون باستخدام قيمة غير صالحة في grid-with-masonry أو grid-without-masonry. على سبيل المثال، يُسمح باستخدام grid-template-columns: masonry أو grid-template-rows: masonry ولكن ليس كليهما في الوقت نفسه. ماذا يحدث في حال استخدام كليهما في الوقت نفسه؟ يجب تحديد هذه التفاصيل لكي تؤدي جميع المتصفّحات إلى الإجراء نفسه.

يصبح هذا الأمر معقّدًا من وجهة نظر المواصفات، الآن وفي المستقبل. سنحتاج إلى التأكّد من أنّ كل العناصر تراعي تنسيق "العرض على الشاشة"، وما إذا كان يعمل مع هذا التنسيق أو لا. ويؤدي ذلك أيضًا إلى حدوث التباس من وجهة نظر المطوّرين. لماذا عليك أن تضع في اعتبارك أنّه على الرغم من استخدام display: grid، لا تعمل بعض الأشياء بسبب استخدام الطوب؟

اقتراح بديل

كما ذكرنا سابقًا، يريد فريق Chrome تحديد تنسيق "المرصوص" خارج مواصفات الشبكة. ولا يعني ذلك أنّه سيقتصر على أسلوب تنسيق بسيط جدًا بأحجام أعمدة متطابقة. ستظل جميع العروض التوضيحية في WebKit post متاحة.

تنسيق البناء الكلاسيكي

عندما يفكر معظم الأشخاص في تصميمات "الجدران"، يتبادر إلى أذهانهم تنسيق يتضمّن أعمدة متعددة متساوية الحجم. سيتم تحديد ذلك باستخدام ملف CSS التالي الذي يحتاج إلى رمز يحتوي على خطوط أقل من الإصدار المُضمّن للشبكة المكافئ.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
}

استخدام أحجام مسارات أنواع الشبكة لمختلف عروض الأعمدة

بخلاف المشكلة المذكورة سابقًا المتعلّقة بحجم المسار المتغير والثابت المختلط، يمكنك استخدام جميع أحجام المسار التي تفضّلها من الشبكة. مثل المثال من مشاركة مدونة WebKit، وهو نمط من الأعمدة الضيقة والعريضة المتكررة.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(8rem, 1fr) minmax(16rem, 2fr)) minmax(8rem, 1fr);
  gap: 1rem;
}

أحجام إضافية للمقاطع الصوتية في العرض على شكل شبكة

هناك خيارات إضافية لحجم المقاطع الصوتية لا نسمح بها في الشبكة لأنّه تُعدّ الشبكة طريقة تخطيط ثنائية الأبعاد. ستكون هذه مفيدة في الجدران، ولكن سيكون من المربك عدم عملها في الشبكة.

ملء مسارات بحجم max-content تلقائيًا

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, max-content);
  gap: 1rem;
}

ملء مسارات بحجم auto تلقائيًا، ما سيؤدي إلى إنشاء مسارات بالحجم نفسه، وسيتم ضبط حجمها تلقائيًا لاستيعاب أكبر مسار

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, auto);
  gap: 1rem;
}

السماح للمحتوى بتضمين الأعمدة ووضع العناصر في تنسيق "المرصوص"

لا يوجد سبب يمنع عرض المحتوى على أعمدة في مواصفات تنسيق شاشة شاشة شاشة منفصلة. قد يستخدم هذا الإجراء سمة masonry-track، وهي اختصار لسمتي masonry-track-start وmasonry-track-end لأنّه لا تتوفّر لك سوى سمة واحدة لتوسيع نطاق العناصر عند استخدام تنسيق "عرض مسطّح".

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, auto);
}

.span-2 {
  masonry-track: span 2; /* spans two columns */
}

.placed {
  masonry-track: 2 / 5; /* covers tracks 2, 3, and 4 */
}

الشبكة الفرعية أو الشبكة الفرعية التي تتّبع مسارات الشبكة

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

الخاتمة

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

إذا كانت لديك أي ملاحظات، يمكنك الانضمام إلى المناقشة في الطلب 9041.

نشكر Bramus وTab Atkins-Bittner وUna Kravets وIan Kilpatrick وChris Harrelson على مراجعة هذه المشاركة والمناقشات التي أدّت إلى إنشائها.