הצעה חלופית לבנייה של שירות CSS

פורסם: 30 באפריל 2024, עדכון אחרון: 13 בפברואר 2026

צוות Chrome רוצה לראות הטמעה של פריסות מסוג בנייה בשיטת מייסונרי באינטרנט. עם זאת, לדעתנו, יישום התכונה כחלק ממפרט CSS Grid כפי שהוצע בפוסט האחרון ב-WebKit יהיה טעות. אנחנו גם חושבים שהפוסט ב-WebKit טען נגד גרסה של פריסת בלוקים שאף אחד לא הציע.

לכן, במאמר הזה נסביר למה ב-Chrome יש לנו חששות לגבי הטמעה של masonry כחלק ממפרט פריסת ה-CSS Grid, ונבהיר בדיוק מה ההצעה החלופית מאפשרת. בקצרה:

  • צוות Chrome מאוד רוצה לבטל את החסימה של masonry, כי אנחנו יודעים שזה משהו שמפתחים רוצים.
  • הוספת פריסה חופשית למפרט הרשת בעייתית מסיבות אחרות, ולא רק בגלל השאלה אם פריסה חופשית היא רשת או לא.
  • הגדרת פריסת masonry מחוץ למפרט של רשת לא מונעת שימוש בכמה גדלים של רצועות בפריסת masonry, או שימוש במאפיינים כמו יישור או רווחים, או בכל תכונה אחרת שמשמשת בפריסת רשת.

האם פריסת מייסונרי צריכה להיות חלק מהרשת?

הצוות של Chrome מאמין שפריסת masonry צריכה להיות שיטת פריסה נפרדת, שמוגדרת באמצעות display: masonry (או מילת מפתח אחרת, אם יוחלט על שם טוב יותר). בהמשך הפוסט הזה מוצגות כמה דוגמאות לאופן שבו זה יכול להיראות בקוד.

יש שתי סיבות קשורות לכך שאנחנו חושבים שפריסת קיר עדיפה מחוץ לפריסת רשת – הפוטנציאל לבעיות בביצועי הפריסה והעובדה שלפריסת קיר ולפריסת רשת יש תכונות שמתאימות לשיטת פריסה אחת אבל לא לשיטה השנייה.

ביצועים

ההבדל בין פריסת רשת לפריסת לבנים הוא באופן שבו הדפדפן מתמודד עם הגודל והמיקום של הרכיבים. כשמגדירים פריסה של רשת, כל הפריטים ממוקמים לפני הפריסה והדפדפן יודע בדיוק מה יש בכל רצועה. כך אפשר להשתמש בשינוי גודל מורכב ומוטמע, שימושי מאוד בפריסת Grid. בפריסה מסוג masonry, הפריטים ממוקמים כמו שהם, והדפדפן לא יודע כמה פריטים יש בכל מסלול. הבעיה הזו לא קיימת בכל הרצועות עם גודל פנימי או בכל הרצועות עם גודל קבוע, אלא רק אם משלבים בין רצועות עם גודל קבוע לבין רצועות עם גודל פנימי. כדי לפתור את הבעיה, הדפדפן צריך לבצע שלב של פריסה מראש של כל פריט בכל דרך אפשרית כדי לקבל מדידות. אם מדובר ברשת גדולה, זה יגרום לבעיות בביצועי הפריסה.

לכן, אם יש לכם פריסת masonry עם הגדרת track של grid-template-columns: 200px auto 200px – דבר נפוץ מאוד בפריסת grid – אתם עלולים להיתקל בבעיות. הבעיות האלה הופכות למורכבות יותר כשמוסיפים רשתות משנה.

יש טענה שרוב האנשים לא ייתקלו בבעיה הזו, אבל אנחנו כבר יודעים שיש אנשים עם רשתות גדולות מאוד. אנחנו לא רוצים לשלוח משהו שיש לו מגבלות על אופן השימוש בו, כשיש גישה חלופית.

מה עושים לגבי דברים שלא הגיוניים בכל אחת משיטות הפריסה?

כש-flexbox ו-grid הפכו לחלק מ-CSS, מפתחים רבים הרגישו שההתנהגות שלהם לא עקבית. חוסר העקביות שהם חוו נבע מהנחות ארוכות טווח לגבי אופן הפריסה, על סמך פריסת בלוקים. עם הזמן, המפתחים התחילו להבין את ההקשרים של העיצוב. כשעוברים להקשר של עיצוב grid או flex, חלק מהדברים מתנהגים אחרת. לדוגמה, אתם יודעים שכאשר אתם משתמשים ב-flexbox, לא כל שיטות היישור זמינות, כי flexbox הוא חד-ממדי.

כשמשלבים פריסת masonry עם פריסת grid, הקישור הברור בין הקשר העיצוב לבין הזמינות של דברים כמו מאפייני יישור נשבר. מאפייני היישור מוגדרים במפרט Box Alignment לכל הקשר עיצוב.

אם נחליט לטפל בבעיית הביצועים שצוינה קודם על ידי הגדרת הגדרות מעורבות של מסלולים קבועים ומסלולים פנימיים כלא חוקיות בפריסת masonry, תצטרכו לזכור שתבנית נפוצה מאוד של פריסות grid לא מתאימה לפריסת masonry.

יש גם תבניות שמתאימות לפריסה של בלוקים, למשל grid-template-columns: repeat(auto-fill, max-content), כי אין אילוצים צולבים, אבל הן לא תקפות בפריסה של רשת. בהמשך מפורטת רשימה של מאפיינים שצפויים להתנהג בצורה שונה או שיש להם ערכים חוקיים שונים.

  • grid-template-areas: בפריסת Masonry אפשר לציין רק את השורה הראשונית בכיוון שאינו Masonry.
  • grid-template: הקיצור צריך לכלול את כל ההבדלים.
  • מעקב אחר ערכי הגודל של grid-template-columns ושל grid-template-rows בגלל הבדלים בערכים החוקיים.
  • המאפיין grid-auto-flow לא חל על פריסת masonry, והמאפיין masonry-auto-flow לא חל על פריסת grid. מיזוג שלהם ייצור בעיות של דברים לא תקינים בגלל שיטת הפריסה שבה אתם משתמשים.
  • לפריסת רשת יש ארבעה מאפייני מיקום (grid-column-start וכן הלאה), ולפריסת קיר לבנים יש רק שניים.
  • בפריסה מסוג Grid אפשר להשתמש בכל ששת המאפיינים justify-* ו-align-*, אבל בפריסה מסוג Masonry אפשר להשתמש רק בחלק מהם, כמו בפריסה מסוג Flexbox.

בנוסף, יהיה צורך לציין מה קורה בכל מקרי השגיאה החדשים שנגרמים בגלל מפתחים שמשתמשים בערך לא תקין בפריסה מסוג grid-with-masonry או grid-without-masonry. לדוגמה, אפשר להשתמש ב-grid-template-columns: masonry או ב-grid-template-rows: masonry, אבל לא בשניהם בו-זמנית. מה קורה אם משתמשים בשניהם בו-זמנית? צריך לציין את הפרטים האלה כדי שכל הדפדפנים יפעלו באותו אופן.

הדבר הזה מסתבך מבחינת המפרט, גם עכשיו וגם בעתיד. אנחנו צריכים לוודא שהכל לוקח בחשבון את פריסת ה-Masonry, ושהפריסה פועלת או לא פועלת ב-Masonry. הוא גם מבלבל מנקודת המבט של המפתחים. למה צריך לזכור שבגלל השימוש ב-display: grid, חלק מהדברים לא פועלים?

הצעה חלופית

כפי שצוין קודם, צוות Chrome רוצה להגדיר את הפריסה של masonry מחוץ למפרט של grid. זה לא אומר שהפריסה תוגבל לשיטה פשוטה מאוד עם גדלים זהים של עמודות. כל ההדגמות בפוסט של WebKit עדיין אפשריות.

פריסת מבני אבן קלאסית

כשרוב האנשים חושבים על פריסת לבנים, הם חושבים על פריסה עם כמה עמודות בגודל שווה. ההגדרה תתבצע באמצעות ה-CSS הבא, שדורש פחות שורות קוד מאשר גרסת ה-grid המקבילה.

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

טראקים בגודל שווה.

שימוש בגדלים של רצועות מסוג grid לרוחבים שונים של עמודות

חוץ מהבעיה שצוינה קודם לגבי גודל משולב של רכיבי track קבועים ורכיבי track בגודל טבעי, אפשר להשתמש בכל הגדלים של רכיבי track שאתם אוהבים מרשת. לדוגמה, הדוגמה מפוסט בבלוג של WebKit, שבה מוצג דפוס של עמודות צרות ורחבות שחוזרות על עצמן.

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

תבנית של רצועות ברוחב משתנה.

גודל מסלול נוסף לסידור Masonry

יש אפשרויות נוספות לשינוי הגודל של הטראקים, אבל אנחנו לא מאפשרים אותן בפריסה של grid כי זו שיטה לפריסה דו-ממדית. הם יכולים להיות שימושיים בפריסה של בלוקים, אבל זה עלול להיות מבלבל אם הם לא יעבדו בפריסה של רשת.

מילוי אוטומטי של טראקים בגודל 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

אין סיבה לא לכלול תוכן שמשתרע על פני עמודות במפרט נפרד של פריסת Masonry. יכול להיות שנעשה שימוש במאפיין masonry-track, שהוא קיצור של masonry-track-start ו-masonry-track-end, כי יש רק מאפיין אחד שצריך להגדיר לו טווח כשמשתמשים בפריסת masonry.

.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 */
}

פריסת Masonry עם פריטים שמוצבים ופריטים שמתפרסים על פני כמה עמודות.

פריסת משנה או רשת משנה שמשתמשות בפריסת עמודים

אפשר לתמוך בזה באמצעות הגדרה נפרדת של פריסת לבנים, שוב עם ההערה שאסור להשתמש בשילוב של טראקים עם גודל קבוע וטראקים עם גודל פנימי. צריך להגדיר בדיוק איך זה ייראה. לא מצאנו סיבה לכך שהפעולה הזו לא תצליח.

סיכום

נשמח להגיע למצב שבו נוכל לשלוח מפרט שניתן להשתמש בו באופן הדדי. עם זאת, אנחנו רוצים לעשות את זה בצורה שתעבוד טוב עכשיו ובעתיד, ושמפתחים יוכלו להסתמך עליה. הדרך היחידה לטפל בבעיות הביצועים שצוינו היא להחמיר את הבעיה השנייה – חלקים ברשת לא חוקיים בפריסה חופשית. אנחנו לא חושבים שזה פתרון טוב, במיוחד כשאפשר להשתמש בכל התכונות של התצוגה ברשת ולשמור על הפרדה ברורה בין הדברים השונים.

אם יש לכם משוב, אתם יכולים להצטרף לדיון בבעיה מספר 9041.

תודה ל-Bramus,‏ Tab Atkins-Bittner,‏ Una Kravets,‏ Ian Kilpatrick ו-Chris Harrelson על הבדיקה של הפוסט הזה ועל הדיונים שהובילו לכתיבתו.