إن فريق Chrome حريص على رؤية تنفيذ تخطيطات أنواع البناء على الويب. ومع ذلك، نرى أن تنفيذها كجزء من مواصفات شبكة CSS كما هو مقترح في مشاركة WebKit الحديثة سيكون خطأ. نشعر أيضًا أن منشور WebKit يعترض على نسخة من البناء لم يكن أحد يقترحها.
لذلك، تهدف هذه المشاركة إلى توضيح سبب قلقنا في Chrome بشأن تنفيذ البناء كجزء من مواصفات تخطيط شبكة CSS، وتوضيح ما يمكّنه الاقتراح البديل بالضبط. باختصار:
- يحرص فريق Chrome على إزالة التشويش عن البناء، ونحن نعلم أن هذا الأمر يريده المطورون.
- تُعد إضافة البناء إلى مواصفات الشبكة مشكلة لأسباب أخرى بخلاف ما إذا كنت تعتقد أن البناء عبارة عن شبكة أم لا.
- لا يمنع تحديد البناء خارج مواصفات الشبكة أحجام مسارات متعددة للبناء، أو استخدام خصائص مثل المحاذاة أو الفجوات، أو أي ميزات أخرى مستخدمة في تخطيط الشبكة.
هل يجب أن يكون البناء جزءًا من الشبكة؟
ويعتقد فريق Chrome أن أعمال البناء يجب أن تكون طريقة تصميم منفصلة،
يتم تحديدها باستخدام display: masonry (أو يجب تحديد اسم أفضل لكلمة رئيسية أخرى). لاحقًا في هذه المشاركة، يمكنك رؤية بعض الأمثلة حول ما يمكن أن يبدو
عليه ذلك في التعليمات البرمجية.
هناك سببان مترابطان يجعلنا نشعر بأن البناء يتم تحديده بشكل أفضل خارج تخطيط الشبكة - احتمالية حدوث مشكلات في أداء التخطيط، وحقيقة أن كل من البناء والشبكة لها ميزات منطقية في طريقة تخطيط واحدة دون الأخرى.
عروض أداء
الشبكة والبناء تتعارضان من حيث كيفية تعامل المتصفح مع الحجم والموضع. عند وضع شبكة، يتم وضع جميع العناصر قبل التخطيط ويعرف المتصفح بالضبط ما هو موجود في كل مسار. وهذا يتيح الحجم الجوهري المعقد الذي يكون مفيدًا جدًا في الشبكة. في عملية البناء، يتم وضع العناصر كما هي مرصوفة، ولا يعرف المتصفح عدد العناصر في كل مسار. هذه ليست مشكلة في جميع المسارات ذات الحجم الأساسي أو كل المسارات ذات الحجم الثابت، ولكن إذا كنت تمزج بين المسارات الثابتة والأساسية. لحل المشكلة، يحتاج المتصفح إلى إجراء خطوة تخطيط مسبق لتخطيط كل عنصر بكل طريقة ممكنة للحصول على القياسات، مع وجود شبكة كبيرة من شأنها أن يساهم ذلك في مشكلات أداء التخطيط.
لذلك، إذا كان لديك تصميم بنية أساسية مع تعريف مسار grid-template-columns: 200px auto 200px، وهو أمر شائع جدًا يجب تنفيذه في الشبكة، ستواجه مشاكل. تصبح هذه المشاكل أُسِّيَّة عند إضافة شبكات فرعية.
هناك جدال مفاده أنّ معظم الأشخاص لن يواجهوا هذا النوع من المشاكل، ولكنّنا نعرف أنّ الأشخاص لديهم شبكات كبيرة جدًا. لا نريد شحن شيء له حدود حول كيفية استخدامه، عندما يكون هناك نهج بديل.
ماذا نفعل بشأن الأشياء التي لا معنى لها في كل طريقة تخطيط؟
عندما أصبح flexbox والشبكة جزءًا من CSS، شعر المطورون في كثير من الأحيان أنهم يتصرفون بطريقة غير متسقة. كان التناقض الذي كانوا يواجهونه بسبب الافتراضات الطويلة الأمد حول كيفية عمل التخطيط، بناءً على تخطيط الكتلة. بمرور الوقت، بدأ المطورون في فهم تنسيق السياقات. عندما ننتقل إلى سياق شبكة أو تنسيق مرن، تتصرف بعض الأشياء بشكل مختلف. على سبيل المثال، عند استخدام flexbox، لا تكون جميع طرق المحاذاة متوفرة لأنّ flexbox هو بُعد واحد.
يؤدي تجميع أعمال البناء في شبكة إلى تقسيم هذا الرابط الواضح بين التنسيق ومدى توفر أشياء مثل خصائص المحاذاة، التي يتم تحديدها في مواصفات محاذاة المربع لكل سياق تنسيق.
إذا قررنا التعامل مع مشكلة الأداء الموضحة سابقًا من خلال جعل تعريفات المسارات الأساسية والثابتة غير قانونية في مجال البناء، فسيتعين عليك أن تتذكر أن النمط الشائع جدًا لتخطيطات الشبكة لا يصلح للبناء.
هناك أيضًا أنماط قد تكون منطقية في أعمال البناء، على سبيل المثال 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وما إلى ذلك)، وتحتوي أعمال البناء على خاصيتين فقط. - يمكن أن تستخدم Grid خصائص
justify-*وalign-*الست، لكن Masonry تستخدم مجموعة فرعية فقط مثل flexbox.
سيكون هناك أيضًا مطلب لتحديد ما يحدث في جميع حالات الخطأ الجديدة
التي يتسبب فيها المطورون باستخدام قيمة غير صالحة في شبكة مع البناء أو شبكة بدون أعمال بناء. على سبيل المثال، يمكن استخدام
grid-template-columns: masonry أو grid-template-rows: masonry
ولكن ليس كليهما في آن واحد. ماذا يحدث في حال استخدامهما في آنٍ واحد؟
يجب تحديد هذه التفاصيل حتى تتمكن جميع المتصفحات
من القيام بنفس الشيء.
يصبح هذا الأمر معقدًا من وجهة نظر المواصفات، الآن وفي المستقبل. سنحتاج إلى التأكد من أن كل شيء يأخذ في الاعتبار
الأعمال البناء، وما إذا كان يفعل أعمال البناء أم لا. إنه أمر محير أيضًا من
وجهة نظر المطورين. لماذا يجب أن تضعوا في ذهنك فكرة أنّه على الرغم من
استخدام display: grid، فإنّ بعض الأمور لا تكون نتيجة استخدام أعمال البناء؟
اقتراح بديل
كما ذكرنا سابقًا، يرغب فريق Chrome في تعريف البناء خارج مواصفات الشبكة. هذا لا يعني أنه سيقتصر على طريقة تخطيط بسيطة للغاية بأحجام أعمدة متطابقة. ولا تزال جميع العروض التوضيحية في منشور WebKit ممكنة.
تصميم كلاسيكي للبناء
عندما يفكر معظم الناس في البناء، فإنهم يفكرون في تخطيط بأعمدة متعددة ومتساوية الحجم. يمكن تحديد ذلك باستخدام لغة CSS التالية، والتي تحتاج إلى رمز بدون سطر من رمز الإصدار gridاق المكافئ.
.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.
شكرًا لـ "براموس" و"تاب أتكينز بيتنر" و"أونا كرافيتس" و"إيان كيلباتريك" و"كريس هاريلسون" بعد مراجعة هذه المشاركة والمناقشات التي ساهمت فيها.