Frontend Interview: CSS Container Queries, Media Queries से किस प्रकार भिन्न हैं?

प्रॉम्प्ट और संदर्भ

एक कार्ड कम्पोनेंट मुख्य कॉलम, साइडबार और ग्रिड में दिखाई देता है। समझाएं कि CSS container queries, media queries से किस प्रकार भिन्न हैं, ऐसा CSS लिखें जो कार्ड कंटेनर की चौड़ाई के आधार पर लेआउट बदलता हो, और कन्टेनमेंट, स्कोप, फ़ॉलबैक तथा टेस्टिंग का विवरण दें।

Media queries व्यूपोर्ट या डिवाइस की विशेषताओं का मूल्यांकन करती हैं; container queries किसी एंसेस्टर (पूर्वज) क्वेरी कंटेनर के आकार, स्टाइल या स्क्रॉल स्थिति का मूल्यांकन करती हैं। GreatFrontEnd की CSS इंटरव्यू गाइड container queries को एक इंटरव्यू प्रश्न के रूप में सूचीबद्ध करती है, Hack Frontend की HTML/CSS प्रश्न सूची इस विषय को कवर करती है, और MDN container-type, @container तथा container query यूनिट्स का दस्तावेज़ीकरण करता है। यह प्रश्न किसी विशिष्ट कंपनी से जुड़ा नहीं है।

इंटरव्यूअर्स क्या आंकते हैं

इंटरव्यूअर्स चाहते हैं कि उम्मीदवार CSS लिखने से पहले रिस्पॉन्स टारगेट की पहचान करे। एक बेहतरीन उत्तर यह समझाता है कि container-type: inline-size एक साइज़-क्वेरी कॉन्टेक्स्ट स्थापित करता है, यह कि क्वेरी रूल्स स्वयं कंटेनर के बजाय उसके डिसेंडेंट्स (वंशजों) को स्टाइल करते हैं, डिफ़ॉल्ट रूप से निकटतम योग्य एंसेस्टर का उपयोग किया जाता है, और एक ही व्यूपोर्ट चौड़ाई पर भी अलग-अलग कार्ड चौड़ाई के लिए container queries की आवश्यकता क्यों होती है।

वे साइज़-कन्टेनमेंट के साइड इफेक्ट्स, नेम्ड-कंटेनर सीमाओं, ब्राउज़र फ़ॉलबैक और टेस्टिंग की समझ की भी जांच करते हैं। कंटेनर स्थापित किए बिना या नेस्टिंग को संभाले बिना केवल @media को @container से बदलना विश्वसनीय रूप से काम नहीं करेगा।

स्पष्टीकरण हेतु प्रश्न

• रिस्पॉन्स को क्या संचालित करना चाहिए? यह प्रॉम्प्ट पूरे व्यूपोर्ट के बजाय कार्ड के इनलाइन आकार पर प्रतिक्रिया करता है।
• क्या स्टाइल या स्क्रॉल-स्टेट क्वेरीज़ की आवश्यकता है? नहीं; यह उत्तर साइज़ क्वेरीज़ पर केंद्रित है और अन्यों को एक्सटेंशन के रूप में मानता है।
• ब्राउज़र सपोर्ट टारगेट क्या है? पहले इसकी पुष्टि करें, फिर एक उपयोगी बेस लेआउट और फ़ॉलबैक बनाए रखें।
• क्या कम्पोनेंट की सीमाएं नेस्टेड हो सकती हैं? यदि हाँ, तो अभीष्ट सीमा को स्पष्ट करने के लिए container-name का उपयोग करें।

30-सेकंड का उत्तर

“Media queries व्यूपोर्ट का अवलोकन करती हैं और पेज-लेवल ब्रेकपॉइंट्स के लिए उपयुक्त हैं; container queries किसी कम्पोनेंट के एंसेस्टर का अवलोकन करती हैं और विभिन्न स्लॉट्स में रखे गए दोबारा उपयोग किए जाने वाले (reusable) कम्पोनेंट्स के लिए उपयुक्त हैं। मैं कार्ड लिस्ट पर container-type: inline-size सेट करता हूँ, फिर एक इनलाइन-साइज़ थ्रेशोल्ड पर कार्ड लेआउट बदलने के लिए @container का उपयोग करता हूँ। क्वेरी डिसेंडेंट्स को स्टाइल करती है और डिफ़ॉल्ट रूप से निकटतम योग्य कंटेनर का उपयोग करती है; मैं जटिल नेस्टिंग के लिए container-name का उपयोग करता हूँ। मैं बेस स्टाइल्स और एक @supports फ़ॉलबैक प्रदान करता हूँ, फिर मुख्य कॉलम, साइडबार, ग्रिड और एक असमर्थित ब्राउज़र में पैरेंट का आकार बदलते समय व्यूपोर्ट को स्थिर रखता हूँ।”

चरण-दर-चरण उत्तर

चरण 1: रिस्पॉन्स टारगेट और स्कोप की तुलना करें

Media queries नेविगेशन, पेज कॉलम्स, प्रिंटिंग और यूज़र प्राथमिकताओं के लिए सीधे तौर पर उपयुक्त हैं। Container queries उस स्थिति को हल करती हैं जहां एक कम्पोनेंट को यह नहीं पता होता कि उसका स्लॉट कितना चौड़ा होगा: एक ही व्यूपोर्ट चौड़ाई पर एक मुख्य कॉलम और साइडबार अलग-अलग लेआउट का उपयोग कर सकते हैं।

चरण 2: एक साइज़-क्वेरी कॉन्टेक्स्ट स्थापित करें

.card-list {
  container-type: inline-size;
  container-name: card-list;
}

.card {
  display: grid;
  gap: 0.75rem;
}

@container card-list (inline-size > 40rem) {
  .card {
    grid-template-columns: 8rem 1fr;
    align-items: center;
  }
}

inline-size एक इनलाइन-एक्सिस साइज़-क्वेरी कंटेनर स्थापित करता है और राइटिंग मोड्स के महत्वपूर्ण होने पर अच्छी तरह से काम करता है। size मजबूत दो-अक्षीय कन्टेनमेंट स्थापित करता है और इसे केवल तभी चुना जाना चाहिए जब ब्लॉक-एक्सिस क्वेरीज़ की आवश्यकता हो। normal साइज़-क्वेरी कॉन्टेक्स्ट स्थापित नहीं करता है। शर्त @container में लिखी जाती है, और मैचिंग नियम डिसेंडेंट्स पर लागू होता है।

चरण 3: निकटतम कंटेनर्स, नाम और यूनिट्स को समझें

बिना किसी नाम के, ब्राउज़र निकटतम योग्य एंसेस्टर को ढूंढता है; इसलिए नेस्टेड कम्पोनेंट्स गलत सीमा को पढ़ सकते हैं। एक नाम उद्देश्य को स्पष्ट करता है: @container card-list (...) केवल card-list नाम वाले कंटेनर से मेल खाता है। Container query लंबाई की इकाइयाँ जैसे cqw और cqi क्वेरी कंटेनर की चौड़ाई या इनलाइन आकार के आधार पर स्केल होती हैं, लेकिन इन्हें उचित न्यूनतम और अधिकतम मानों के साथ जोड़ा जाना चाहिए ताकि बहुत छोटे कंटेनर अपठनीय टेक्स्ट न उत्पन्न करें।

क्वेरी को अपने परिणाम के आधार पर कंटेनर का स्वयं का आकार बदलने का कारण नहीं बनना चाहिए, अन्यथा एक फीडबैक लूप हो सकता है; कन्टेनमेंट और स्कोपिंग नियम उस लूप को रोकते हैं। साइज़ कन्टेनमेंट स्वचालित साइज़िंग को भी बदल सकता है, इसलिए खाली कंटेंट, अनलोड की गई इमेज और कंटेंट पर निर्भर ऊंचाइयों की जांच करें।

चरण 4: फ़ॉलबैक और प्रोग्रेसिव एन्हांसमेंट डिज़ाइन करें

.card {
  display: block;
}

@supports (container-type: inline-size) {
  .card-list {
    container-type: inline-size;
  }

  @container (inline-size > 40rem) {
    .card {
      display: grid;
      grid-template-columns: 8rem 1fr;
    }
  }
}

बेस लेआउट container queries के बिना भी पठनीय रहना चाहिए। एक media query पेज-लेवल फ़ॉलबैक प्रदान कर सकती है, लेकिन एक व्यूपोर्ट ब्रेकपॉइंट प्रत्येक साइडबार या ग्रिड-सेल चौड़ाई का सटीक प्रतिनिधित्व नहीं कर सकता है। जब लक्षित ब्राउज़र में परखी गई क्षमता की कमी होती है, तो उसे मूल कंटेंट या इंटरैक्शन को खोए बिना बेस स्टाइल्स को बनाए रखना चाहिए।

चरण 5: परिदृश्यों और सीमाओं का परीक्षण करें

ब्राउज़र व्यूपोर्ट को स्थिर रखें। एक ही कम्पोनेंट को मुख्य कॉलम, साइडबार और दो-कॉलम ग्रिड में रखें, फिर केवल पैरेंट की चौड़ाई बदलें और सत्यापित करें कि कार्ड व्यूपोर्ट के बजाय कंटेनर पर प्रतिक्रिया करता है। नेस्टेड नेम्ड कंटेनर्स, विभिन्न राइटिंग मोड्स, लोड होने से पहले और बाद की इमेज, बहुत संकीर्ण कंटेनर्स, डायनेमिक स्लॉट्स और container-query सपोर्ट के बिना ब्राउज़र का परीक्षण करें। यह भी सत्यापित करें कि कम्पोनेंट किसी एक पेज की DOM डेप्थ पर निर्भर नहीं करता है, जो पुन: उपयोग किए जाने पर गलत कंटेनर का चुपचाप चयन कर सकता है।

स्वीकार्य कार्यान्वयन सीमाएं

उत्तर में प्रत्येक क्वेरी प्रकार को कवर करने की आवश्यकता नहीं है, लेकिन इसे व्यूपोर्ट को एंसेस्टर कंटेनर से सटीक रूप से अलग करना चाहिए और उदाहरण को वास्तविक क्वेरी कॉन्टेक्स्ट के साथ चलाने योग्य बनाना चाहिए। यदि उम्मीदवार size, स्टाइल क्वेरीज़, या स्क्रॉल-स्टेट क्वेरीज़ चुनता है, तो उन्हें अतिरिक्त कन्टेनमेंट प्रभावों, ब्राउज़र टारगेट और टेस्ट सीमाओं की व्याख्या करनी चाहिए। जब सपोर्ट अनिश्चित हो, तो बेस लेआउट सुरक्षित डिफ़ॉल्ट होना चाहिए।

सामान्य गलतियाँ और विरोधी उदाहरण

• container-type को भूल जाना: बिना क्वेरी कॉन्टेक्स्ट के @container आकार पर प्रतिक्रिया नहीं करता है।
• कंटेनर को अपना स्वयं का क्वेरी टारगेट बनाना: स्थिर क्वेरीज़ डिसेंडेंट्स को स्टाइल करती हैं; परिणाम से स्वयं का आकार बदलना एक लूप बना सकता है।
• डिफ़ॉल्ट रूप से size का उपयोग करना: दो-अक्षीय कन्टेनमेंट स्वचालित साइज़िंग को प्रभावित कर सकता है; केवल क्षैतिज आवश्यकता के लिए inline-size चुनें।
• केवल चौड़ी स्क्रीन पर परीक्षण करना: साइडबार और मुख्य कॉलम एक ही व्यूपोर्ट चौड़ाई पर भिन्न होते हैं, इसलिए व्यूपोर्ट को स्थिर रखते हुए पैरेंट का आकार बदलें।
• बेस फ़ॉलबैक को छोड़ना: असमर्थित ब्राउज़रों को एन्हांसमेंट से पहले एक उपयोगी बेस लेआउट की आवश्यकता होती है।

फॉलो-अप्स और प्रतिक्रियाएं

आप अभी भी media queries का उपयोग कब करेंगे?

Media queries का उपयोग तब करें जब नेविगेशन, पेज कॉलम्स, प्रिंटिंग या यूज़र प्राथमिकताएं व्यूपोर्ट या मीडिया विशेषताओं पर निर्भर करती हों। जब किसी कम्पोनेंट का आंतरिक ब्रेकपॉइंट उसके पैरेंट पर निर्भर करता है, तो container queries का उपयोग करें।

आप inline-size बनाम size का चयन कैसे करते हैं?

inline-size तब चुनें जब कम्पोनेंट केवल उपलब्ध क्षैतिज स्थान पर प्रतिक्रिया करता हो। जब ब्लॉक और इनलाइन दोनों अक्षों की आवश्यकता हो, तब size पर विचार करें, फिर स्वचालित साइज़िंग, खाली कंटेंट और इमेज-लोड के बाद के व्यवहार को सत्यापित करें।

आप असमर्थित ब्राउज़रों को कैसे संभालते हैं?

एक बेस सिंगल-कॉलम या फ्लूइड लेआउट प्रदान करें और @supports (container-type: inline-size) के साथ इसे उत्तरोत्तर बेहतर (progressively enhance) बनाएं। Media queries पेज-लेवल व्यवहार को पूरक कर सकती हैं, लेकिन वे प्रत्येक कंटेनर-लेवल ब्रेकपॉइंट की जगह नहीं ले सकती हैं।