CSS: वे बुरे हिस्से जिनसे बचा नहीं जा सकता

 (matklad.github.io)
2 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • वेबपेज styling के लिए साधारण ब्लॉग या GUI में सीखने लायक एक छोटा subset काफी हो सकता है, लेकिन browser defaults और layout जैसी मुश्किलें कई दिनों की debugging तक ले जा सकती हैं
  • अगर पहले अर्थपूर्ण HTML5 tags इस्तेमाल किए जाएँ और wrappers कम रखे जाएँ, तो CSS को मौजूदा markup के अनुसार काम करवाना आसान हो जाता है
  • CSS layout के लिए कोई सार्वभौमिक single algorithm नहीं है, इसलिए यह समझने वाला दृष्टिकोण चाहिए कि हर system किस तरह की placement की अनुमति देता है
  • box-sizing, margin, font-size, line-height, word-break अक्सर intuition के विपरीत काम करते हैं, इसलिए छोटे बदलाव भी पूरे layout या readability की समस्या बन सकते हैं
  • साधारण pages के लिए CSS reset, classless CSS, flexbox, और बहुत ज़्यादा न होने वाले responsive rules एक व्यावहारिक शुरुआत हो सकते हैं

CSS सीखने की सीमा और बुनियादी नज़रिया

  • CSS, HTML, Web API बहुत विशाल हैं और इनमें विशेषज्ञता की ज़रूरत पड़ती है, लेकिन programming blog या साधारण GUI जैसे कामों के लिए आधुनिक web का एक उपयुक्त subset काफी है
  • साधारण कामों के लिए ज़रूरी subset ही सिखाने वाली सामग्री लेखक को नहीं मिली, लेकिन MDN का अनुसरण करते हुए कुछ हद तक समझा जा सकता है
  • समस्या यह है कि जिन pitfalls के होने की उम्मीद नहीं होती, वे page को बिगाड़ सकते हैं और कारण ढूँढने में कई दिन लग सकते हैं
  • इस साइट की styling लगभग 200 lines of readable CSS से बनी है

अच्छे हिस्से: अर्थपूर्ण HTML और classless CSS

  • HTML5 semantic tags

    • MDN की Elements Reference देखना उपयोगी है, और HTML elements की संख्या बहुत ज़्यादा नहीं है
    • main, article, nav, kbd जैसे tags page structure को आसान बना सकते हैं
    • ul को हर तरह की list के लिए इस्तेमाल किया जा सकता है, जैसे header > nav के अंदर site sections
    • details का उपयोग table of contents के लिए किया जा सकता है, और MDN source देखा जा सकता है
    • dl और dt को paired lists के लिए इस्तेमाल किया जा सकता है

  • wrappers कम करने का तरीका

    • असली websites के source को देखने पर कई परतों वाले wrapper elements दिखाई देते हैं, जिससे लग सकता है कि layout समस्याएँ wrappers से हल की जाती हैं
    • production CSS के अनुभव पर अंतिम राय रोके रखते हुए, लेखक को यह तरीका ज़्यादा समझने योग्य लगा कि खुद को सिर्फ अर्थपूर्ण semantic tags तक सीमित किया जाए और फिर उसी markup के अनुकूल CSS ढूँढी जाए

  • Classless CSS

    • styles को पूरी तरह तटस्थ “कुछ भी नहीं” वाली स्थिति में reset नहीं किया जा सकता; सफेद या transparent text भी एक style ही है
    • reset के बाद common HTML elements को सीधे style करना संभव है
    • main, header, footer, nav tags का उपयोग करने पर बहुत सारे CSS selectors लिखे बिना पूरे page layout को सेट किया जा सकता है
    • यह तरीका CSS को HTML structure मान लेने पर मजबूर करता है, लेकिन अगर HTML और CSS दोनों आपके अपने हैं, तो नतीजा पसंद न आने पर बदला जा सकता है

बुरे हिस्से: layout, browser defaults, selectors

  • layout

    • layout की समस्या सिर्फ web की नहीं है; यह कई GUI frameworks में भी कठिन समस्या है
    • fixed-size raster images और उन्हें समझाने वाले text paragraphs को screen rectangle में रखने के कई तरीके हो सकते हैं
    • सामान्य GUI कई ऐसे boxes की hierarchy होती है जिनमें “layout freedom” बहुत होती है
    • हर box का layout बाकी सभी boxes के layout को प्रभावित करता है, और आम तौर पर सभी boxes को spacing या overlap के बिना ठीक-ठीक फिट होना चाहिए
    • कोई universal single layout algorithm नहीं है; RectCut से लेकर constraint solvers और उनके बीच के क्षेत्र तक, हर system अलग heuristic इस्तेमाल करता है
    • “इस system में layout कैसे बनाया जाए?” से बेहतर सवाल अक्सर यह होता है: “यह system किस तरह के layouts की अनुमति देता है?”

  • browser defaults और CSS reset

    • CSS के बिना भी अर्थपूर्ण HTML पर browser में color, font, size, बड़े headings, underlined links जैसी default styles लागू होती हैं
    • default styles मददगार हैं, लेकिन browsers के बीच अलग होती हैं; जिन defaults को आपने लिखा ही नहीं, उन पर निर्भर रहने से दूसरे browsers में अलग नतीजे मिल सकते हैं
    • सामान्य समाधान CSS reset या normalization है, जिसमें CSS की शुरुआत में explicit rules से defaults को override किया जाता है
    • defaults अपने आप में बुरे नहीं हैं; समस्या यह है कि वे आपस में consistent नहीं हैं
    • व्यवहार में किन rules को override करना चाहिए, यह समझने के लिए कई मौजूदा CSS resets की तुलना करना बेहतर है

  • क्या web pages को style करना चाहिए?

    • web platform में एक नज़रिया इसे लचीला और अनुकूलनशील visual medium मानता है, जबकि दूसरा नज़रिया content delivery पर ज़ोर देता है और मानता है कि users को presentation customize कर सकना चाहिए
    • default styling वाला page भी अक्सर कम usable और कम आकर्षक होता है
    • CSS रहित pages अगर अपने आप पढ़ने में आसान होते तो दुनिया बेहतर होती, लेकिन मौजूदा स्थिति में content पर style लागू करना उपयोगी है
    • advanced users को अपना CSS लाने की अनुमति देना अच्छा है
    • HTML markup उचित होना चाहिए, HTML को CSS के लिए overfit नहीं करना चाहिए, और page को reader mode में काम करना चाहिए

  • CSS selectors

    • बुनियादी CSS शक्तिशाली inheritance की तरह काम करता है, जहाँ page का हर design element कई rules से प्रभावित होता है
    • CSS file में जोड़कर मौजूदा elements को कभी भी “monkey patch” किया जा सकता है
    • लेखक selectors को ऐसी abstraction मानता है जो गलत axis पर शक्ति जोड़ती है, और इस कारण classless CSS तथा inline style वाला तरीका संभव मानता है
    • Tailwind जैसे tools inline लिखने की असुविधा घटा सकते हैं, और JSX या composition को support करने वाले template engines HTML repetition कम कर सकते हैं
    • CSS nesting का उपयोग करके दूर तक फैलने वाले selectors घटाए जा सकते हैं और component स्तर पर styling की जा सकती है

box model और placement: box-sizing, margin, default flow, flexbox

  • box-sizing

    • UI पुनरावर्ती rectangles से बना होता है, और layout तय करने की प्रक्रिया है कि हर rectangle कहाँ रखा जाए
    • HTML defaults में किसी element की width और height में border और padding शामिल नहीं होते, जो intuitive नहीं है
    • किसी एक जगह padding बढ़ाने से पहले पूरी तरह सही दिख रहा layout अचानक अनपेक्षित रूप से खिसक सकता है
    • * { box-sizing: border-box; } CSS reset की पहली line होने लायक है, क्योंकि यह border जोड़ने को local change बना देता है

  • margin collapsing

    • अगर किसी element के चारों ओर 8px spacing चाहिए, तो padding इस्तेमाल करने पर दो पड़ोसी elements के बीच 16px spacing हो सकती है
    • margin इस तरह काम करता है कि दो पड़ोसी margins को जोड़ा नहीं जाता, बल्कि max के रूप में मिलाया जाता है
    • margin collapsing बहुत उपयोगी है, लेकिन यह चौंकाने वाला behavior पैदा कर सकता है
    • लेखक इसे ऐसे समझता है कि child margin parent के बाहर निकल सकता है, लेकिन margin की intuitive समझ अभी भी अधूरी है
    • Julia Evans का लेख Moving away from Tailwind, and learning to structure my CSS इस owl selector तरीके पर चर्चा करता है, जिसमें सामान्य रूप से खुद element को margin देने के बजाय parent children के बीच margin नियंत्रित करता है
    • section के पहले child को छोड़कर बाकी सभी children पर margin जोड़ने का तरीका margin समस्याएँ घटाने का एक विचार माना गया है
    • यह असुविधाजनक है कि ऐसी जानकारी तब तक सीखना कठिन है जब तक कोई पेशेवर web developer न बने या किसी और CSS framework को reverse engineer न करे

  • default flow layout

    • default layout algorithm HTML की document language के रूप में उत्पत्ति से जुड़ा है, और लगता है कि यह text तथा चित्र-केंद्रित कागज़ी documents बनाने के मामलों के लिए अनुकूलित था
    • body text के लिए default flow वास्तव में काफ़ी हद तक वैसा काम करता है जैसा चाहिए
    • page elements की spatial placement को सीधे नियंत्रित करने के लिए default flow से अलग तरीका चाहिए

  • flexbox

    • flexbox ऐसा layout है जो elements की एक श्रृंखला को vertical या horizontal दिशा में रखता है और उपलब्ध जगह के अनुसार उन्हें adapt कराता है
    • पहले “यह बाईं ओर, यह दाईं ओर” जैसी placement के लिए भी गहरी CSS knowledge या कोई अपारदर्शी CSS framework चाहिए होता था
    • flexbox काफ़ी जटिल है, इसलिए MDN बार-बार देखना पड़ता है, लेकिन आम तौर पर इससे इच्छित काम पूरा हो जाता है

  • responsive design

    • आधुनिक CSS screen size को query कर सकता है और user agent constraints के आधार पर conditional logic लागू कर सकता है
    • HTML स्वभाव से ही responsive है; PostScript या PDF के विपरीत, window size बदलने पर paragraphs अपने आप reflow हो जाते हैं
    • explicit responsive rules से बचना और layout को अपने आप उचित व्यवहार करने देना अच्छा है
    • यह blog बिना explicit @media queries के mobile, tablet, और desktop पर ठीक दिखता है
    • body text के main column पर बस max-width तय कर देना ही काफी हो सकता है

size और text: pixels, fonts, line height, line breaks

  • pixels

    • 1px वह काम करता है जिसकी ज़रूरत होती है, लेकिन इसका मतलब screen का एक physical pixel नहीं है
    • CSS का 1px visual angle की इकाई है, जिसे इस तरह बनाया गया है कि यह किसी भी screen पर perceptually समान लगे
    • screen size, pixel density, और सामान्य viewing distance के अनुसार यह अलग-अलग संख्या में physical pixels में बदलता है
    • इसलिए अलग-अलग displays की pixel density को अलग से सोचे बिना भी सभी sizes pixels में दी जा सकती हैं
    • CSS की centimeter और inch जैसी “वास्तविक” units भी pixel के आधार पर परिभाषित होती हैं, इसलिए वे भी angle की तरह काम करती हैं

  • font-size

    • font-size: 16px में 16px किसी खास glyph का size नहीं, बल्कि glyph के आसपास के virtual box का size है
    • यह box glyph पर कसकर फिट नहीं बैठता, और वास्तविक glyph size font के अनुसार बदलता है
    • font-size-adjust अलग-अलग fonts के बीच font-size को अधिक consistent बना सकता है
    • फिलहाल font-size-adjust बहुत niche feature जैसा लगता है; व्यक्तिगत रूप से लेखक box-sizing के साथ font-size-adjust: ex-height 0.53; रखना चाहेगा, लेकिन ऐसा करने वाले pages कम हैं
    • font-size defaults browsers के बीच काफ़ी consistent हैं, और 16px भारी बहुमत वाला default है
    • font के अनुसार 16px छोटा लग सकता है, और कुछ default fonts खासकर छोटे दिखते हैं
    • Apple पर font-family: serif , sans-serif की तुलना में बहुत छोटा दिखता है, और 16px पर लगभग पढ़ने में असुविधाजनक हो जाता है
    • CSS में font-size सेट करने से browser की default font size बदलने की व्यवस्था निष्क्रिय हो जाती है
    • यह मानकर नहीं चलना चाहिए कि text अपने आप पढ़ने लायक होगा; अलग settings में जाँच करना चाहिए
    • अगर font-size-adjust से freedom घटाकर font-size का अर्थ स्थिर कर दिया जाए, और default 16px font size पर सब ठीक लगे, तो काम पूरा माना जा सकता है
    • अगर ऐसा नहीं है, तो font-size को बड़े मान पर सेट करना चाहिए, और फिर यह भी देखना चाहिए कि reader mode में पढ़ना आसान रहे

  • line-height

    • नाम के विपरीत, line-height किसी line की height सेट नहीं करता
    • line-height उसी font में सेट किए गए glyphs के एक समूह की height है
    • जब सारा text एक ही font में हो, तब line height और glyph group height एक जैसे होते हैं
    • अगर कुछ शब्द monospace font में सेट हों, तो परिणाम अपेक्षा से अलग हो सकते हैं
    • font-size-adjust box के भीतर glyph size को ठीक करता है, लेकिन उनकी relative position तय नहीं करता
    • जब अलग-अलग fonts के text groups को baseline साझा करने के लिए vertically align किया जाता है, तो उनके line-height line-box आपस में खिसक जाते हैं
    • पूरी line की height संघ जैसी बन सकती है और अपेक्षा से बड़ी हो सकती है
    • इस प्रभाव पर Deep dive CSS: font metrics, line-height and vertical-align में विस्तार से चर्चा है

  • vertical rhythm

    • vertical rhythm वह विचार है जिसमें headings, images आदि होने पर भी paragraphs के बीच lines एक ही relative position पर रहें
    • इसे ऐसे समझाया जाता है जैसे webpage के पीछे अदृश्य ruled lines हों
    • single-column layout में लेखक को यह उपयोगी नहीं लगता
    • two-column layout में दोनों तरफ की lines मिलाने की इच्छा हो सकती है
    • single column में इसके लिए जटिल मेहनत करना उचित नहीं लगता

  • word-break

    • flow layout की खूबी यह है कि window संकरी होने पर text साफ़ तौर पर नई lines में टूट जाता है
    • lines सिर्फ spaces या hyphen insertion points पर ही टूट सकती हैं
    • inline code या URL जैसे लंबे हिस्से नहीं टूटते
    • यह समस्या mobile devices पर horizontal overflow पैदा करती है, और आम तौर पर post प्रकाशित होने के बाद ही पता चलती है
    • इसे ठीक करने का कोई एक जादुई उपाय नहीं है, लेकिन Against Horizontal Scroll में कुछ tips दी गई हैं

व्यावहारिक निष्कर्ष

  • साधारण blog बनाने के लिए ऐसी सामग्री चाहिए जो HTML और CSS के सिर्फ पर्याप्त हिस्से को संक्षेप में समझाए
  • निष्कर्ष एक ऐसी लगभग 100-page छोटी किताब की माँग के साथ खत्म होता है, जो margin collapsing जैसी समस्याओं में फँसे बिना साधारण blog बनाने लायक HTML और CSS समझाए

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Lobste.rs की राय

  • छोटी-सी आपत्ति है, लेकिन responsive design की परिभाषा है: “ऐसा डिज़ाइन जो अलग-अलग डिवाइसों और विंडो/स्क्रीन आकारों पर अच्छी तरह render हो, ताकि usability और user satisfaction सुनिश्चित हो।”
    media queries या container queries इसे लागू करने के कई टूल्स में से सिर्फ़ एक हैं, और responsive design “हर चीज़ के लिए media query लिखो” से ज़्यादा एक सोच के क़रीब है।
    इसलिए “बुरी चीज़” responsive design ख़ुद नहीं, बल्कि media queries या breakpoints के overuse को कहना ज़्यादा सही लगता है।

  • “Browser defaults” वाला हिस्सा काफ़ी भ्रम पैदा करता है। reset stylesheet और normalize stylesheet का उद्देश्य और व्यवहार बहुत अलग है, लेकिन लेख में दोनों को मिलाकर पेश किया गया है।
    reset का मक़सद browser के बीच के फ़र्क मिटाना कम, और elements के बीच के default फ़र्क हटाना ज़्यादा है—जैसे ol का padding-inline-start या button का default appearance हटाना—ताकि आप user agent stylesheet के ऊपर नहीं, बल्कि एक खाली slate से styling शुरू कर सकें।
    normalize, इसके उलट, user agent stylesheet के साथ सहयोग करने वाला approach है; इसमें browser के बीच फ़र्क बराबर करने वाली चीज़ें भी हैं और ऐसे defaults भी जिन्हें “ज़्यादा reasonable” माना गया है।
    आजकल browser defaults में meaningful फ़र्क बहुत कम बचे हैं, इसलिए सामान्य web content लिखने वाले लोग इन्हें लगभग नज़रअंदाज़ कर सकते हैं। अपवाद के तौर पर Chromium has the wrong table border-color, WebKit fixed theirs 1½ years ago, कुछ form elements की margin/size differences, appearance, और WebKit में <summary> ::marker styling जैसी चीज़ें बची हैं।
    मैं box-sizing: border-box के भी ख़िलाफ़ हूँ। border-box layout-केंद्रित है, जबकि content-box content-केंद्रित, इसलिए parent को layout संभालने देना और content के हिसाब से design करना बेहतर लगता है। ratios के साथ काम करते समय content-box ज़रूरी होता है, और border-box वाक़ई उपयोगी मुख्यतः तब है जब body को viewport तक भरना हो।
    font-size-adjust को लेकर भी संदेह है। यह एक अच्छी तरह समझी हुई समस्या को कम-परखी हुई दूसरी समस्या से बदल देता है; कुछ लोगों के लिए थोड़ा बेहतर, और कुछ के लिए थोड़ा बदतर हो सकता है। मूल समस्या हल नहीं होती, और user के font ratios व metrics के बारे में बिना आधार के मान्यताएँ बनानी पड़ती हैं।
    line-height और “same font में set करना” जैसी भाषा भी काफ़ी सटीक नहीं है। असल में font size, language switching, font-family: monospace, vertical-align, <sup>, <sub>, और font metrics सब आपस में जुड़े होते हैं, इसलिए इसे सिर्फ़ same font की समस्या कहना सही नहीं।
    margin collapsing लेख में बताए गए से ज़्यादा जटिल है, लेकिन काफ़ी उपयोगी भी है। सामान्य content में flex या grid इस्तेमाल करने पर gap या margins को बार-बार छेड़ना पड़ता है, जिससे चीज़ें fragile हो सकती हैं। display: flow-root इस्तेमाल करने से child margins का parent margins के साथ collapse होना रोका जा सकता है।
    responsive design पर बड़े ढाँचे वाली बात से मैं सहमत नहीं हूँ, लेकिन अनावश्यक media queries घटाना और browser से लड़ाई न करना सही दिशा है। अगर layout changes को content के आधार पर व्यक्त किया जा सके, तो आमतौर पर वही बेहतर होता है।
    हाल में viewport units का इस्तेमाल करते हुए clamp linear interpolation बहुत कर रहा हूँ: margin-inline: --vw-lerp(1rem at 20rem, 2.5rem at 60rem); को margin-inline: clamp(1rem,1rem + ((2.5 - 1)/(60 - 20)*(100vw - 20rem)),2.5rem); में expand करने जैसा।
    पिछले साल मैंने इसे implemented this as a LightningCSS visitor के रूप में लागू किया था, और इससे viewport 20rem या उससे कम होने पर 1rem रहता है, 60rem तक आते-आते 2.5rem तक smoothly बढ़ता है, फिर रुक जाता है—यानि breakpoints के बिना user font size के साथ भी अच्छी तरह adapt करता है।

    • मुझे यक़ीन नहीं कि font-size-adjust वाक़ई ऐसे ही काम करता है। नाम थोड़ा भ्रामक है, लेकिन मेरी समझ यह है कि font-size em box का size बदलता है, जबकि font-size-adjust em box के भीतर glyph size बदलता है।
      इसलिए em और rem वैसे ही रहते हैं, लेकिन ch बदलता है। और ch तो मूल रूप से font-dependent है, इसलिए उसका बदलना ठीक ही है।
      काश इस पर कोई font-size-adjust के बारे में लेख लिखे। मैं expert नहीं हूँ इसलिए भरोसा कम है, लेकिन अभी तक यह लगभग अनजानी चीज़ होते हुए भी बहुत बड़ा सुधार लगती है। कोई भी दो fonts हर context में अपने-आप perfectly match नहीं हो सकते, लेकिन em box की बजाय x का size match करना ही fonts/context के 90% मामलों को cover कर देता है।

  • लेख का इरादा अच्छा है, और HTML/CSS में पूरी तरह डूबे न रहने वाले लोगों का नज़रिया भी महत्वपूर्ण है, लेकिन इनमें से काफ़ी-सी “बुरी चीज़ें” context के हिसाब से अच्छी भी हो सकती हैं।
    CSS selectors का overuse आसान है, लेकिन वे अपने-आप में बुरे नहीं हैं। A या B में नतीजा निकालने की बजाय, आप सामान्य rules/selectors रख सकते हैं और ज़रूरत पड़ने पर exception-based classes या utility classes छिड़क सकते हैं।
    लेख में selectors का एक अच्छा उदाहरण भी है:

    section > *+* {  
  margin-top: 1rem;  
}

    media queries भी ज़रूरी न हों अगर उन्हें container queries से हल किया जा सके।
    CSS का surface area बहुत बड़ा महसूस हो सकता है, लेकिन जितना यह व्यापक रूप से इस्तेमाल होता है और जितना कुछ कर सकता है, उतने ही मतभेद भी स्वाभाविक हैं। फिर भी, यह भी देखना चाहिए कि CSS कितना आगे बढ़ चुका है, और concepts समझ लेने पर अपेक्षाकृत कम code में कितना कुछ किया जा सकता है।
    अगर और सीखना हो, तो https://every-layout.dev/ ने CSS में अलग-अलग हिस्से कैसे एक-दूसरे से जुड़ते हैं, यह समझने में काफ़ी मदद की।

    • Every Layout की सिफ़ारिश के पक्ष में मेरी भी एक वोट। अभी भी मुझे CSS पसंद नहीं है, और निजी तौर पर मुझे लगता है कि cascade एक layout model के रूप में बुनियादी तौर पर कमज़ोर है, लेकिन अब कम-से-कम desktop और mobile पर चीज़ों को ज़्यादातर ठीक-ठाक और responsive दिखाना संभव है।
      web layout मुझे तब समझ आना शुरू हुआ जब एहसास हुआ कि अच्छे websites मूल रूप से vertical design होते हैं। elements को डिफ़ॉल्ट रूप से ऊपर-नीचे stack होना चाहिए, और mobile screen को पहले design करके बड़े screens पर उसे bonus की तरह फैलाना चाहिए।

  • इस दावे से सहमत होना मुश्किल है। CSS nesting सिर्फ syntactic sugar है, और यह जरूरत से ज़्यादा specific selectors की समस्या से कोई सार्थक बचाव नहीं करता
    15 साल पहले भी Sass में selector nesting का बहुत इस्तेमाल होता था, और आखिर में लोग एक-एक करके इसी निष्कर्ष पर पहुँचे कि इससे CSS selectors HTML structure से बहुत कसकर बँध जाते हैं और हम खुद अपने पैरों पर कुल्हाड़ी मारते हैं
    nesting का जाल project की शुरुआत में आसानी से दिखता नहीं है। greenfield phase में, जहाँ ज़्यादातर नए features बन रहे होते हैं, इस तरह CSS लिखना बहुत अच्छा लगता है
    कुछ महीनों बाद जब बड़े layout बदलाव और design overhaul शुरू होते हैं, तो HTML में wrapper elements अपनी जगह बदलते रहते हैं, और CSS को उसके हिसाब से ढालना LSD लेकर Rubik's Cube हल करने जैसा लगने लगता है
    मेरा मानना है कि selector specificity को संभालने का सबसे अच्छा तरीका यह था कि ज़्यादातर चीज़ों को simple selectors, यानी सिर्फ एक class, तक low रखा जाए, और बहुत कम composite selectors तथा a:hover जैसे combinator selectors ही इस्तेमाल हों। यही BEM, OOCSS जैसी धाराएँ थीं, और उसके बाद ध्यान तेज़ी से JS-केंद्रित tools की तरफ़ चला गया

  • दिलचस्प लेख है, लेकिन लगता है कि लेखक nested selectors को ऐसी जगह इस्तेमाल कर रहा है जहाँ उनका कोई असर ही नहीं है

    header { /* Site Header */  
  margin-bottom: 2rem;  
  & nav { /* ampersand redundant here? */  
    /* Styles, specific to nav in the Header. */  
  }  
}
    • कुछ लोग मानते हैं कि & को छोड़ सकने देना एक गलती थी, और वे हमेशा & लिखते हैं। यह काफ़ी तर्कसंगत रुख़ है
      निजी तौर पर मैं अभी भी आधा-आधा बँटा हूँ। शुरू में मुझे भी यह गलती लगा था, लेकिन जब बहुत सारे styles लिखने के बाद उन्हें सिर्फ header { … } में wrap करके scope छोटा किया जा सकता है, तब यह काफ़ी सुविधाजनक लगता है। अच्छा होता अगर @keyframes जैसे selector-आधारित नहीं होने वाले at-rules भी उसके अंदर लिखे जा सकते

  • यह सच कहूँ तो वाकई बहुत खराब सलाह है। मुझे Maklad की लिखी चीज़ें पसंद हैं, लेकिन यह साफ़ तौर पर ऐसे व्यक्ति ने लिखा है जिसने कभी professional तौर पर CSS इस्तेमाल नहीं की
    लगभग सब कुछ वही amateur-level bad practices हैं जिनसे professional CSS writing में बचा जाता है

    • थोड़ा और स्पष्ट कहें तो, amateurs के लिए मुख्य design target content box होता है। CMS paragraph, emphasis, links, lists वगैरह उगल देता है, और ज़्यादातर समय उसी को style करने में जाता है
      selectors के बिना उसे style करते-करते वे <main> या <nav> को भी बिना selector के style करने लगते हैं
      इसके उलट professional माहौल में content box design करने में बहुत कम समय लगता है। project की शुरुआत में उसे एक बार बना दिया जाता है, और उसके बाद बस छोटे bugs धीरे-धीरे ठीक किए जाते हैं
      ज़्यादातर समय custom components या reusable components बनाने में जाता है। reusable components ज़्यादा कठिन होते हैं, और practically आप site-specific Bootstrap clone बना रहे होते हैं
      custom components आसान होते हैं, लेकिन code ज़्यादा हो जाता है, और दूसरे components से अनचाहा interference न हो, इसके लिए BEM, OOCSS, Tailwind जैसी utility classes जैसी रणनीतियाँ चाहिए होती हैं
      निष्कर्ष यह है कि हर technique के लिए सही scale अलग होता है। अगर professional CSS writing के तरीके आपको बेकार लगते हैं, तो शायद आप किसी और scale की समस्या हल कर रहे हैं
    • लेख में भी साफ़ कहा गया है कि “मैंने कभी production CSS नहीं लिखी”
      फिर भी Bad: Wrappers से मैं सहमत हूँ। मैंने ऐसे CSS experts भी देखे हैं जो पूरी site को एक-दो files में लिख देते हैं, और ऐसे लोग भी देखे हैं जो CSS का बहुत भारी इस्तेमाल करते हैं
      बाद वाला रास्ता आखिरकार बहुत सारी CSS को manage करने के लिए BEM जैसे गलत approach की ओर ले जाना आसान बना देता है

  • लेख में कुछ सलाहें एक-दूसरे से टकराती हुई लगती हैं
    Good: Classless CSS और Bad: CSS selectors दोनों साथ में हैं, लेकिन classless CSS इस्तेमाल करनी हो तो उल्टा CSS selectors पर और ज़्यादा निर्भर होना पड़ता है
    संदर्भ: https://www.keithcirkel.co.uk/css-classes-considered-harmful/

  • “जैसे वेबपेज के पीछे कोई अदृश्य ruled notebook हो” वाली vertical rhythm सिर्फ EM values से भी हासिल की जा सकती है
    अलग-अलग fonts मिलाने पर metrics के फ़र्क़ की वजह से थोड़ा डगमगाव हो सकता है, लेकिन तब भी flex का align-items: baseline इस्तेमाल किया जा सकता है