یک پیشنهاد جایگزین برای سنگ تراشی CSS

تیم Chrome مشتاق اجرای طرح‌بندی‌های نوع سنگ‌تراشی در وب است. با این حال، ما احساس می کنیم که اجرای آن به عنوان بخشی از مشخصات CSS Grid همانطور که در پست اخیر WebKit پیشنهاد شده است، اشتباه خواهد بود. ما همچنین احساس می کنیم که پست WebKit علیه نسخه ای از سنگ تراشی که هیچ کس آن را پیشنهاد نکرده بود، استدلال می کرد.

بنابراین، این پست قصد دارد توضیح دهد که چرا ما در Chrome نگرانی هایی در مورد اجرای سنگ تراشی به عنوان بخشی از مشخصات طرح بندی شبکه ای CSS داریم و دقیقاً مشخص می کند که پیشنهاد جایگزین چه چیزی را فعال می کند. به طور خلاصه:

  • تیم 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 و غیره) است، سنگ تراشی فقط دو ویژگی دارد.
  • Grid می تواند از هر شش ویژگی justify-* و align-* استفاده کند، اما Masonry فقط از یک زیر مجموعه مانند flexbox استفاده می کند.

همچنین باید مشخص شود که در تمام موارد خطای جدید ایجاد شده توسط توسعه‌دهندگان از مقداری استفاده می‌کنند که در grid-with-masonry یا grid-without-masonry معتبر نیست، چه اتفاقی می‌افتد. برای مثال، استفاده از grid-template-columns: masonry یا grid-template-rows: masonry معتبر است، اما نه هر دو در یک زمان. اگر هر دو را همزمان استفاده کنید چه اتفاقی می‌افتد؟ این جزئیات باید مشخص شود تا همه مرورگرها یک کار را انجام دهند.

این همه از نقطه نظر مشخصات، در حال حاضر و در آینده پیچیده می شود. ما باید اطمینان حاصل کنیم که همه چیز سنگ تراشی را در نظر می گیرد و اینکه آیا در سنگ تراشی کار می کند یا نه. از دیدگاه توسعه دهندگان نیز گیج کننده است. چرا باید این نکته را در ذهن خود داشته باشید که علیرغم استفاده از display: grid برخی از چیزها به دلیل استفاده از سنگ تراشی کار نمی کنند؟

یک پیشنهاد جایگزین

همانطور که قبلا ذکر شد، تیم کروم می‌خواهد سنگ‌تراشی را خارج از مشخصات شبکه تعریف کند. این بدان معنا نیست که به یک روش طرح بندی بسیار ساده با اندازه ستون های یکسان محدود می شود. همه دموهای موجود در پست 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 بپیوندید.

از Bramus، Tab Atkins-Bittner، Una Kravets، Ian Kilpatrick و Chris Harrelson برای بررسی این پست و بحث‌هایی که به آن اطلاع داده‌اند، تشکر می‌کنیم.

،

تیم Chrome مشتاق اجرای طرح‌بندی‌های نوع سنگ‌تراشی در وب است. با این حال، ما احساس می کنیم که اجرای آن به عنوان بخشی از مشخصات CSS Grid همانطور که در پست اخیر WebKit پیشنهاد شده است، اشتباه خواهد بود. ما همچنین احساس می کنیم که پست WebKit علیه نسخه ای از سنگ تراشی که هیچ کس آن را پیشنهاد نکرده بود، استدلال می کرد.

بنابراین، این پست قصد دارد توضیح دهد که چرا ما در Chrome نگرانی هایی در مورد اجرای سنگ تراشی به عنوان بخشی از مشخصات طرح بندی شبکه ای CSS داریم و دقیقاً مشخص می کند که پیشنهاد جایگزین چه چیزی را فعال می کند. به طور خلاصه:

  • تیم 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 و غیره) است، سنگ تراشی فقط دو ویژگی دارد.
  • Grid می تواند از هر شش ویژگی justify-* و align-* استفاده کند، اما Masonry فقط از یک زیر مجموعه مانند flexbox استفاده می کند.

همچنین باید مشخص شود که در تمام موارد خطای جدید ایجاد شده توسط توسعه‌دهندگان از مقداری استفاده می‌کنند که در grid-with-masonry یا grid-without-masonry معتبر نیست، چه اتفاقی می‌افتد. برای مثال، استفاده از grid-template-columns: masonry یا grid-template-rows: masonry معتبر است، اما نه هر دو در یک زمان. اگر هر دو را همزمان استفاده کنید چه اتفاقی می‌افتد؟ این جزئیات باید مشخص شود تا همه مرورگرها یک کار را انجام دهند.

این همه از نقطه نظر مشخصات، در حال حاضر و در آینده پیچیده می شود. ما باید اطمینان حاصل کنیم که همه چیز سنگ تراشی را در نظر می گیرد و اینکه آیا در سنگ تراشی کار می کند یا نه. از دیدگاه توسعه دهندگان نیز گیج کننده است. چرا باید این نکته را در ذهن خود داشته باشید که علیرغم استفاده از display: grid برخی از چیزها به دلیل استفاده از سنگ تراشی کار نمی کنند؟

یک پیشنهاد جایگزین

همانطور که قبلا ذکر شد، تیم کروم می‌خواهد سنگ‌تراشی را خارج از مشخصات شبکه تعریف کند. این بدان معنا نیست که به یک روش طرح بندی بسیار ساده با اندازه ستون های یکسان محدود می شود. همه دموهای موجود در پست 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 بپیوندید.

از Bramus، Tab Atkins-Bittner، Una Kravets، Ian Kilpatrick و Chris Harrelson برای بررسی این پست و بحث‌هایی که به آن اطلاع داده‌اند، تشکر می‌کنیم.

،

تیم Chrome مشتاق اجرای طرح‌بندی‌های نوع سنگ‌تراشی در وب است. با این حال، ما احساس می کنیم که اجرای آن به عنوان بخشی از مشخصات CSS Grid همانطور که در پست اخیر WebKit پیشنهاد شده است، اشتباه خواهد بود. ما همچنین احساس می کنیم که پست WebKit علیه نسخه ای از سنگ تراشی که هیچ کس آن را پیشنهاد نکرده بود، استدلال می کرد.

بنابراین، این پست قصد دارد توضیح دهد که چرا ما در Chrome نگرانی هایی در مورد اجرای سنگ تراشی به عنوان بخشی از مشخصات طرح بندی شبکه ای CSS داریم و دقیقاً مشخص می کند که پیشنهاد جایگزین چه چیزی را فعال می کند. به طور خلاصه:

  • تیم 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 و غیره) است، سنگ تراشی فقط دو ویژگی دارد.
  • Grid می تواند از هر شش ویژگی justify-* و align-* استفاده کند، اما Masonry فقط از یک زیر مجموعه مانند flexbox استفاده می کند.

همچنین باید مشخص شود که در تمام موارد خطای جدید ایجاد شده توسط توسعه‌دهندگان از مقداری استفاده می‌کنند که در grid-with-masonry یا grid-without-masonry معتبر نیست، چه اتفاقی می‌افتد. برای مثال، استفاده از grid-template-columns: masonry یا grid-template-rows: masonry معتبر است، اما نه هر دو در یک زمان. اگر هر دو را همزمان استفاده کنید چه اتفاقی می‌افتد؟ این جزئیات باید مشخص شود تا همه مرورگرها یک کار را انجام دهند.

این همه از نقطه نظر مشخصات، در حال حاضر و در آینده پیچیده می شود. ما باید اطمینان حاصل کنیم که همه چیز سنگ تراشی را در نظر می گیرد و اینکه آیا در سنگ تراشی کار می کند یا نه. از دیدگاه توسعه دهندگان نیز گیج کننده است. چرا باید این نکته را در ذهن خود داشته باشید که علیرغم استفاده از display: grid برخی از چیزها به دلیل استفاده از سنگ تراشی کار نمی کنند؟

یک پیشنهاد جایگزین

همانطور که قبلا ذکر شد، تیم کروم می‌خواهد سنگ‌تراشی را خارج از مشخصات شبکه تعریف کند. این بدان معنا نیست که به یک روش طرح بندی بسیار ساده با اندازه ستون های یکسان محدود می شود. همه دموهای موجود در پست 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 بپیوندید.

از Bramus، Tab Atkins-Bittner، Una Kravets، Ian Kilpatrick و Chris Harrelson برای بررسی این پست و بحث‌هایی که به آن اطلاع داده‌اند، تشکر می‌کنیم.

،

تیم Chrome مشتاق اجرای طرح‌بندی‌های نوع سنگ‌تراشی در وب است. با این حال، ما احساس می کنیم که اجرای آن به عنوان بخشی از مشخصات CSS Grid همانطور که در پست اخیر WebKit پیشنهاد شده است، اشتباه خواهد بود. ما همچنین احساس می کنیم که پست WebKit علیه نسخه ای از سنگ تراشی که هیچ کس آن را پیشنهاد نکرده بود، استدلال می کرد.

بنابراین، این پست قصد دارد توضیح دهد که چرا ما در Chrome نگرانی هایی در مورد اجرای سنگ تراشی به عنوان بخشی از مشخصات طرح بندی شبکه ای CSS داریم و دقیقاً مشخص می کند که پیشنهاد جایگزین چه چیزی را فعال می کند. به طور خلاصه:

  • تیم 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 و غیره) است، سنگ تراشی فقط دو ویژگی دارد.
  • Grid می تواند از هر شش ویژگی justify-* و align-* استفاده کند، اما Masonry فقط از یک زیر مجموعه مانند flexbox استفاده می کند.

همچنین باید مشخص شود که در تمام موارد خطای جدید ایجاد شده توسط توسعه‌دهندگان از مقداری استفاده می‌کنند که در grid-with-masonry یا grid-without-masonry معتبر نیست، چه اتفاقی می‌افتد. برای مثال، استفاده از grid-template-columns: masonry یا grid-template-rows: masonry معتبر است، اما نه هر دو در یک زمان. اگر هر دو را همزمان استفاده کنید چه اتفاقی می‌افتد؟ این جزئیات باید مشخص شود تا همه مرورگرها یک کار را انجام دهند.

این همه از نقطه نظر مشخصات، در حال حاضر و در آینده پیچیده می شود. ما باید اطمینان حاصل کنیم که همه چیز سنگ تراشی را در نظر می گیرد و اینکه آیا در سنگ تراشی کار می کند یا نه. از دیدگاه توسعه دهندگان نیز گیج کننده است. چرا باید این نکته را در ذهن خود داشته باشید که علیرغم استفاده از display: grid برخی از چیزها به دلیل استفاده از سنگ تراشی کار نمی کنند؟

یک پیشنهاد جایگزین

همانطور که قبلا ذکر شد، تیم کروم می‌خواهد سنگ‌تراشی را خارج از مشخصات شبکه تعریف کند. این بدان معنا نیست که به یک روش طرح بندی بسیار ساده با اندازه ستون های یکسان محدود می شود. همه دموهای موجود در پست 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 بپیوندید.

از Bramus، Tab Atkins-Bittner، Una Kravets، Ian Kilpatrick و Chris Harrelson برای بررسی این پست و بحث‌هایی که به آن اطلاع داده‌اند، تشکر می‌کنیم.