ประมาณ 15 ปีที่แล้ว ฉันทำงานในบริษัทที่เราสร้างแอปสำหรับตัวแทนการท่องเที่ยว พนักงานสนามบิน และบริษัทสายการบิน นอกจากนี้เรายังสร้างเฟรมเวิร์กภายในของเราเองสำหรับส่วนประกอบ UI และความสามารถของแอปหน้าเดียว เรามีส่วนประกอบสำหรับทุกสิ่ง: ฟิลด์ ปุ่ม แท็บ ช่วง ตารางข้อมูล เมนู เครื่องมือเลือกวันที่ การเลือก และการเลือกหลายรายการ เรายังมีองค์ประกอบ div ด้วยซ้ำ อย่างไรก็ตาม องค์ประกอบ div ของเรานั้นยอดเยี่ยมมาก มันช่วยให้เราสามารถโค้งมนบนเบราว์เซอร์ทั้งหมด ซึ่งไม่ว่าจะเชื่อหรือไม่ก็ตาม ไม่ใช่เรื่องง่ายที่จะทำในเวลานั้น
งานของเราเกิดขึ้นในจุดหนึ่งในประวัติศาสตร์ของเราเมื่อ JS, Ajax และ HTML แบบไดนามิกถูกมองว่าเป็นการปฏิวัติที่นำเราไปสู่อนาคต ทันใดนั้น เราก็สามารถอัปเดตเพจแบบไดนามิก รับข้อมูลจากเซิร์ฟเวอร์ และหลีกเลี่ยงการไปยังหน้าอื่นๆ ซึ่งถูกมองว่าช้าและปรากฏสี่เหลี่ยมสีขาวขนาดใหญ่บนหน้าจอระหว่างทั้งสองหน้า มีวลีหนึ่งที่ได้รับความนิยมโดย Jeff Atwood (ผู้ก่อตั้ง StackOverflow) ซึ่งอ่านว่า: “แอปพลิเคชันใด ๆ ที่สามารถเขียนด้วย JavaScript ในที่สุดก็จะเขียนด้วย JavaScript”— Jeff Atwood
สำหรับเราในตอนนั้น รู้สึกเหมือนเป็นการกล้าที่จะสร้างสรรค์แอปเหล่านั้นขึ้นมาจริงๆ รู้สึกเหมือนเป็นการอนุมัติแบบครอบคลุมในการทำทุกอย่างกับ JS ดังนั้นเราจึงทำทุกอย่างกับ JS และเราไม่ได้ใช้เวลาค้นคว้าวิธีการอื่นในการทำสิ่งต่างๆ เลย เราไม่รู้สึกว่ามีแรงจูงใจที่จะเรียนรู้อย่างถูกต้องว่า HTML และ CSS สามารถทำอะไรได้บ้าง เราไม่ได้มองว่าเว็บเป็นแพลตฟอร์มแอปที่มีการพัฒนาอย่างครบถ้วน ส่วนใหญ่เราเห็นว่ามันเป็นสิ่งที่เราต้องแก้ไข โดยเฉพาะอย่างยิ่งเมื่อเป็นเรื่องของการรองรับเบราว์เซอร์ เราก็แค่โยน JS เข้าไปให้มากขึ้นเพื่อทำงานให้เสร็จ การสละเวลาเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับวิธีการทำงานของเว็บและสิ่งที่มีอยู่ในแพลตฟอร์มจะช่วยฉันได้ไหม แน่นอนว่าฉันอาจจะโกนโค้ดจำนวนหนึ่งที่ไม่จำเป็นจริงๆ ได้ แต่ ณ เวลานั้น อาจจะไม่มากขนาดนั้น คุณเห็นไหมว่าความแตกต่างของเบราว์เซอร์ค่อนข้างสำคัญในตอนนั้น นี่เป็นช่วงเวลาที่ Internet Explorer ยังคงเป็นเบราว์เซอร์ที่โดดเด่น โดยมี Firefox ตามมาเป็นอันดับสอง แต่เริ่มสูญเสียส่วนแบ่งการตลาดเนื่องจาก Chrome ได้รับความนิยมอย่างรวดเร็ว แม้ว่า Chrome และ Firefox จะค่อนข้างดีในการยอมรับมาตรฐานเว็บ แต่สภาพแวดล้อมที่แอปของเราทำงานอยู่นั้นหมายความว่าเราต้องรองรับ IE6 มาเป็นเวลานาน แม้ว่าเราจะได้รับอนุญาตให้สนับสนุน IE8 แต่เรายังคงต้องจัดการกับความแตกต่างมากมายระหว่างเบราว์เซอร์ ไม่เพียงเท่านั้น เว็บในยุคนั้นยังไม่มีความสามารถมากมายที่สร้างไว้ในแพลตฟอร์ม
ก้าวไปข้างหน้าอย่างรวดเร็วในวันนี้ สิ่งต่าง ๆ มีการเปลี่ยนแปลงอย่างมาก เราไม่เพียงแต่มีความสามารถเหล่านี้มากขึ้นกว่าที่เคย แต่อัตราที่ความสามารถเหล่านี้พร้อมใช้งานก็เพิ่มขึ้นเช่นกัน ให้ฉันถามคำถามอีกครั้ง: สละเวลาเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับวิธีการทำงานของเว็บและสิ่งที่มีอยู่บนแพลตฟอร์มจะช่วยคุณในวันนี้หรือไม่ ใช่อย่างแน่นอน การเรียนรู้ที่จะเข้าใจและใช้แพลตฟอร์มเว็บในปัจจุบันจะทำให้คุณได้เปรียบเหนือนักพัฒนารายอื่นๆ อย่างมาก ไม่ว่าคุณจะทำงานด้านประสิทธิภาพ การเข้าถึง การตอบสนอง ทั้งหมดเข้าด้วยกัน หรือเพียงแค่จัดส่งฟีเจอร์ UI หากคุณต้องการทำงานในฐานะวิศวกรที่รับผิดชอบ การรู้ว่าเครื่องมือที่คุณมีจะช่วยให้คุณบรรลุเป้าหมายได้เร็วและดีขึ้น บางสิ่งคุณอาจไม่ต้องการห้องสมุดอีกต่อไป เมื่อรู้ว่าเบราว์เซอร์ใดรองรับในปัจจุบัน คำถามก็คือ: เราจะทิ้งอะไรได้บ้าง เราจำเป็นต้องมีองค์ประกอบ div เพื่อทำมุมโค้งมนในปี 2568 หรือไม่? แน่นอนว่าเราไม่ทำ คุณสมบัติ border-radius ได้รับการสนับสนุนโดยเบราว์เซอร์ที่ใช้อยู่ทั้งหมดในปัจจุบันมานานกว่า 15 ปี ณ จุดนี้ และรูปทรงเข้ามุมกำลังจะมาในเร็วๆ นี้ สำหรับมุมที่แปลกใหม่ยิ่งขึ้น มาดูคุณลักษณะล่าสุดที่ขณะนี้พร้อมใช้งานในเบราว์เซอร์หลักๆ ทั้งหมด และที่คุณสามารถใช้เพื่อแทนที่การขึ้นต่อกันที่มีอยู่ในโค้ดเบสของคุณ ประเด็นไม่ได้อยู่ที่การละทิ้งไลบรารี่ที่คุณรักทั้งหมดและเขียนโค้ดเบสของคุณใหม่โดยทันที สำหรับทุกสิ่งทุกอย่าง คุณจะต้องคำนึงถึงการสนับสนุนเบราว์เซอร์ก่อน และตัดสินใจโดยพิจารณาจากปัจจัยอื่นๆ ที่เฉพาะเจาะจงสำหรับโครงการของคุณ คุณลักษณะต่อไปนี้ถูกนำมาใช้ในกลไกเบราว์เซอร์หลักสามรายการ (Chromium, WebKit และ Gecko) แต่คุณอาจมีข้อกำหนดการสนับสนุนเบราว์เซอร์ที่แตกต่างกันซึ่งทำให้ไม่สามารถใช้งานได้ทันที ขณะนี้ยังเป็นเวลาที่ดีที่จะเรียนรู้เกี่ยวกับคุณลักษณะเหล่านี้ และอาจวางแผนที่จะใช้งานในบางจุด Popovers และกล่องโต้ตอบ Popover API, องค์ประกอบ
แน่นอนว่าความเร็วการเชื่อมต่ออินเทอร์เน็ตของคุณก็อาจเพิ่มขึ้นเช่นกัน แต่นั่นไม่ใช่สำหรับทุกคน และไม่ใช่ทุกคนที่มีความสามารถของอุปกรณ์เหมือนกัน การดึงโค้ดจากบุคคลที่สามมาทำสิ่งที่คุณสามารถทำได้กับแพลตฟอร์มแทน อาจหมายความว่าคุณจัดส่งโค้ดมากขึ้น และเข้าถึงลูกค้าได้น้อยกว่าปกติ บนเว็บ ประสิทธิภาพการโหลดที่ไม่ดีทำให้เกิดอัตราการละทิ้งจำนวนมาก และทำให้ชื่อเสียงของแบรนด์เสียหาย ใช้โค้ดน้อยลงบนอุปกรณ์ นอกจากนี้ โค้ดที่คุณจัดส่งบนอุปกรณ์ของลูกค้ามีแนวโน้มที่จะทำงานเร็วขึ้นหากใช้ JavaScript Abstractions น้อยลงบนแพลตฟอร์ม มันอาจจะตอบสนองมากกว่าและเข้าถึงได้มากกว่าโดยค่าเริ่มต้น ทั้งหมดนี้ส่งผลให้ลูกค้ามีความสุขมากขึ้น ตรวจสอบบล็อกช่องว่างด้านประสิทธิภาพที่ไม่เท่าเทียมกันประจำปีของเพื่อนร่วมงานของฉัน Alex Russell ซึ่งแสดงให้เห็นว่าอุปกรณ์ระดับพรีเมียมส่วนใหญ่ไม่อยู่ในตลาดที่มีผู้ใช้หลายพันล้านคนเนื่องจากความไม่เท่าเทียมกันด้านความมั่งคั่ง และช่องว่างนี้ก็เพิ่มขึ้นตามกาลเวลาเท่านั้น
เค้าโครงก่ออิฐในตัว คุณลักษณะหนึ่งของแพลตฟอร์มเว็บที่จะมาในเร็วๆ นี้ และที่ฉันตื่นเต้นมากคือ CSS Masonry
ฉันขอเริ่มต้นด้วยการอธิบายว่าการก่ออิฐคืออะไร การก่ออิฐคืออะไร การก่ออิฐเป็นเลย์เอาต์ประเภทหนึ่งที่ Pinterest ได้รับความนิยมเมื่อหลายปีก่อน มันสร้างแทร็กเนื้อหาที่เป็นอิสระซึ่งรายการต่างๆ จะรวมตัวกันใกล้กับจุดเริ่มต้นของแทร็กมากที่สุด
หลายๆ คนมองว่า Masonry เป็นตัวเลือกที่ยอดเยี่ยมสำหรับแฟ้มผลงานและแกลเลอรีรูปภาพ ซึ่งแน่นอนว่าสามารถทำได้ แต่ Masonry มีความยืดหยุ่นมากกว่าที่คุณเห็นใน Pinterest และไม่ได้จำกัดอยู่เพียงเค้าโครงที่เหมือนน้ำตกเท่านั้น ในรูปแบบการก่ออิฐ:
แทร็กอาจเป็นคอลัมน์หรือแถว:
แทร็กเนื้อหาไม่จำเป็นต้องมีขนาดเท่ากันทั้งหมด:
รายการสามารถขยายได้หลายแทร็ก:
ไอเท็มสามารถวางบนแทร็กเฉพาะได้ พวกเขาไม่จำเป็นต้องปฏิบัติตามอัลกอริธึมการจัดตำแหน่งอัตโนมัติเสมอไป:
การสาธิต นี่คือการสาธิตง่ายๆ บางส่วนที่ฉันสร้างขึ้นโดยใช้การใช้งาน CSS Masonry ใน Chromium ที่กำลังจะมีขึ้น การสาธิตแกลเลอรีรูปภาพ แสดงให้เห็นว่ารายการต่างๆ (ชื่อในกรณีนี้) สามารถขยายหลายแทร็กได้อย่างไร:
แกลเลอรี่รูปภาพอื่นที่แสดงแทร็กขนาดต่างๆ:
เค้าโครงเว็บไซต์ข่าวที่มีแทร็กบางแทร็กกว้างกว่าแทร็กอื่น และบางรายการครอบคลุมความกว้างทั้งหมดของเค้าโครง:
กระดานคัมบังที่แสดงว่ารายการต่างๆ สามารถวางบนแทร็กเฉพาะได้:
หมายเหตุ:การสาธิตก่อนหน้านี้สร้างขึ้นด้วย Chromium เวอร์ชันที่ผู้ใช้เว็บส่วนใหญ่ยังไม่มีให้บริการ เนื่องจาก CSS Masonry เพิ่งเริ่มใช้งานในเบราว์เซอร์เท่านั้น อย่างไรก็ตาม นักพัฒนาเว็บใช้ไลบรารีเพื่อสร้างเค้าโครง Masonry อย่างมีความสุขมาหลายปีแล้ว ไซต์ที่ใช้การก่ออิฐในปัจจุบัน แท้จริงแล้ว Masonry เป็นเรื่องปกติบนเว็บในปัจจุบัน นี่คือตัวอย่างบางส่วนที่ฉันพบนอกเหนือจาก Pinterest:
และอีกสองสามตัวอย่างที่ชัดเจนน้อยกว่า:
แล้วเลย์เอาต์เหล่านี้ถูกสร้างขึ้นมาได้อย่างไร? วิธีแก้ปัญหา เคล็ดลับอย่างหนึ่งที่ฉันเคยเห็นใช้คือการใช้เค้าโครง Flexbox แทน เปลี่ยนทิศทางเป็นคอลัมน์ และตั้งค่าเป็น Wrap ด้วยวิธีนี้ คุณสามารถวางสิ่งของที่มีความสูงต่างกันในหลายคอลัมน์ที่แยกจากกัน ให้ความรู้สึกเหมือนเค้าโครงแบบก่ออิฐ:
อย่างไรก็ตาม มีข้อจำกัดสองประการในวิธีแก้ปัญหานี้:
ลำดับของรายการแตกต่างไปจากลำดับของเลย์เอาต์ก่ออิฐจริง เมื่อใช้ Flexbox รายการจะเติมคอลัมน์แรกก่อน และเมื่อเต็มแล้วจึงไปที่คอลัมน์ถัดไป เมื่อใช้ Masonry สิ่งของจะซ้อนกันไม่ว่าแทร็ก (หรือคอลัมน์ในกรณีนี้) จะมีพื้นที่ว่างมากขึ้น แต่และอาจสำคัญกว่านั้นคือ วิธีแก้ปัญหานี้กำหนดให้คุณตั้งค่าความสูงคงที่ให้กับคอนเทนเนอร์ Flexbox มิฉะนั้นจะไม่มีการห่อเกิดขึ้น
ห้องสมุดก่ออิฐของบุคคลที่สาม สำหรับกรณีขั้นสูง นักพัฒนาได้ใช้ไลบรารี ห้องสมุดที่เป็นที่รู้จักและได้รับความนิยมมากที่สุดเรียกง่ายๆ ว่า Masonry และมีการดาวน์โหลดประมาณ 200,000 ครั้งต่อสัปดาห์ตาม NPM Squarespace ยังมีองค์ประกอบเลย์เอาต์ที่แสดงเลย์เอาต์แบบ Masonry เป็นทางเลือกที่ไม่ต้องเขียนโค้ด และมีเว็บไซต์จำนวนมากใช้งาน ตัวเลือกทั้งสองนี้ใช้โค้ด JavaScript เพื่อวางรายการต่างๆ ในเค้าโครง ก่ออิฐในตัว ฉันตื่นเต้นมากที่ตอนนี้ Masonry เริ่มปรากฏในเบราว์เซอร์เป็นฟีเจอร์ CSS ในตัว เมื่อเวลาผ่านไป คุณจะสามารถใช้ Masonry ได้เหมือนกับที่คุณใช้ Grid หรือ Flexbox กล่าวคือ โดยไม่ต้องใช้วิธีแก้ปัญหาหรือโค้ดจากบุคคลที่สาม ทีมงานของฉันที่ Microsoft ได้นำการสนับสนุน Masonry ในตัวมาใช้ในโครงการโอเพ่นซอร์ส Chromium ซึ่งใช้ Edge, Chrome และเบราว์เซอร์อื่นๆ อีกมากมาย Mozilla เป็นผู้จำหน่ายเบราว์เซอร์รายแรกที่เสนอการทดลองใช้งาน Masonry ในปี 2020 และ Apple ก็สนใจอย่างมากในการทำให้เค้าโครงเว็บใหม่นี้เกิดขึ้นจริง งานเพื่อสร้างมาตรฐานให้กับฟีเจอร์นี้กำลังก้าวไปข้างหน้า โดยมีข้อตกลงภายในคณะทำงาน CSS เกี่ยวกับทิศทางทั่วไปและแม้แต่จอแสดงผลประเภทใหม่: ช่องทางกริด หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการก่ออิฐและติดตามความคืบหน้า โปรดดูหน้าทรัพยากร CSS Masonry ของฉัน เมื่อเวลาผ่านไป เมื่อ Masonry กลายเป็นฟีเจอร์พื้นฐาน เช่นเดียวกับ Grid หรือ Flexbox เราจะสามารถใช้มันและได้รับประโยชน์จาก:
ประสิทธิภาพที่ดีขึ้น การตอบสนองที่ดีขึ้น ใช้งานง่ายและโค้ดที่เรียบง่ายยิ่งขึ้น
ลองมาดูสิ่งเหล่านี้ให้ละเอียดยิ่งขึ้น ประสิทธิภาพที่ดีขึ้น การสร้างระบบเค้าโครงเหมือนอิฐของคุณเอง หรือใช้ไลบรารีของบุคคลที่สามแทน หมายความว่าคุณจะต้องเรียกใช้โค้ด JavaScript เพื่อวางรายการต่างๆ บนหน้าจอ นี่ก็หมายความว่าโค้ดนี้จะถูกบล็อกการแสดงผล แน่นอนว่าไม่มีอะไรปรากฏขึ้น หรือสิ่งต่าง ๆ จะไม่อยู่ในตำแหน่งที่ถูกต้องหรือขนาดที่ถูกต้อง จนกว่าโค้ด JavaScript จะเริ่มทำงาน เลย์เอาต์ก่ออิฐมักใช้สำหรับส่วนหลักของหน้าเว็บ ซึ่งหมายความว่าโค้ดจะทำให้เนื้อหาหลักของคุณปรากฏช้ากว่าที่ควรจะเป็น ส่งผลให้ LCP ของคุณหรือตัววัด Largest Contentful Paint ลดลง ซึ่งมีบทบาทสำคัญในประสิทธิภาพการรับรู้และการเพิ่มประสิทธิภาพกลไกค้นหา ฉันทดสอบไลบรารี Masonry JS ด้วยรูปแบบที่เรียบง่าย และโดยการจำลองการเชื่อมต่อ 4G ที่ช้าใน DevTools ไลบรารีมีขนาดไม่ใหญ่มาก (24KB, 7.8KB gzipped) แต่ใช้เวลาโหลด 600ms ภายใต้เงื่อนไขการทดสอบของฉัน นี่คือการบันทึกประสิทธิภาพที่แสดงให้เห็นว่าเวลาในการโหลดนาน 600 มิลลิวินาทีสำหรับไลบรารี Masonry และไม่มีกิจกรรมการเรนเดอร์อื่นๆ เกิดขึ้นในขณะที่กำลังเกิดขึ้น:
นอกจากนี้ หลังจากเวลาโหลดครั้งแรก สคริปต์ที่ดาวน์โหลดมาจะต้องถูกแยกวิเคราะห์ คอมไพล์ และรัน ดังที่ได้กล่าวไว้ก่อนหน้านี้เป็นการบล็อกการแสดงผลของเพจ ด้วยการใช้งาน Masonry ในตัวในเบราว์เซอร์ เราจะไม่มีสคริปต์ให้โหลดและรัน เอ็นจิ้นเบราว์เซอร์จะดำเนินการในระหว่างขั้นตอนการแสดงหน้าแรก การตอบสนองที่ดีขึ้น เช่นเดียวกับเมื่อโหลดเพจครั้งแรก การปรับขนาดหน้าต่างเบราว์เซอร์จะทำให้ต้องแสดงเค้าโครงในหน้านั้นอีกครั้ง อย่างไรก็ตาม ณ จุดนี้ หากเพจใช้ไลบรารี Masonry JS ก็ไม่จำเป็นต้องโหลดสคริปต์อีกครั้ง เพราะมันอยู่แล้วที่นี่. อย่างไรก็ตาม จำเป็นต้องเรียกใช้โค้ดที่ย้ายรายการในตำแหน่งที่ถูกต้อง ตอนนี้ดูเหมือนว่าไลบรารีนี้จะค่อนข้างเร็วในการดำเนินการนี้เมื่อโหลดหน้าเว็บ อย่างไรก็ตาม รายการดังกล่าวจะทำให้รายการเคลื่อนไหวเมื่อจำเป็นต้องย้ายไปยังตำแหน่งอื่นในการปรับขนาดหน้าต่าง และสิ่งนี้ทำให้เกิดความแตกต่างอย่างมาก แน่นอนว่าผู้ใช้ไม่ได้เสียเวลาปรับขนาดหน้าต่างเบราว์เซอร์มากเท่ากับนักพัฒนาของเรา แต่ประสบการณ์การปรับขนาดภาพเคลื่อนไหวนี้อาจเป็นเรื่องที่น่าสะเทือนใจและเพิ่มเวลาในการรับรู้ที่ใช้ในการปรับหน้าให้เข้ากับขนาดใหม่ ใช้งานง่ายและโค้ดที่เรียบง่ายยิ่งขึ้น ความง่ายในการใช้ฟีเจอร์บนเว็บและความเรียบง่ายของโค้ดเป็นปัจจัยสำคัญที่สามารถสร้างความแตกต่างให้กับทีมของคุณได้มาก แน่นอนว่าสิ่งเหล่านี้ไม่เคยมีความสำคัญเท่ากับประสบการณ์การใช้งานขั้นสุดท้ายของผู้ใช้ แต่ประสบการณ์ของนักพัฒนาส่งผลต่อการบำรุงรักษา การใช้คุณลักษณะเว็บในตัวมาพร้อมกับคุณประโยชน์ที่สำคัญดังนี้:
นักพัฒนาที่รู้จัก HTML, CSS และ JS อยู่แล้วมักจะสามารถใช้ฟีเจอร์นั้นได้อย่างง่ายดาย เนื่องจากได้รับการออกแบบให้ผสานรวมได้ดีและสอดคล้องกับส่วนอื่นๆ ของแพลตฟอร์มเว็บ ไม่มีความเสี่ยงที่จะเกิดการเปลี่ยนแปลงในการใช้งานคุณลักษณะนี้ แทบไม่มีความเสี่ยงเป็นศูนย์ที่ฟีเจอร์นั้นจะเลิกใช้งานหรือไม่ได้รับการบำรุงรักษา
ในกรณีของ Masonry ในตัว เนื่องจากเป็นรูปแบบดั้งเดิม คุณจึงใช้จาก CSS เช่นเดียวกับ Grid หรือ Flexbox โดยไม่มี JS เกี่ยวข้อง นอกจากนี้ คุณสมบัติ CSS ที่เกี่ยวข้องกับเลย์เอาต์อื่นๆ เช่น gap จะทำงานตามที่คุณคาดหวังไว้ ไม่มีลูกเล่นหรือวิธีแก้ปัญหาที่ต้องรู้ และสิ่งที่คุณเรียนรู้จะได้รับการบันทึกไว้ใน MDN สำหรับ Masonry JS lib การเริ่มต้นจะซับซ้อนเล็กน้อย โดยต้องใช้แอตทริบิวต์ข้อมูลที่มีไวยากรณ์เฉพาะ พร้อมด้วยองค์ประกอบ HTML ที่ซ่อนอยู่เพื่อตั้งค่าคอลัมน์และขนาดช่องว่าง นอกจากนี้ หากคุณต้องการขยายคอลัมน์ คุณต้องรวมขนาดช่องว่างด้วยตนเองเพื่อหลีกเลี่ยงปัญหา:
<สไตล์> .ติดตามขนาด .รายการ { ความกว้าง: 20%; } .gutter-sizer { ความกว้าง: 1rem; } .รายการ { ความสูง: 100px; ขอบบล็อกสิ้นสุด: 1rem; } .item: n-child (คี่) { ความสูง: 200px; } .รายการ--ความกว้าง2 { ความกว้าง: คำนวณ (40% + 1rem); }
<ระดับ div = "คอนเทนเนอร์" data-masonry='{ "itemSelector": ".item", "columnWidth": ".track-sizer", "percentPosition": true, "gutter": ".gutter-sizer" }'>
...