ข้อเสนอทางเลือกสำหรับการก่ออิฐ CSS

ทีมงาน Chrome ต้องการเห็นการนำเลย์เอาต์ประเภทอิฐก่อใน ข้อมูลเว็บ อย่างไรก็ตาม เรารู้สึกว่าการนำไปใช้ให้เป็นส่วนหนึ่งของข้อกำหนดตารางกริด CSS ตามที่ระบุไว้ใน โพสต์ WebKit ล่าสุด ก็ถือเป็นความผิดพลาด นอกจากนี้ เรายังรู้สึกว่าโพสต์ WebKit โต้แย้งความคิดเห็นของคุณ ที่ไม่มีใครเสนอให้

ดังนั้น โพสต์นี้จึงมีจุดมุ่งหมายเพื่ออธิบายว่าเหตุใดพวกเราที่ Chrome จึงมีความกังวลเกี่ยวกับ การใช้การก่ออิฐเป็นส่วนหนึ่งของข้อกำหนดการออกแบบตารางกริด CSS และชี้แจง สิ่งที่ข้อเสนอสำรองเปิดใช้งาน กล่าวโดยสรุปคือ

  • ทีม Chrome ต้องการเลิกบล็อกงานก่ออิฐ เราทราบดีว่า ที่ต้องการอีกด้วย
  • การเพิ่มสิ่งก่อสร้างในข้อมูลจำเพาะของตารางกริดเป็นปัญหาสำหรับ เหตุผลนอกเหนือจากที่คุณคิดว่าการก่ออิฐเป็นกริดหรือไม่
  • คำจำกัดความของการก่ออิฐ นอกข้อกำหนดตารางกริดไม่ได้ป้องกันแทร็กขนาดหลายขนาดสำหรับ การก่ออิฐ หรือการใช้คุณสมบัติ เช่น การปรับแนวหรือช่องว่าง หรือการใช้คุณสมบัติอื่นๆ ฟีเจอร์ที่ใช้ในเลย์เอาต์แบบตารางกริด

การก่ออิฐควรเป็นส่วนหนึ่งของตารางกริดหรือไม่

ทีม Chrome เชื่อว่าการก่ออิฐควรเป็นการออกแบบที่แยกต่างหาก วิธีการ กำหนดโดยใช้ display: masonry (หรือคีย์เวิร์ดอื่นควรใช้ชื่อที่ดีกว่า ตัดสินใจ) ในส่วนต่อไปของโพสต์นี้ คุณจะเห็นตัวอย่างว่า จะมีลักษณะเหมือนในโค้ด

มีเหตุผลที่เกี่ยวข้อง 2 ประการที่ทำให้เราคิดว่าการก่ออิฐได้รับการกำหนดไว้ที่ดีกว่าภายนอก ของเลย์เอาต์แบบตารางกริด ที่อาจเกิดขึ้นจากปัญหาด้านประสิทธิภาพของเลย์เอาต์ และข้อเท็จจริงที่ว่า ทั้งก่ออิฐและตารางกริดมีฟีเจอร์ที่เหมาะสมในการจัดวางตำแหน่งเดียว แต่กลับไม่มีลักษณะ อีกอย่างหนึ่ง

ประสิทธิภาพ

ตารางกริดและการก่ออิฐนั้นตรงกันข้ามในแง่ของวิธีที่เบราว์เซอร์จะจัดการกับการปรับขนาดและ ตำแหน่ง เมื่อมีการวางผังรายการ รายการทั้งหมดจะถูกวางก่อนการจัดวางและ จะรู้แน่ชัดว่าแต่ละแทร็กมีอะไร ซึ่งช่วยให้แท็กภายใน ซึ่งมีประโยชน์มากในตารางกริด ด้วยการก่ออิฐ สิ่งของจะวางอย่างที่ควรจะเป็น แต่เบราว์เซอร์จะไม่รู้จำนวนที่แท้จริงในแต่ละแทร็ก นี่ไม่ใช่ ปัญหาที่เกิดกับแทร็กที่มีขนาดภายในทั้งหมดหรือแทร็กที่มีขนาดคงที่ทั้งหมดแต่หากคุณ ผสมผสานแทร็กคงที่และแทร็กที่มีอยู่ ในการแก้ปัญหา เบราว์เซอร์จำเป็นต้อง วางขั้นตอนการจัดวางไว้ล่วงหน้าสำหรับ การจัดวางรายการทุกแบบ ด้วยตารางกริดขนาดใหญ่ ก็จะส่งผลต่อประสิทธิภาพของเลย์เอาต์ ปัญหา

ดังนั้น หากคุณมีการออกแบบสำหรับก่ออิฐที่มีคำจำกัดความของการติดตามเป็น grid-template-columns: 200px auto 200px เป็นสิ่งธรรมดาๆ ที่ต้องทำในตารางกริด เริ่มพบปัญหา โจทย์เหล่านี้จะกลายเป็นเลขชี้กำลังเมื่อคุณบวก ตารางกริดย่อย

มีเหตุผลหนึ่งที่คนส่วนใหญ่มัก ไม่ ต้องพบปัญหานี้ แต่เราได้ ทราบว่าผู้บริโภคมี ตารางกริด เราไม่ต้องการจัดส่ง บางอย่างที่มีขีดจำกัดว่าจะนำมาใช้งานได้ เมื่อมีทางเลือก ของเรา

เราทำอะไรกับสิ่งที่ไม่สมเหตุสมผลในการจัดวางแต่ละวิธี

เมื่อ Flexbox และ grid กลายเป็นส่วนหนึ่งของ CSS นักพัฒนาซอฟต์แวร์มักจะรู้สึกว่า มีพฤติกรรมที่ไม่สอดคล้องกัน ความไม่สอดคล้องกันที่พบคือ ก็เพราะสมมติฐานที่มีไว้เป็นเวลานานเกี่ยวกับวิธีการทำงานของเลย์เอาต์ โดยอิงจากเลย์เอาต์แบบบล็อก เมื่อเวลาผ่านไป นักพัฒนาซอฟต์แวร์เริ่มเข้าใจเกี่ยวกับการจัดรูปแบบ บริบทเหล่านี้ เมื่อเราเปลี่ยนเป็นตารางกริดหรือการจัดรูปแบบแบบยืดหยุ่น มีพฤติกรรมต่างกัน ตัวอย่างเช่น คุณรู้ว่าเมื่อคุณอยู่ใน Flexbox ไม่ใช่ทุกส่วน วิธีการจัดแนวที่ใช้ได้ เนื่องจาก Flexbox เป็นแบบ 1 มิติ

การรวมกลุ่มสิ่งก่อสร้างลงในตารางกริดจะเป็นการแบ่งความเชื่อมโยงที่ชัดเจนระหว่างบริบทการจัดรูปแบบกับ ความพร้อมใช้งานของสิ่งต่างๆ เช่น คุณสมบัติการปรับแนว ซึ่งระบุไว้ใน Box ข้อกำหนดการปรับแนวต่อบริบทการจัดรูปแบบ

หากเราตัดสินใจที่จะจัดการกับปัญหาประสิทธิภาพ ที่ระบุไว้ก่อนหน้านี้โดย คำนิยามของแทร็กแบบผสมและแทร็กคงที่ที่ผิดกฎหมายในการก่อสร้างถนน คุณต้อง แต่รูปแบบที่พบได้ทั่วไปสำหรับเลย์เอาต์แบบตารางกริดนั้นใช้ไม่ได้กับ การก่อสร้าง

นอกจากนี้ยังมีรูปแบบที่เหมาะสมกับการก่ออิฐเช่น 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 ไม่มีผลกับตารางกริด กำลังผสาน จะสร้างปัญหาของสิ่งที่ไม่ถูกต้อง เนื่องจากวิธีการจัดวาง อยู่ในตอนนี้
  • ตารางกริดมีพร็อพเพอร์ตี้ตำแหน่ง 4 รายการ (grid-column-start และต่อไปเรื่อยๆ) งานก่อสร้างมีแค่ 2 อย่าง
  • ตารางกริดใช้ justify-* และ align-* ได้ทั้ง 6 รายการ พร็อพเพอร์ตี้ แต่การก่ออิฐใช้เซตย่อย เช่น Flexbox เท่านั้น

นอกจากนี้ยังมีข้อกำหนดให้ระบุว่าจะเกิดอะไรขึ้นกับข้อผิดพลาดใหม่ทั้งหมดด้วย กรณีที่เกิดจากนักพัฒนาซอฟต์แวร์ใช้ค่าที่ไม่ถูกต้องในตารางกริดที่มีการก่ออิฐ หรือแบบโครงข่ายโดยไม่ต้องก่ออิฐ เช่น สามารถใช้ได้ grid-template-columns: masonry หรือ grid-template-rows: masonry แต่ไม่ใช่ทั้ง 2 อย่างพร้อมกัน จะเกิดอะไรขึ้นหากคุณใช้ทั้ง 2 อย่างพร้อมกัน คุณต้องระบุรายละเอียดเหล่านี้ เพื่อให้ทุกเบราว์เซอร์ ทำแบบเดียวกัน

ทั้งหมดนี้เริ่มซับซ้อนจากมุมมองด้านข้อกำหนด ทั้งในปัจจุบันและใน ในอนาคต เราต้องตรวจสอบให้แน่ใจว่าทุกอย่างเกี่ยวข้องกับการก่ออิฐ และ ไม่ว่างานก่ออิฐถือปูน แต่ยังสับสนจากประเด็นที่ว่า ในมุมมองของนักพัฒนาซอฟต์แวร์ ทำไมคุณจึงต้องเอาใจเขามาใส่ใจเรา การใช้ display: grid บางอย่างไม่ได้ผลเพราะใช้สิ่งก่อสร้างไม่ได้แล้วใช่ไหม

ข้อเสนอทางเลือก

ดังที่กล่าวไปแล้ว ทีม Chrome ต้องการที่จะระบุความหมายของการก่ออิฐภายนอก ตามข้อกำหนดของตารางกริด ซึ่งไม่ได้หมายความว่า วิธีเลย์เอาต์แบบง่ายที่มีขนาดคอลัมน์เหมือนกัน การสาธิตทั้งหมดใน WebKit ก็ยังคงเป็นไปได้

รูปแบบการก่ออิฐแบบคลาสสิก

เมื่อนึกถึงการก่ออิฐ คนส่วนใหญ่ ก็จะนึกถึงเลย์เอาต์ที่มีบล็อกหลายชั้น ที่ปรับขนาดได้ โดยจะกำหนดโดยใช้ CSS ต่อไปนี้ซึ่งต้องมีบรรทัด โค้ดน้อยกว่าตารางที่สัมพันธ์กันซึ่งจัดกลุ่มอยู่ version

.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;
}

รูปแบบของแทร็กแบบกว้างและแคบ

การปรับขนาดการติดตามเพิ่มเติมสำหรับการก่ออิฐ

มีตัวเลือกการปรับขนาดแทร็กเพิ่มเติมที่เราไม่อนุญาตในตารางเนื่องจาก ความจริงที่ว่าตารางกริดคือวิธีการจัดวางแบบ 2 มิติ สิ่งเหล่านี้จะเป็นประโยชน์ใน งานก่ออิฐ แต่คงจะสับสนหากไม่ทำงานในตารางกริด

กำลังเติมแทร็กที่มีขนาด 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 */
}

การก่ออิฐที่มีการวางและประแจ

การก่ออิฐหรือการก่อสร้างย่อยที่รับการก่ออิฐ

วิธีนี้สามารถใช้กับข้อกำหนดการก่ออิฐที่แยกต่างหาก อีกครั้งด้วย ไม่อนุญาตให้ใช้แทร็กที่มีขนาดคงที่และแทร็กที่มีขนาดคงที่ผสมกัน ใช่แล้ว ที่ดูเหมือนจะต้องมีการกำหนด เราไม่พบเหตุผลที่การดำเนินการนี้จะไม่ งาน

บทสรุป

เราอยากจะแจ้งให้ทราบถึงข้อกำหนดที่จัดส่งได้ ที่ทำงานร่วมกัน อย่างไรก็ตาม เราต้องการทำให้รูปแบบดังกล่าว ทำงานได้ดีทั้งในปัจจุบันและในอนาคต ที่นักพัฒนาซอฟต์แวร์สามารถพึ่งพาได้ วิธีเดียวที่จะจัดการกับ ปัญหาด้านประสิทธิภาพที่ระบุไว้ จะเป็นปัญหาที่ 2 ซึ่งก็คือ การมีส่วนต่างๆ ของตารางกริดผิดกฎหมายในการก่ออิฐ - แย่ที่สุด เราคิดว่าวิธีนี้ไม่ดี ของคุณโดยเฉพาะ โดยเฉพาะอย่างยิ่งเมื่อเป็นไปได้ที่จะมีฟีเจอร์ตารางกริดทั้งหมดที่คุณต้องการ โดยเก็บสิ่งที่แยกออกจากกันอย่างชัดเจน

หากคุณมีความคิดเห็นใดๆ ให้เข้าร่วมการสนทนาใน ปัญหา 9041

ขอขอบคุณ Bramus, Tab Atkins-Bittner, Una Kravets, Ian Kilpatrick และ Chris Harrelson เพื่อตรวจสอบโพสต์นี้และการสนทนาที่แจ้งให้ทราบแล้ว