CSS Grid Level 3 ‘Masonry’ लेआउट के मानकीकरण के लिए WebKit ने फीडबैक मांगा

(webkit.org)

2 पॉइंट द्वारा GN⁺ 2024-04-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें

WebKit ने CSS में लंबे समय से मुश्किल रहे masonry/waterfall लेआउट को CSS Grid Level 3 में मानकीकृत करने की प्रक्रिया पर डिज़ाइनरों और डेवलपर्स से फीडबैक मांगा है
प्रस्तावित मॉडल display: grid के ऊपर grid-template-rows: masonry के जरिए rows बनाना बंद करता है और content को ईंटों की तरह खाली जगहों में भरता है
Apple का मानना है कि यह फीचर Grid के भीतर होना चाहिए ताकि fr, minmax(), max-content, spanning, explicit placement, subgrid जैसी मौजूदा Grid क्षमताओं के साथ जोड़ा जा सके
अलग display: masonry तरीका लेआउट टाइप को सरलता से अलग कर सकता है, लेकिन चर्चा के अनुसार यह एक-जैसी चौड़ाई वाले columns तक सीमित हो सकता है और Grid की track sizing क्षमता का उपयोग करना कठिन होगा
अक्टूबर 2024 अपडेट के बाद CSS Working Group ने निष्कर्ष निकाला कि variable-width tracks, explicit placement, spanning, और subgrid को masonry में शामिल करना उपयोगी है और performance के लिहाज से implement करना भी संभव है, लेकिन syntax पर चर्चा जारी है

CSS Grid Level 3 की वर्तमान स्थिति

अक्टूबर 2024 अपडेट के बाद CSS Grid Layout Module Level 3 का आधिकारिक W3C Working Draft बनाया गया और masonry लेआउट के व्यवहार को दस्तावेज़ित किया गया
CSS Working Group के सदस्यों ने निष्कर्ष निकाला कि masonry लेआउट में निम्न फीचर्स शामिल करना उपयोगी है और इन्हें performance के साथ implement किया जा सकता है
- variable-width tracks
- explicit placement
- spanning
- subgrid
हालांकि syntax को लेकर बहस अभी खुली हुई है, और WebKit इस पर अलग लेख Help us choose the syntax for Masonry in CSS में चर्चा आगे बढ़ा रहा है

masonry लेआउट की ज़रूरत क्यों है

CSS Grid Level 1 को 2017 में पेश किया गया था, जिससे float-आधारित लेआउट में size और placement का बोझ कम हुआ, और Grid Level 2 ने Subgrid दिया
लेकिन CSS Grid आने के बाद भी “masonry लेआउट को CSS में कैसे लिखा जाए” इस सवाल का 7 साल तक कोई स्पष्ट जवाब नहीं था
masonry लेआउट एक ऐसा पैटर्न है जिसमें content ईंटों या पत्थर की दीवार की तरह एक-दूसरे में फिट होकर रखा जाता है, और इसे waterfall layout भी कहा जाता है
यह अलग-अलग aspect ratio वाले content को संभाल सकता है, इसलिए हर item को एक जैसे rectangle में फिट करने के लिए crop या shrink करने की ज़रूरत कम होती है
content पूरे page में फैला रहता है, इसलिए scroll करते समय पढ़ने का क्रम स्वाभाविक बना रहता है, और नीचे lazy-load से content जोड़ते समय मौजूदा content को हिलाना नहीं पड़ता

प्रस्ताव का इतिहास और मानकीकरण पर बहस

CSS में masonry लेआउट बनाने की mechanism Mozilla ने जनवरी 2020 में पहली बार CSS Grid extension के रूप में प्रस्तावित की थी, और इसे Firefox Nightly में flag के पीछे experimental feature के रूप में implement किया गया
Apple ने 2022 में Safari Technology Preview में CSS Grid Level 3 प्रस्ताव को implement करना शुरू किया, और यह फिलहाल default रूप से enabled है
CSS Working Group के भीतर मूल दिशा को लेकर मतभेद रहे हैं
- कुछ लोगों का मानना है कि masonry, CSS Grid का हिस्सा नहीं बल्कि अलग display type होना चाहिए
- कुछ लोग आश्वस्त नहीं थे कि वेब को सच में इस लेआउट की ज़रूरत है या बड़े websites इसका उपयोग करेंगी
WebKit का मानना है कि browser इस फीचर को रिलीज़ करने से पहले CSS Working Group की सहमति ज़रूरी है

बुनियादी उपयोग: rows बंद करके सिर्फ columns वाला Grid

पारंपरिक masonry/waterfall लेआउट में main element पर display: grid लगाया जाता है, columns define की जाती हैं, और row direction में masonry value दी जाती है

main {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
  grid-template-rows: masonry;
}

grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr)) न्यूनतम 14rem चौड़ाई वाले flexible columns बार-बार बनाता है
gap: 1rem columns और items के बीच 1rem का अंतर बनाता है
grid-template-rows: masonry browser को निर्देश देता है कि rows न बनाए और content को masonry/waterfall pattern में भरे
यह उदाहरण media query या container query के बिना सिर्फ चार lines की CSS में अलग-अलग screen sizes के लिए flexible layout बनाता है
फिलहाल masonry नाम की यह value browser रिलीज़ से पहले बदल भी सकती है

Grid की column-definition क्षमता बनाए रखने की वजह

WebKit ने यह दिखाने के लिए कि masonry CSS Grid का हिस्सा होना चाहिए, चार demos बनाए हैं, जिन्हें webkit.org/demos/grid3 पर सीधे आज़माया जा सकता है
demos उन browsers में देखे जा सकते हैं जो Grid Level 3 को support करते हैं
- Safari Technology Preview
- Firefox, जब masonry grid layout feature flag enabled हो
CSS Grid columns define करने के लिए कई तरह के options देता है
- px, em, rem, cqi, lh, ch, ic, cap, vw, svh जैसी units में fixed sizes
- max-content, min-content
- fr unit
- minmax()
- % sizes
- auto
उदाहरण के लिए पहली और आख़िरी column को 14ch fixed width दी जा सकती है, और बीच की columns को न्यूनतम 28ch वाली flexible columns बनाया जा सकता है

main {
  display: grid;
  grid-template-columns: 14ch repeat(auto-fill, minmax(28ch, 1fr)) 14ch;
  grid-template-rows: masonry;
  gap: 1rem;
}

fr unit और minmax() को मिलाकर columns के अलग-अलग चरणों में फैलने और सिकुड़ने की two-stage flexibility बनाई जा सकती है
max-content और min-content column size को content के आकार के अनुसार तय करने देते हैं, जिससे content को column में फिट करने के बजाय अलग तरह की layout संभव होती है
grid-template-columns: 1fr 1fr 2fr 3fr 5fr 8fr; की तरह Fibonacci sequence का उपयोग करके अलग-अलग चौड़ाई वाले columns भी बनाए जा सकते हैं
mega menu उदाहरण grid-template-columns: repeat(auto-fill, minmax(max-content, 30ch)); का उपयोग करता है ताकि हर column इतना बड़ा हो कि link text बिना line-break के समा सके
WebKit का मानना है कि अलग display: masonry पर चर्चा आज के multicolumn layout की तरह केवल एक-जैसे size के columns की दिशा में जा रही है

Spanning, View Transitions, columnar grid

CSS Grid items को कई columns में फैलाने की सुविधा देता है, जिससे masonry placement में भी विविध visual composition संभव होती है
उदाहरण में हर पाँचवीं image को दो columns में फैलाया जा सकता है, जबकि बाकी images केवल एक column घेरती हैं
चौड़े aspect ratio वाली images को wider class देकर कई columns में फैलाया जा सकता है, और corners को square बनाना या gap को 0 करना जैसी variations भी संभव हैं
Photos demo इसे View Transitions के साथ जोड़ता है, ताकि user जब photo पर click या tap करे तो वह कई columns में फैलकर बड़ी हो जाए और browser transition को अपने आप animate करे
- इस demo के लिए Safari Technology Preview 192 या उससे ऊपर चाहिए
WebKit Grid Level 3 के मूल को किसी खास “masonry” pattern से ज़्यादा rows को बंद करने की mechanism मानता है
यह तरीका केवल columns से बना columnar grid तैयार करता है, जो CSS Grid Level 1 के उस modular grid से अलग है जिसमें rows और columns दोनों aligned होते हैं

Modular grid और columnar grid में अंतर

modular grid वह Grid है जिसमें content columns और rows दोनों के अनुसार align होता है, और CSS Grid Level 1 ऐसे layout के लिए उपयुक्त है
float-आधारित layouts में भी content height को मिलाना पड़ता था ताकि floats सही तरह clear हों, इसलिए वेब पर modular grid के उपयोग को बढ़ावा मिला
वास्तविक websites पर अक्सर images का aspect ratio समान किया जाता है, text length मिलाई जाती है, या CMS policy, CSS cropping और ellipsis के जरिए content को एक जैसे boxes में फिट किया जाता है
columnar grid में content को उसके मनचाहे आकार में रहने दिया जा सकता है, और layout content के अनुसार काम करता है
WebKit का मानना है कि text-केंद्रित content को भी ज़्यादा जीवंत ढंग से सजाया जा सकता है, जैसे latest article को चार columns में फैलाना, कुछ recent articles को दो columns में रखना, और पुराने content को एक column में रखना

Subgrid और explicit placement का संयोजन

CSS Grid Level 2 का subgrid अब ज़्यादातर browsers में support किया जाता है
museum page उदाहरण में painting card के metadata को एक ही बाएँ-संरेखित column में सूचीबद्ध करने के बजाय, subgrid के जरिए year और catalog number को हर card के दाईं ओर रखा जाता है और दूसरे cards के उसी data के साथ line up कराया जाता है
अगर masonry, CSS Grid Level 3 में शामिल होती है, तो मौजूदा developer tools का भी सीधा उपयोग किया जा सकेga
- Safari Technology Preview के Grid Inspector में grid-template-rows: masonry को आज़माया जा सकता है
अलग display type होने पर subgrid का फायदा नहीं मिलेगा
CSS Grid Level 1 की explicit placement भी साथ में इस्तेमाल की जा सकती है; उदाहरण में grid-column: -3 / -1 से header को आख़िरी दो columns के page के ऊपर दाईं ओर रखा जाता है
WebKit का कहना है कि कुछ lines के layout code से Grid Level 1, 2, 3 फीचर्स को जोड़कर ऐसा layout बनाया जा सकता है जिसमें media query या container query के बिना उपलब्ध जगह के अनुसार columns की संख्या बदलती रहे

`display: masonry` के साथ विवाद

WebKit और Apple का मानना है कि Masonry, CSS Grid का विस्तार है जो modular grid के साथ-साथ columnar grid भी बनाने देता है
इस दिशा में column definition, track spanning, explicit placement, subgrid जैसे Grid फीचर्स साथ में इस्तेमाल किए जा सकते हैं
अलग display type को पसंद करने वालों का मानना है कि इससे layout types साफ़-साफ़ अलग रहेंगे

display: block;
display: inline;
display: flexbox;
display: grid;
display: masonry;

CSS Working Group ने अलग Masonry display type की syntax पर अभी चर्चा नहीं की है, लेकिन WebKit ने multicolumn layout जैसी syntax या सीमित Grid-जैसी syntax के उदाहरण दिए हैं

main {
  display: masonry;
  columns: 28ch;
}

main {
  display: masonry;
  masonry-columns: repeat(5, minmax(28ch, 1fr));
                   /* where only one repeating width is allowed */
}

अलग layout type Grid और Masonry को लगातार साथ काम कराने के लिए ज़रूरी काम से बचा सकता है
- layout model सरल हो जाता है
- browser implementation आसान होती है
- performance pitfalls की संभावना घटती है
- Grid और Masonry के feature sets अलग हो सकते हैं
इसके उलट WebKit का मानना है कि अगर Grid layout के ये दोनों प्रकार जुड़े रहें, तो CSS Working Group भविष्य के फीचर्स को modular grid और columnar grid दोनों के लिए परिभाषित करेगा
उदाहरण के लिए अगर CSS Grid Level 4 में grid area और grid line styling, track background color, gap की rule line जैसी सुविधाएँ जुड़ें, तो बेहतर होगा कि वे शुरू से ही Grid के दोनों प्रकारों में काम करें

“Grid” को कैसे देखा जाए

अलग display: masonry का समर्थन करने वालों में कुछ लोग CSS Grid को मूल रूप से 2-dimensional alignment मानते हैं, और उनका कहना है कि masonry सिर्फ एक दिशा में align होती है, इसलिए यह Grid नहीं है
WebKit का मानना है कि graphic design के इतिहास में grid एक ऐसा tool था जो text, image, और content को नियमित pattern में व्यवस्थित करके readability और usability बेहतर बनाता था
20वीं सदी के यूरोप और अमेरिका के modernists द्वारा columns और rows दोनों में alignment को “proper” graphic design grid बताने से पहले भी कई तरह के grids इस्तेमाल होते थे
Mark Boulton ने symmetrical columnar grid को बहुत औपचारिक और उबाऊ माना, और web design में asymmetrical compound grid के उपयोग को बढ़ावा दिया
CSS Grid Level 1 ने asymmetrical grid और compound grid बनाना आसान किया, लेकिन फिलहाल यह तभी तक सीमित है जब वह Grid modular grid हो
WebKit का मानना है कि modular grid और columnar grid दोनों grid हैं, और CSS Grid में columnar grid बनाने की क्षमता भी होनी चाहिए

डेवलपर्स और डिज़ाइनरों से मांगा गया फीडबैक

WebKit ने डेवलपर्स और डिज़ाइनरों से कहा है कि वे demos खुद बनाएं, blog या social media पर अपनी राय लिखें, और CSS Working Group issues में टिप्पणी करें
फीडबैक के लिए पूछे गए सवाल ये हैं
- क्या “masonry”/“waterfall” CSS Grid का हिस्सा होना चाहिए
- क्या subgrid, spanning, explicit placement, और विभिन्न track sizing सहित columnar grid फीचर्स की ज़रूरत है
- क्या सिर्फ एक-जैसी चौड़ाई वाले columns वाला पारंपरिक masonry लेआउट पर्याप्त है
- क्या आप वास्तव में इस फीचर का उपयोग करेंगे, और इससे क्या बना सकेंगे
- क्या आपके पास बनाए गए demo के links हैं
- क्या इस मॉडल से कुछ ऐसा है जो किया नहीं जा सकता
WebKit टीम पिछले डेढ़ साल से Masonry पर काम कर रही है, और फरवरी 2023 में Safari Technology Preview 163 में इसे default रूप से enabled किया गया था
टीम इस फीचर को जल्द रिलीज़ करना चाहती है, लेकिन नाम सहित details और बुनियादी सवाल पहले सुलझने ज़रूरी हैं

नाम पर चर्चा: `masonry`, `waterfall`, `off`

WebKit का मानना है कि masonry शायद इस नई value के लिए सबसे अच्छा नाम नहीं है
CSS में नाम अक्सर center, contain, clip, wrap, smooth जैसे सरल शब्द होते हैं जो सीधे परिणाम बताते हैं
masonry एक ऐसा रूपक है जिसके लिए पृष्ठभूमि समझानी पड़ती है, इसलिए अंग्रेज़ी न बोलने वाले डेवलपर्स के लिए इसे याद रखना कठिन हो सकता है
कुछ क्षेत्रों में इस लेआउट को waterfall ज़्यादा कहा जाता है, इसलिए grid-template-rows: waterfall भी एक संभव विकल्प हो सकता है
WebKit का मानना है कि यह फीचर Pinterest-जैसे लेआउट से ज़्यादा “Grid बनाओ, लेकिन rows मत बनाओ” जैसी mechanism है
grid-template-rows: none; अर्थ के हिसाब से उपयुक्त लग सकता है, लेकिन none पहले से ही grid-template-* की default value है, जिसका मतलब “explicit rows नहीं, सिर्फ implicit rows” होता है, इसलिए इसे इस्तेमाल नहीं किया जा सकता
एक विकल्प के तौर पर grid-template-rows: off; प्रस्तावित किया गया है

main {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
  grid-template-rows: off;
}

CSSWG नाम पर इस issue में चर्चा कर रहा है
फिलहाल Safari Technology Preview और demos में Editor’s Draft के अनुसार masonry value का उपयोग हो रहा है, लेकिन भविष्य में नाम बदल सकता है

1 टिप्पणियां

GN⁺ 2024-04-24

Hacker News की रायें

पृष्ठभूमि यह है कि browser vendors के CSSWG developer relations प्रभारी लोगों ने Masonry layout को CSS में आधिकारिक तौर पर शामिल करने के तरीके पर चर्चा की है। यह चर्चा कम-से-कम 2020 से चल रही है, जब Firefox ने पहली बार इसका प्रस्ताव रखा था
इस बार की खबर यह है कि WebKit पक्ष ने इस चर्चा को सार्वजनिक रूप से सामने लाकर designers और developers से “social media पर पोस्ट करें, blog posts लिखें” जैसे action लेने का आग्रह किया है
ऊपर से यह एक औपचारिक प्रक्रिया जैसी लग सकती है, लेकिन यह एक अहम precedent बन सकती है। मुख्य मुद्दा यह है कि सभी layout options को CSS Grid का हिस्सा माना जाए, या जरूरत पड़ने पर नए CSS Display properties जोड़ते रहा जाए
पहला विकल्प पहले से जटिल CSS Grid spec को और जटिल बनाता है, और दूसरा CSS spec को नए properties और sub-properties से फुला सकता है। दोनों में से कोई भी उतना आसान नहीं है जितना दिखता है
- Masonry को Grid के ऊपर रखने में तनाव इसलिए पैदा होता है क्योंकि दोनों मूल रूप से अलग तरह से काम करते हैं
  Grid पहले सभी items को grid में place करता है, जैसे col:2,row:3, और फिर grid का size तय करता है। Masonry ideally पहले track sizes तय करना चाहता है और फिर उन tracks में items place करना चाहता है
  Firefox की पहली implementation और उस समय की spec ने मूल रूप से कहा था कि पहली row और कुछ जटिल rules को छोड़कर Masonry items को track size calculation में consider नहीं किया जाएगा, इसलिए items का tracks से overflow कर जाना बहुत आसान था
  मौजूदा spec सभी items को हर possible track में place करके देखने की मांग करती है। worst और काफी common case में O(N_tracks * N_items) की quadratic performance आती है, और quadratic performance खराब होती है[1]; दूसरे layout algorithms में असल में ऐसा कुछ नहीं है
  Nesting भी आ जाए तो performance quasi-exponential तरीके से खराब होती है, और तेज CPU होने पर भी यह अच्छा नहीं है। कहा जा सकता है कि ऐसे cases common नहीं हैं, लेकिन CSS layout modes में लोग हमेशा limits test करते हैं, इसलिए इसे मूल रूप से fast होना चाहिए
  Grid में, item किस track में रखा गया है इसके आधार पर वह अपना size अलग तरह से तय करता है, इसलिए हर possible position में place करके देखना जरूरी होता है। Masonry को इस समस्या को कम करने के लिए track size calculation में कोई अलग algorithm चाहिए हो सकता है, लेकिन blog post इस मुद्दे को पर्याप्त रूप से नहीं छूता। Grid size calculation का ऐसा version हो सकता था जिसमें item position dependency न होती, लेकिन वह ship अब निकल चुका है
  [1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...
- “बिना rows वाला” Grid मौजूदा CSS Grid spec में काफी अच्छी तरह fit बैठता है। वजह यह है कि powerful column definition properties और subgrid को reuse किया जा सकता है, और examples भी भरोसेमंद तरीके से दिखाते हैं कि ये features आपस में कितने orthogonal हैं
  आम तौर पर सिर्फ grid-row-template: masonry इस्तेमाल करने पर बाकी सब वैसे ही ठीक चलता है। यह अच्छी बात है, और मुझे लगता है कि इससे Grid layout को अभी से ज्यादा मुश्किल नहीं बनाया जाएगा
  कमी मुख्य रूप से browser engine authors के लिए है। क्योंकि “CSS Grid fully supported” का bar ऊंचा हो जाता है। यह भी कहा जाता है कि जिस implementation को Grid के सभी features support करने होंगे, उसमें कुछ Grid layouts में spec के सरल होने की तुलना में धीमा हो सकने वाले performance traps से भी बचा जा सकता है
  अगर अलग display mode हो, तो Masonry layout के लिए grid-column spec को repeat करना पड़ेगा, और यह अफसोस की बात होगी
- इस तरह की चीज community feedback के पास गई हो, यह पहली बार नहीं है। nested CSS selectors के समय भी यही तरीका अपनाया गया था, और feedback के लिहाज से यह काफी अच्छा काम किया था: https://webkit.org/blog/13607/help-choose-from-options-for-c...
- trade-offs explore करते समय शुरुआती preference पर दोबारा विचार करना पड़ सकता है
  CSS Masonry से सीधे जुड़ा नहीं है, लेकिन हाल में मैंने ऐसी ही tension वाले interface का दूसरा iteration prototype किया। मुद्दा यह था कि data model में मिलते-जुलते लेकिन अलग types बढ़ाए जाएं, या मौजूदा type के भीतर detailed nuances बढ़ाकर refinement support किया जाए
  शुरुआत में मेरी मजबूत preference दूसरे विकल्प के लिए थी, लेकिन options को सच में explore करने पर उल्टा “फूला हुआ” interface consume करना और उसके परिणामस्वरूप application code के बारे में reason करना कहीं ज्यादा सरल निकला
  CSS Masonry पर मेरी कोई strong position नहीं है, लेकिन लोगों को intuitively जो tension दिखती है और actual use में जो feel होता है, उनके बीच ऐसी ही surprise हो सकती है। CSS में खासकर “bloat”, यानी use-case-specific meanings की वृद्धि को justify करना मुश्किल होगा, लेकिन users को Grid जैसी dense API अधिक कठिन लगने की tendency भी हो सकती है
- इसे इस तरह public तरीके से आगे बढ़ाना अच्छा है। पिछले साल से मैं इसमें जुड़े सभी लोगों को लगातार push कर रहा था। Chrome पक्ष सबसे पीछे है और अभी support नहीं है। Firefox में flag support है
  पिछले साल से Firefox और Safari में test किया है और implementation से कोई शिकायत नहीं है। property की जगह और नाम को लेकर कुछ लोग बड़बड़ाते हैं, लेकिन शायद कोई perfect solution नहीं है—यह मानकर practical implementation करनी चाहिए
  fallback implementation के लिए JavaScript इस्तेमाल करना मुझे मंजूर नहीं है। इसलिए fallback तरीका बहुत सारे बदसूरत CSS के साथ आता है जो order ठीक से नहीं मिला पाता, लेकिन जिस project पर काम कर रहा हूं उसके लिए यह बड़ी समस्या नहीं है। अभी ज्यादातर लोग JavaScript से fallback देंगे, लेकिन अगर layout का solution JavaScript है, तो आप पहले ही हार रहे हैं
मेगामेन्यू डेमो <https://webkit.org/demos/grid3/megamenu/> मुझे बिल्कुल पसंद नहीं आया, और वहाँ Masonry का इस्तेमाल पूरी तरह अनुपयुक्त लगता है। यह flow direction को बिगाड़कर अपेक्षाओं को बुरी तरह तोड़ देता है
अपेक्षित reading order: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2....
वास्तविक डेमो जो order देता है: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1..... यह सही reading order और tab index को प्रभावित करता है। दृश्य उपयोगकर्ता व्यवहार में लगभग हमेशा “गलत” क्रम में पढ़ेंगे
आखिरकार यह दिखाता है कि इसमें कोई संरचना नहीं है, बस links से भरा एक असंरचित थैला है। लेकिन अगर नंबरों के क्रम में देखें तो लगता है कि काफी तार्किक क्रम था, जिसे अनुपयुक्त तरीके से Masonry बनाने के कारण पूरी तरह बिगाड़ दिया गया
स्क्रीनशॉट में “आइटम नंबर दिखाएँ” चालू किया गया है। आम तौर पर यह बिना background वाली सामान्य columns जैसा दिखता है
implementation में columns का इस्तेमाल होना चाहिए था, लेकिन हर section में break-inside: avoid जोड़ना चाहिए था। डेमो में यह छूट गया
newspaper डेमो भी मिलते-जुलते कारणों से थोड़ा संदिग्ध है, लेकिन यह बहुत छोटी समस्या है
images जैसे media की तरह, जहाँ blocks अधिक स्वतंत्र हों और reading order इतनी गहराई से जुड़ा न हो, वहाँ Masonry layout बेहतर फिट बैठता है। फिर भी tab index के आसपास कुछ अस्पष्टता रहती है, लेकिन अब यह स्पष्ट रूप से गलत नहीं रहता
- अगर इसका मतलब है कि accessibility tree और tab order असल content order को bypass करके columns को एक-एक करके traverse करते हैं, तो मैं उसे bug मानता हूँ
  Masonry layout में दृश्य उपयोगकर्ता की अपेक्षा यह नहीं होती कि columns के बीच continuity हो, बल्कि यह होती है कि visual rows के साथ क्रम आगे बढ़े। आपने जिसे “अनपेक्षित” order के रूप में पेश किया है, वह भी इसी का पालन करता है
  समस्या यह लगती है कि tab order मूल content order को अनदेखा करके visual चीज़ की नकल करने की कोशिश कर रहा है, और यह लगभग निश्चित रूप से मौजूदा implementation approach का बचा हुआ असर होगा
- सिर्फ दृश्य उपयोगकर्ताओं को देखें तो मौजूदा order उचित लगता है। आपके सुझाए तरीके में items को क्रम से देखने के लिए अक्सर ऊपर-नीचे scroll करना पड़ेगा, और अगर और items जुड़ें तो बड़ा layout shift हो सकता है
- Masonry effect चाहिए तो व्यापक रूप से supported CSS multi-column layout का इस्तेमाल क्यों नहीं?
- यह बस एक arbitrary डेमो है, और feedback इकट्ठा करने की मूल अवधारणा से इसका ज्यादा संबंध नहीं लगता
इस feature की अच्छी बात यह है कि जिन browsers में support नहीं है—यानी special flags चालू किए बिना आज के सभी stable browsers—उनमें भी डेमो देखने पर, क्योंकि इसे सीधे Grid layout के ऊपर बनाया गया है, यह काफी reasonable fixed-row format में दिखता है: https://webkit.org/demos/grid3/
हर case में proper Masonry layout होता तो यह कहीं बेहतर दिखता, लेकिन उसके बिना भी काफी usable है। पसंद न आए तो feature detection करके बेहतर fallback display भी दिया जा सकता है
Masonry/waterfall layout का overall look and feel सच में अच्छा है। शायद इसलिए कि मैं कागज़ के अखबार पढ़ते हुए बड़ा हुआ हूँ और अब भी पढ़ता हूँ, column-based layouts पेज को बाँटने का intuitive तरीका लगते हैं
हालांकि default Masonry alignment का कोई alternative हो तो अच्छा होगा। जहाँ तक मुझे पता है, basic rule कुछ ऐसा है: “अगला item उस column में रखें जहाँ वह सबसे ऊपर fit हो सके”, और इसकी वजह से दूसरी row से left-right order काफी गड़बड़ा जाता है
मैं जिस बेहतर तरीके की कल्पना करता हूँ, वह ऐसा layout है जो left→right, या preferred direction right→left हो तो उस reading flow को ज्यादा preserve करे। उदाहरण के लिए: “अगला item पिछले item के right column में रखें, लेकिन अगर वह पहले से सबसे right में है तो सबसे left में रखें, और अगर नया bottom left column की lower boundary से बहुत नीचे नहीं जाता, तो उसी column में दूसरा item रखा जा सकता है”
यह strict left→right से ज्यादा flexible होगा, alignment को भी कम बिगाड़ेगा, और left→right reading direction का अर्थ भी कुछ हद तक बनाए रख सकेगा
Masonry में पसंद किए जा सकने वाले हर formula को support नहीं किया जा सकता, लेकिन अगर content में order थोड़ा भी मायने रखता है—Pinterest भले न हो, पर journal जैसे cases में—तो मुझे लगता है कि ऐसा तरीका classic Masonry rule की तुलना में अधिक reasonable default होगा
- मैं Masonry layout का इस्तेमाल सिर्फ उन चीज़ों के लिए करूँगा जिनमें शुरू से ही कोई clear order न हो। समय-क्रम में sorted images के लिए शायद नहीं करूँगा
- समस्या left→right alignment खुद है। इस layout में इधर-उधर jump किए बिना left→right align करने का तरीका लगभग नहीं दिखता
  magazine-style layout हो तो क्या पहले columns को top→bottom पढ़ते हैं, फिर left→right नहीं? CSS में यह पहले से columns या vertical-direction Flexbox से संभव है
  इस Masonry layout की एक और समस्या यह है कि नीचे का हिस्सा uneven होता है। magazine में शायद इसे बराबर align किया जाता, और यह भी columns या Flexbox से किया जा सकता है
  web में शायद endless scrolling content की छिपी हुई assumption है, इसलिए page के bottom का shape महत्वपूर्ण नहीं माना जाता। अगर ऐसा है, तो यह assumption जरूरी नहीं कि encourage करने लायक हो
- ऐसा कुछ कैसा रहेगा:
  { /* update के समय elements को left या right में अधिकतम 2 columns तक ही move करें */ grid-template-max-horizontal-shift: 2 col; }
अगर मान लें कि हम CSS की जगह एक बैकवर्ड-कम्पैटिबिलिटी-रहित सिस्टम बना सकते हैं, तो हमें क्या करना चाहिए?
क्या एक सुसंगत लेआउट सिस्टम बनाने के तरीकों पर कोई किताब या पेपर है?
Qt, Tk, SwiftUI जैसे विकल्प कैसे हैं? CSS के अलावा मैंने कुछ इस्तेमाल नहीं किया है। अगर वास्तव में व्यापक रूप से लागू सिस्टमों में कोई बेहतर है, तो वह किस वजह से बेहतर है?
मैं ऐसा सिस्टम चाहता हूँ जो developers को बेहतर interface दे, लेकिन समझ नहीं आता कैसे। अगर शुरू से फिर से शुरू कर सकते, तो design principles क्या होने चाहिए?
- मैं खास तौर पर anti-CSS नहीं हूँ, लेकिन size groups, predictable size request-allocation cycle, ऊँचाई के आधार पर चौड़ाई, constraints और alignment-based layout जैसे concepts में रुचि हो सकती है। और CSS में non-orthogonal तरीके से उलझे हुए concepts की गड़बड़ी को कुल मिलाकर साफ करना होगा
  properties ज़्यादा explicit और अलग-अलग होनी चाहिए। negative margins जैसी बकवास चीजें हटानी चाहिए, और सभी distances को multi-stage बनाना चाहिए। उदाहरण के लिए padding = max(el.paddings[]) जैसा
  boundary boxes को explicit बनाना चाहिए, और borders को ठीक-ठाक elements बनाना चाहिए। box model अपने-आप में खराब नहीं है; CSS ने उसका implementation भयानक किया है। यह ऐसे नाज़ुक spells और अजीब limits से भरा है कि छूते ही 99% चीजें टूट जाती हैं, और वे limits और समस्याएँ व “solutions” पैदा करती हैं
- Cassowary algorithm इस्तेमाल करने वाला constraint-based layout कुछ समय तक एक लोकप्रिय विकल्प जैसा दिखता था: https://github.com/slightlyoff/cassowary.js/?tab=readme-ov-f...
  इसे screen size और shape में बदलावों को solve करने के लिए design किया गया था। Apple SwiftUI पर चला गया है और शायद इस approach से आगे बढ़ चुका है
- अलग-अलग styling/layout systems की तुलना करने वाला कोई लेख हो तो वाकई दिलचस्प होगा। हालांकि कई styling languages का अनुभव रखने वाले लोग ज़्यादा नहीं हैं, इसलिए ऐसा लिख सकने वाले लोग भी शायद कम होंगे
  Flutter और XAML भी देखने लायक candidates लगते हैं
- reference के लिए prior art चुनते समय ध्यान देने वाली बात यह है कि CSS declarative control का standard काफी ऊँचा सेट करता है। जिन चीजों का ज़िक्र हुआ है उनके बारे में detail में नहीं कह सकता, लेकिन ज़्यादा comparable prior art शायद printing-side use cases में मिल सकता है
- इस विषय की classic किताब के तौर पर "Rastersysteme für die visuelle Gestaltung - Grid systems in Graphic Design" लगती है। मैंने पढ़ी नहीं है
बेहतर visibility के लिए इसे top-level comment के रूप में फिर से पोस्ट कर रहा हूँ
मेरी एक photography website है, और layout के लिए JavaScript इस्तेमाल नहीं करता। बनाते समय JavaScript Masonry libraries देखी थीं, लेकिन नतीजे संतोषजनक नहीं थे
असल में उपलब्ध सारी जगह भरने वाला सही Masonry layout कुछ images को crop करता है। crop किए बिना aspect ratio बनाए रखना हो तो photos के आसपास खाली जगह छोड़नी पड़ती है। ऐसा न करने का इकलौता तरीका infinite scroll है, जो शायद corporate addiction machines को चाहिए, लेकिन मेरी website में मुझे यह नहीं चाहिए
मैंने इसे ऐसे बनाया:
https://yakubin.com/photography/albumless/
https://yakubin.com/photography/album/kenya-2023/
यह result पाने के लिए मैंने display:inline-block इस्तेमाल किया, यानी photos को ऐसे treat किया जैसे text जो नई line में reflow होना चाहिए। नतीजे से बहुत खुश हूँ और Masonry libraries जिस तरह करती हैं उससे इसे पसंद करता हूँ
- यह layout शायद कुछ lines CSS में row-direction Flexbox से implement हो सकता था, जो wrap होकर center-align होता है। वही ज़्यादा standard तरीका भी है
- Masonry layout के लिए JavaScript इस्तेमाल नहीं करता। मौजूदा Masonry CSS solution में supported CSS solution को fallback display के रूप में रखता हूँ
  समस्या order है। अगर order important नहीं है तो current CSS-only solution भी अच्छे से काम करता है। हालांकि याद है कि columns के नीचे अजीब shape बच सकती है
- इस तरह के layout के लिए Flexbox ही design किया गया था, इसलिए यहाँ भी यह एक option हो सकता है
संबंधित रूप से, मैंने Grid principles को cover करने वाला interactive demo बनाया है:
https://cssprinciples.com/3/grid/
मौजूदा float है और आधुनिक Flexbox व Grid लेआउट भी हैं, फिर भी CSS में “लेआउट” विकल्प लगातार जोड़ते रहना सही है या नहीं, यह सोचने वाली बात है
अगर अब भी ऐसे मामले हैं जो कवर नहीं होते, तो जटिलता बढ़ने के बावजूद सभी लेआउट मामलों को कवर करने वाला एक अंतिम constraint-based system रखना बेहतर समाधान हो सकता है। तब CSS framework और utility library उसके ऊपर अगली पीढ़ी के Masonry Grid वगैरह बना सकते हैं
- इस बात पर संदेह है कि constraint system पर सच में विचार किया जाएगा। CSS ने अब तक layout cost की predictability को मजबूत लक्ष्य बनाया है
  फिर भी Houdini layout proposal इस विचार के सबसे करीब है। यह layout को isolated JavaScript context में सौंपने का तरीका है: https://github.com/w3c/css-houdini-drafts/blob/main/css-layo...
  लेकिन ईमानदारी से कहें तो Flexbox और Grid, और containment जैसी चीज़ों ने पहले ही कई समस्याएँ हल कर दी हैं, इसलिए Flexbox से पहले वाले दौर की तुलना में सुधार की माँग काफी कम हो गई है
- इस पहल का मुख्य मतलब पुराने float hacks या जल्द पुराने पड़ने वाले CSS Grid/Flexbox hacks का इस्तेमाल बंद करना है। Firefox का Masonry layout असल में Grid rows को collapse करने वाली एक नई property जोड़ने के तरीके से है, इसलिए व्यवहार में इसे लगभग सभी layout cases को कवर करने के अंदाज़ में implement किया गया है
- यह Grid Level 3 है। ऐसा कर सकते हैं:
  display: grid;
  grid-template-rows: masonry;
  हालांकि यह WebKit तक सीमित है। मैंने इसे अपने personal news feed के gallery mode में implement किया था, लेकिन अक्टूबर 2023 में ही हटा दिया
- JavaScript ही ultimate layout system है। कोई भी declarative language सभी use cases संभाल नहीं सकती। सौभाग्य से Grid आने के बाद JavaScript पर निर्भर होने की जरूरत कम ही पड़ती है
  constraint-based system शायद Grid और JavaScript के बीच कहीं awkward तरीके से अटक जाएगा, इसलिए पता नहीं वह कितनी मदद करेगा
- अगर CSS layout किसी requirement को सीधे support नहीं करता, तो कभी भी JavaScript से layout generate किया जा सकता है
मैं पहले से इसका इस्तेमाल कर रहा हूँ। Firefox में option से enable करके bookmarks में use करता हूँ। Mobile पर यह बस ऊपर-नीचे stack हो जाता है, इसलिए समस्या नहीं होती। Mobile में about:config नहीं है
आखिरी image off वाली स्थिति में है
https://imgur.com/a/o7OyZEW
- मेरी समझ के हिसाब से Masonry layout rule row के हिसाब से पहले सबसे ऊँची खाली जगह भरता है, इसलिए irregular alignment बनती है। लेकिन visually यह columns में aligned जैसा दिखता है
  इसलिए window size बदलने पर bookmarks का क्रम बदल जाएगा
- Mobile पर Firefox Beta आज़माएँ :)
और background व दूसरी तरफ की दलील—यानी display:grid + grid-template-rows: masonry की तुलना में display: masonry बेहतर है—इस पर चर्चा यहाँ विस्तार से देख सकते हैं: https://github.com/w3c/csswg-drafts/issues/9041

CSS Grid Level 3 ‘Masonry’ लेआउट के मानकीकरण के लिए WebKit ने फीडबैक मांगा

CSS Grid Level 3 की वर्तमान स्थिति

masonry लेआउट की ज़रूरत क्यों है

प्रस्ताव का इतिहास और मानकीकरण पर बहस

बुनियादी उपयोग: rows बंद करके सिर्फ columns वाला Grid

Grid की column-definition क्षमता बनाए रखने की वजह

Spanning, View Transitions, columnar grid

Modular grid और columnar grid में अंतर

Subgrid और explicit placement का संयोजन

display: masonry के साथ विवाद

“Grid” को कैसे देखा जाए

डेवलपर्स और डिज़ाइनरों से मांगा गया फीडबैक

नाम पर चर्चा: masonry, waterfall, off

संबंधित पढ़ाई

1 टिप्पणियां

Hacker News की रायें

`display: masonry` के साथ विवाद

नाम पर चर्चा: `masonry`, `waterfall`, `off`