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