प्रतिनिधि इंटरव्यू विषय

फ़्रंटएंड इंटरव्यू: बहुत बड़ा z-index होने पर भी कोई एलिमेंट दूसरे एलिमेंट के पीछे क्यों रह जाता है?

फ्रंटएंडमध्यम
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

कार्ड के अंदर मौजूद एक ड्रॉपडाउन position: absolute और z-index: 999999 का उपयोग करता है, फिर भी उसका कुछ हिस्सा स्टिकी हेडर के पीछे रहता है और बाकी हिस्सा कार्ड के किनारे पर कट जाता है। समझाएं कि z-index बढ़ाने से यह समस्या क्यों हल नहीं होती, दिखाएं कि आप इसका निदान कैसे करेंगे, और एक साधारण मेनू, एक पुन: प्रयोज्य ओवरले, तथा एक मोडल या पॉपओवर के लिए फिक्स चुनें।

प्रॉम्प्ट और लागू संदर्भ

एक उत्पाद पृष्ठ (product page) में एक स्टिकी हेडर और एक कार्ड है जिसमें मेनू बटन शामिल है। मेनू बिल्कुल एब्सोल्यूटली पोज़िशन्ड (absolutely positioned) है और इसे अत्यधिक बड़ा स्टैकिंग मान (stacking value) दिया गया है। जब यह पृष्ठ के शीर्ष के पास खुलता है, तब भी हेडर इसके ऊपर पेंट होता है। जब यह कार्ड से बाहर फैलता है, तो इसका निचला हिस्सा गायब हो जाता है। एक टीम का साथी स्टैकिंग मान में एक और शून्य जोड़ने का सुझाव देता है।

समझाएं कि वह प्रस्ताव दोनों लक्षणों को ठीक क्यों नहीं कर सकता। नीचे दिए गए उदाहरण का निदान करें, पेंट क्रम (paint order) को क्लिपिंग और पोज़िशनिंग ज्योमेट्री से अलग करें, और तीन मामलों के लिए एक टिकाऊ समाधान चुनें: एक मेनू जो अपने घटक के अंदर रह सकता है, एक ओवरले जिसे घटक से बाहर निकलना होगा, और ऐसा UI जिसके सिमेंटिक्स मोडल डायलॉग या पॉपओवर की मांग करते हैं।

html
<header class="site-header">Navigation</header>
<main class="page">
  <section class="card">
    <button type="button">Open menu</button>
    <div class="menu">Menu items</div>
  </section>
</main>
css
.site-header {
  position: sticky;
  top: 0;
  z-index: 4;
}

.page {
  position: relative;
  z-index: 1;
}

.card {
  position: relative;
  overflow: hidden;
  transform: translateZ(0);
}

.menu {
  position: absolute;
  inset-block-start: 100%;
  z-index: 999999;
}

मान लें कि वर्तमान एवरग्रीन ब्राउज़र उपयोग में हैं। उत्तर को केवल तब तक CSS हटाने के बजाय कि जब तक स्क्रीनशॉट सही न दिखे, जानबूझकर किए गए स्क्रॉल, कंटेनमेंट और एक्सेसिबिलिटी व्यवहार को बनाए रखना चाहिए।

इंटरव्यूअर क्या मूल्यांकन करता है

पहला संकेत यह है कि क्या उम्मीदवार तुलना की सीमा (comparison boundary) को जानता है। एक stacking context अपने मूल (parent) संदर्भ में एक एकल परमाणु इकाई (atomic unit) के रूप में पेंट होता है। वंशज (descendants) उस इकाई के अंदर स्वयं को पुन: व्यवस्थित कर सकते हैं, लेकिन कोई भी वंशज स्टैकिंग मान पूरी इकाई को उसके मूल संदर्भ के सिबलिंग से ऊपर नहीं उठा सकता। यहाँ, मेनू का बड़ा मान .page के अंदर जीतता है; संपूर्ण .page अभी भी स्तर 1 पर भाग लेता है, जो स्तर 4 पर मौजूद हेडर से नीचे है।

दूसरा संकेत वर्गीकरण है। "हेडर के पीछे" होना एक पेंट-क्रम (paint-order) की समस्या है। "कार्ड के किनारे पर कटना" overflow: hidden के कारण होने वाली क्लिपिंग की समस्या है। एक तीसरा वर्ग अक्सर समान दिखता है: transform वाला एक पूर्वज (ancestor) एब्सोल्यूटली और फिक्स्ड-पोज़िशन्ड वंशजों के लिए एक containing block स्थापित करता है, इसलिए निर्देशांक (coordinates) या फिक्स्ड व्यवहार किसी अप्रत्याशित पूर्वज के सापेक्ष हो सकते हैं। एक अकेला स्टैकिंग मान क्लिपिंग या ज्योमेट्री को ठीक नहीं करता है।

तीसरा संकेत रटी हुई सूची बनाए बिना context creators का ज्ञान होना है। सामान्य कारणों में गैर-ऑटो स्टैकिंग मान वाला पोज़िशन्ड एलिमेंट, फिक्स्ड या स्टिकी पोज़िशनिंग, एक से कम opacity, transforms, फ़िल्टर, perspective, क्लिपिंग या मास्किंग, ब्लेंडिंग, isolation: isolate, लेआउट या पेंट कंटेनमेंट, कंटेनर क्वेरीज़, और गैर-ऑटो स्टैकिंग मान वाले flex या grid चिल्ड्रन शामिल हैं। प्रत्येक पूर्वज श्रृंखला (ancestor chain) पर पहली प्रासंगिक सीमा खोजना एक उपयोगी कौशल है।

चौथा संकेत समाधान का निर्णय (repair judgment) है। किसी दुर्घटनावश बने संदर्भ को हटाना, सही पूर्वज के स्तर को बदलना, ओवरले को रीपैरेंट (reparent) करना, और ब्राउज़र के top layer का उपयोग करना अलग-अलग अनुबंधों (contracts) को हल करते हैं। एक पोर्टल DOM वंशावली को बदलता है और घटक क्लिपिंग से बच सकता है, लेकिन यह स्वचालित रूप से top layer में प्रवेश नहीं करता है या मोडल, फ़ोकस, डिसमिसल, या एक्सेसिबल-नाम व्यवहार नहीं जोड़ता है।

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

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

  • कौन से पिक्सेल गलत हैं? क्या मेनू किसी अन्य एलिमेंट के नीचे पेंट हुआ है, किसी सीमा पर क्लिप हुआ है, गलत निर्देशांकों पर स्थित है, या किसी top-layer एलिमेंट द्वारा कवर किया गया है? इनके लिए अलग-अलग सुधारों की आवश्यकता होती है।
  • कौन से पूर्वज संदर्भ बनाते हैं? मेनू की श्रृंखला और कवर करने वाले एलिमेंट की श्रृंखला दोनों का निरीक्षण करें। निर्णायक तुलना वह है जहां श्रृंखलाएं पहली बार सिबलिंग बनती हैं, आवश्यक नहीं कि दो दृश्यमान एलिमेंट्स पर ही हों।
  • क्या क्लिपिंग जानबूझकर की गई है? एक कार्ड गोल किनारों वाले मीडिया को क्लिप कर सकता है, और एक स्क्रॉल कंटेनर को ओवरफ़्लो व्यवहार की आवश्यकता हो सकती है। इसे वैश्विक रूप से हटाने से मेनू तो ठीक हो सकता है लेकिन लेआउट और स्क्रॉलिंग टूट सकती है।
  • ओवरले को किसके साथ एंकर किया जाना चाहिए? साझा ओवरले रूट पर रीपैरेंटिंग का मतलब है कि इसके निर्देशांकों को उस रूट के सापेक्ष मापा जाना चाहिए और स्क्रॉल, रीसाइज़, ज़ूम और लेआउट परिवर्तनों पर अपडेट किया जाना चाहिए।
  • क्या UI को top-layer सिमेंटिक्स की आवश्यकता है? एक मोडल डायलॉग को बाहरी इंटरैक्शन को ब्लॉक करना चाहिए और फ़ोकस को प्रबंधित करना चाहिए। एक हल्के मेनू को केवल एक ओवरले रूट की आवश्यकता हो सकती है। एक उपयुक्त पॉपओवर प्लेटफ़ॉर्म के पॉपओवर व्यवहार और top-layer प्लेसमेंट का उपयोग कर सकता है।
  • कौन से ओवरले एक साथ सह-अस्तित्व में रह सकते हैं? परिभाषित करें कि क्या मेनू, टूलटिप्स, स्टिकी नेविगेशन, ड्रॉअर और मोडल ओवरलैप हो सकते हैं। यादृच्छिक छह अंकों के मानों की तुलना में नामित लेयर्स (named layers) का एक छोटा सेट समझना आसान होता है।
  • कौन से ब्राउज़र और घटक अनुबंध लागू होते हैं? वर्तमान प्लेटफ़ॉर्म प्रिमिटिव को प्राथमिकता दी जा सकती है; पुराना वेबव्यू या स्थापित डिज़ाइन-सिस्टम प्रिमिटिव कार्यान्वयन विकल्प को बदल सकता है।

30-सेकंड का उत्तर फ़्रेमवर्क

"मैं मान बदलने से पहले विफलता को वर्गीकृत करूँगा। मेनू के 999999 की तुलना केवल उसके अपने stacking context के भीतर की जाती है। इसका पूर्वज .page स्तर 1 पर है, इसलिए पूरा सबट्री स्तर 4 पर मौजूद स्टिकी हेडर के नीचे ही रहता है। इसके अलावा, कार्ड का हिडन ओवरफ़्लो मेनू को क्लिप करता है, और इसका transform मेनू के containing block को बदल सकता है। मैं पूर्वज श्रृंखलाओं और ओवरलैप बिंदु पर वास्तविक सबसे ऊपरी एलिमेंट का निरीक्षण करूँगा। यदि मेनू स्थानीय रह सकता है, तो मैं किसी दुर्घटनावश बने संदर्भ को हटा दूँगा या सही पूर्वज को ऊपर उठाऊँगा और क्लिपिंग को स्थानीय स्तर पर संभालूँगा। यदि इसे बाहर निकलना ही है, तो मैं इसे एक साझा ओवरले रूट में रेंडर करूँगा और एंकर ज्योमेट्री की पुनर्गणना करूँगा। यदि इंटरैक्शन एक मोडल या उपयुक्त पॉपओवर है, तो मैं ब्राउज़र के top layer का उपयोग करूँगा और आवश्यक फ़ोकस व डिसमिसल अनुबंध को लागू करूँगा। फिर मैं स्क्रॉल, रीसाइज़, ज़ूम, कीबोर्ड इंटरैक्शन और अन्य ओवरले के साथ सह-अस्तित्व का परीक्षण करूँगा।"

चरण-दर-चरण गहन विश्लेषण

चार तंत्रों को अलग करके शुरुआत करें। वे एक साथ विफल हो सकते हैं, लेकिन वे एक दूसरे के स्थान पर नहीं उपयोग किए जा सकते:

text
PAINT ORDER
  Which painted box is above another?
  Controlled by the stacking-context tree and paint order inside each context.

CLIPPING
  Which pixels are allowed to appear?
  Controlled by overflow, clip paths, masks, and paint containment.

GEOMETRY
  Which box supplies the coordinate system?
  A transform can establish the containing block for absolute and fixed descendants.

TOP LAYER
  Is the element outside normal document stacking?
  Modal dialogs and shown popovers can be placed in the browser-managed top layer.

दो दृश्यमान संख्याओं की तुलना करने के बजाय उदाहरण के लिए संदर्भ ट्री (context tree) बनाएं। स्टिकी हेडर स्तर 4 पर एक संदर्भ बनाता है। पोज़िशन्ड .page स्तर 1 पर एक सिबलिंग संदर्भ बनाता है। कार्ड का transform, .page के भीतर एक अन्य संदर्भ बनाता है। मेनू का बड़ा मान केवल उस सबट्री के अंदर ही इसे क्रमबद्ध करता है। वैचारिक रूप से, तुलना header: 4 बनाम page: 1 है; यह कभी भी header: 4 बनाम menu: 999999 नहीं है।

इसके बाद, क्लिपिंग का स्वतंत्र रूप से निरीक्षण करें। मेनू .card का वंशज है, इसलिए कार्ड के पैडिंग बॉक्स के बाहर के पिक्सेल हिडन ओवरफ़्लो द्वारा क्लिप किए जाते हैं। स्टैकिंग से पेंट का क्रम बदलता है; वे क्लिपिंग क्षेत्र का विस्तार नहीं करते हैं। .page को ऊपर उठाना, transform को हटाना, या मेनू के मान को बदलना इसे हेडर के ऊपर ला सकता है और फिर भी इसके निचले हिस्से को कटा हुआ छोड़ सकता है।

फिर containing block का निरीक्षण करें। मेनू एब्सोल्यूट है, इसलिए पोज़िशन्ड कार्ड पहले से ही इसके निर्देशांक प्रदान करता है। इस विशिष्ट मेनू के लिए transform अनावश्यक (redundant) है, लेकिन यह तब महत्वपूर्ण हो जाता है यदि भविष्य का कोई कार्यान्वयन मेनू को position: fixed पर स्विच करता है: एक रूपांतरित (transformed) पूर्वज उस "fixed" एलिमेंट को व्यूपोर्ट के बजाय पूर्वज के सापेक्ष व्यवहार करने के लिए बाध्य कर सकता है। यही कारण है कि absolute को fixed में बदलना कोई विश्वसनीय बचाव का रास्ता नहीं है।

अनुमान लगाने के बजाय परिकल्पना की पुष्टि के लिए ब्राउज़र निरीक्षण का उपयोग करें। हर पूर्वज पर कंप्यूटेड शैलियों का निरीक्षण तब तक करें जब तक कि पहला संदर्भ निर्माता (context creator) और क्लिपिंग पूर्वज न मिल जाए। मेनू और हेडर की संदर्भ श्रृंखलाओं की तुलना करें। जिस निर्देशांक पर वे ओवरलैप करते हैं, वहां क्वेरी करें कि हिट टेस्टिंग किसे सबसे ऊपरी मानती है:

js
function inspectOverlap(x, y) {
  const stack = document.elementsFromPoint(x, y)

  return stack.map((element) => ({
    element,
    position: getComputedStyle(element).position,
    zIndex: getComputedStyle(element).zIndex,
    overflow: getComputedStyle(element).overflow,
    transform: getComputedStyle(element).transform,
  }))
}

हिट-टेस्ट स्टैक को देखने के लिए elementsFromPoint() सुविधाजनक है; elementFromPoint() केवल सबसे ऊपरी योग्य एलिमेंट लौटाता है। हिट टेस्टिंग सहायक साक्ष्य है, संपूर्ण stacking-context डिबगर नहीं: pointer-events: none वाले एलिमेंट्स को छोड़ा जा सकता है, और क्लिपिंग या ऑफ़-स्क्रीन ज्योमेट्री के लिए अभी भी लेआउट निरीक्षण की आवश्यकता होती है।

स्वामित्व सीमा (ownership boundary) से मेल खाने वाला सबसे छोटा सुधार चुनें।

एक स्थानीय मेनू के लिए, किसी अनपेक्षित संदर्भ को हटा दें यदि उसका कोई आवश्यक दृश्य या रोकथाम प्रभाव नहीं है। यदि पृष्ठ को वास्तव में अपने संदर्भ की आवश्यकता है, तो पृष्ठ-स्तरीय टोकन की तुलना करें और बदलें क्योंकि वह सिबलिंग है जिसे हेडर के विरुद्ध क्रमबद्ध किया जा रहा है। यदि कार्ड क्लिपिंग केवल मीडिया के लिए है, तो उस क्लिपिंग को पूरे इंटरैक्टिव कार्ड के बजाय नेस्टेड मीडिया रैपर पर रखें।

css
:root {
  --layer-content: 0;
  --layer-sticky: 20;
  --layer-overlay: 40;
}

.page {
  position: relative;
  z-index: var(--layer-content);
}

.site-header {
  z-index: var(--layer-sticky);
}

.card-media {
  overflow: hidden;
  border-radius: 1rem;
}

.menu {
  z-index: var(--layer-overlay);
}

यह केवल तभी काम करता है जब इच्छित अनुबंध पृष्ठ सबट्री को हेडर के नीचे रहने की अनुमति देता है और मेनू को उस सीमा को पार करने की आवश्यकता नहीं होती है। यदि मेनू को हेडर को कवर करना ही है, तो लेयर का निर्णय एक सामान्य पूर्वज पर होना चाहिए या ओवरले को एक साझा रूट पर ले जाना चाहिए।

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

एक वास्तविक मोडल संवाद के लिए, मोडल रूप से खोले गए नेटिव डायलॉग एलिमेंट या एक स्थापित एक्सेसिबल प्रिमिटिव को प्राथमिकता दें जो समान अनुबंध प्रदान करता है। उपयुक्त गैर-मोडल इंटरैक्शन के लिए, popover API प्रदर्शित सामग्री को top layer में रख सकता है। Top-layer की प्रविष्टियाँ सामान्य दस्तावेज़ संदर्भों से ऊपर रेंडर होती हैं; बाद की प्रविष्टियाँ पहले वाली प्रविष्टियों के ऊपर होती हैं, और प्रत्येक का अपना रूट संदर्भ होता है। पूर्वज ओवरफ़्लो, अपारदर्शिता, मास्क और ट्रांसफ़ॉर्म किसी top-layer एलिमेंट को वापस पूर्वज के दस्तावेज़ संदर्भ में नहीं खींचते हैं।

Top layer कोई सार्वभौमिक "मजबूत z-index" नहीं है। यह सिमेंटिक प्रवेश और निकास तंत्र के साथ एक व्यवस्थित ब्राउज़र-प्रबंधित लेयर है। एक मोडल को अभी भी एक उपयोगी नाम, जानबूझकर प्रारंभिक फ़ोकस, समाहित इंटरैक्शन, डिसमिसल नीति और फ़ोकस पुनर्स्थापना की आवश्यकता होती है। एक मेनू को अभी भी सही मेनू या प्रकटीकरण सिमेंटिक्स और कीबोर्ड व्यवहार की आवश्यकता होती है। लेयर चुनना कभी भी इंटरैक्शन मॉडल चुनने का स्थान नहीं लेता है।

मैट्रिक्स के रूप में सुधार को मान्य करें:

  1. प्रत्येक व्यूपोर्ट किनारे के पास और नेस्टेड स्क्रॉल कंटेनरों के अंदर खोलें।
  2. पृष्ठ और निकटतम कंटेनर को स्क्रॉल करें; सत्यापित करें कि पैनल एंकर रहता है या नीति के अनुसार बंद हो जाता है।
  3. आकार बदलें, 200% तक ज़ूम करें, और संकीर्ण व चौड़े लेआउट का परीक्षण करें।
  4. कीबोर्ड द्वारा नेविगेट करें; सत्यापित करें कि क्रम, दृश्यमान फ़ोकस, Escape, और फ़ोकस वापसी घटक से मेल खाते हैं।
  5. इसे स्टिकी नेविगेशन, ड्रॉअर, टूलटिप और पहले से मौजूद वास्तविक मोडल के साथ खोलें।
  6. अस्पष्ट पिक्सेल पर हिट परीक्षण की जाँच करें और पुष्टि करें कि कोई अदृश्य ओवरले असंबंधित नियंत्रणों को नहीं रोकता है।
  7. लंबे अनुवादित लेबलों और समर्थित होने पर बाएं-से-दाएं और दाएं-से-बाएं दोनों लेआउट का परीक्षण करें।
  8. पुष्टि करें कि जानबूझकर किया गया ओवरफ़्लो, कंटेनमेंट, कंपोज़िटिंग और स्क्रॉल व्यवहार अभी भी काम कर रहे हैं।

उच्च-गुणवत्ता वाला नमूना उत्तर

"बड़े मान की तुलना गलत स्तर पर की जा रही है। मेनू .page stacking context के अंदर है, जो स्तर 1 पर भाग लेता है। हेडर स्तर 4 पर एक सिबलिंग संदर्भ है। ब्राउज़र पृष्ठ सबट्री को परमाणु रूप से हेडर के नीचे पेंट करता है, इसलिए 999999 का कोई वंशज मान बचकर हेडर के साथ प्रतिस्पर्धा नहीं कर सकता है।

एक अलग क्लिपिंग विफलता भी है। कार्ड का छिपा हुआ ओवरफ़्लो इसकी सीमा के बाहर के पिक्सेल को हटा देता है; z-index क्रम बदलता है लेकिन उस क्लिप को बड़ा नहीं कर सकता। कार्ड का ट्रांसफ़ॉर्म एक और संदर्भ बनाता है और absolute व fixed वंशजों के लिए एक containing block स्थापित कर सकता है, इसलिए fixed पोज़िशनिंग पर स्विच करने पर भी एक अप्रत्याशित निर्देशांक प्रणाली का उपयोग हो सकता है।

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

यदि मेनू को अनुबंध के अनुसार घटक और हेडर सीमाओं को पार करने की अनुमति है, तो मैं इसे एक साझा ओवरले रूट में रेंडर करूँगा। इसका मतलब है कि ओवरले सिस्टम माप, टकराव से निपटने और स्क्रॉल, रीसाइज़, ज़ूम और लेआउट परिवर्तन पर अपडेट का स्वामित्व रखता है। एक पोर्टल वंशावली और क्लिपिंग में मदद करता है, लेकिन यह top-layer या एक्सेसिबिलिटी व्यवहार नहीं बनाता है।

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

सामान्य गलतियाँ

  • वंशज मान को अनिश्चित काल तक बढ़ाना → यह निचले मूल संदर्भ में फंसा रहता है → पहले सिबलिंग संदर्भों की तुलना करें और उस लेयर निर्णय के स्वामी को बदलें।
  • प्रत्येक छिपे हुए पिक्सेल को स्टैकिंग बग मानना → ओवरफ़्लो या पेंट रोकथाम अभी भी इसे क्लिप करती है → पेंट क्रम से अलग क्लिपिंग पूर्वजों का निरीक्षण करें।
  • absolute पोज़िशनिंग को fixed में बदलना → एक ट्रांसफ़ॉर्म किया गया पूर्वज अभी भी containing block को परिभाषित कर सकता है → पोज़िशन मोड चुनने से पहले निर्देशांक प्रणाली का पता लगाएं।
  • प्रत्येक transform या overflow घोषणा को हटाना → गोल मीडिया, स्क्रॉलिंग, कंटेनमेंट, या रेंडरिंग व्यवहार टूट जाता है → केवल आकस्मिक ट्रिगर्स को हटाएं या उन्हें उस एलिमेंट तक सीमित करें जिसे उनकी आवश्यकता है।
  • प्रत्येक ओवरले को body में पोर्टल करना → एंकरिंग, टकराव, स्वामित्व और फ़ोकस समस्याएं मूल बग की जगह ले लेती हैं → स्पष्ट ज्योमेट्री और इंटरैक्शन अनुबंधों के साथ एक साझा ओवरले सिस्टम का उपयोग करें।
  • यह मान लेना कि एक पोर्टल top layer है → सामान्य दस्तावेज़ संदर्भ अभी भी इसे कवर कर सकते हैं → जब इसके सिमेंटिक्स फिट हों तो प्लेटफ़ॉर्म top-layer प्रिमिटिव का उपयोग करें।
  • प्रत्येक फ्लोटिंग पैनल के लिए एक मोडल डायलॉग का उपयोग करना → फ़ोकस और बाहरी इंटरैक्शन अनावश्यक रूप से ब्लॉक हो जाते हैं → पहले व्यवहार के आधार पर मोडल, पॉपओवर, मेनू, टूलटिप, या इनलाइन डिस्क्लोज़र चुनें।
  • मनमाने वैश्विक मान बनाना → घटक एक बढ़ती लेयरिंग प्रतियोगिता में प्रवेश करते हैं → नामित लेयर्स के एक छोटे सेट का उपयोग करें और स्थानीय मानों को स्थानीय रखें।
  • केवल एक स्क्रीनशॉट की पुष्टि करना → स्क्रॉल, ज़ूम, कीबोर्ड, या कोई अन्य ओवरले विफलता को फिर से प्रस्तुत करता है → ओवरलैप और इंटरैक्शन मैट्रिक्स का परीक्षण करें।

फॉलो-अप प्रश्न और उत्तर

क्या बड़ा z-index हमेशा किसी एलिमेंट को छोटे वाले के ऊपर रखता है?

केवल तब जब मान समान प्रासंगिक stacking context तुलना में भाग लेते हैं। वंशजों को उनके संदर्भ के भीतर क्रमबद्ध किया जाता है, और फिर उस पूरे संदर्भ को उसके मूल में क्रमबद्ध किया जाता है। संदर्भ श्रृंखलाओं की तुलना करें, अलग-थलग परिकलित मानों की नहीं।

कौन से CSS गुण आमतौर पर एक stacking context बनाते हैं?

रूट, fixed या sticky पोज़िशनिंग, गैर-ऑटो स्टैकिंग मान वाले पोज़िशन्ड एलिमेंट्स, एक से कम opacity, transforms, फ़िल्टर, perspective, क्लिपिंग या मास्किंग, ब्लेंडिंग, isolation, चयनित कंटेनमेंट और कंटेनर-क्वेरी गुण, और गैर-ऑटो स्टैकिंग मान वाले flex या grid चिल्ड्रेन सामान्य कारण हैं। सटीक सूची विकसित होती रहती है, इसलिए केवल मेमोरी पर भरोसा करने के बजाय निरीक्षण को कंप्यूटेड ट्रिगर की पहचान करनी चाहिए।

कोई एलिमेंट अपने सिबलिंग से ऊपर होने पर भी कटा हुआ क्यों दिख सकता है?

पेंट क्रम तय करता है कि किन अनुमत पिक्सेल को अंतिम रूप से पेंट किया जाएगा। एक क्लिपिंग क्षेत्र तय करता है कि किन पिक्सेल को मौजूद रहने की अनुमति है। पेंट क्रम जीतना किसी पूर्वज के ओवरफ़्लो, क्लिप पथ, मास्क या पेंट कंटेनमेंट द्वारा हटाए गए पिक्सेल को पुनर्प्राप्त नहीं कर सकता है।

क्या position: fixed हमेशा overflow-hidden पूर्वज से बच निकलेगा?

नहीं। Fixed पोज़िशनिंग सामान्य containing-block व्यवहार को बदलती है, लेकिन पूर्वजों पर transforms और संबंधित गुण containing block स्थापित कर सकते हैं। अन्य क्लिपिंग तंत्र अभी भी लागू हो सकते हैं। सार्वभौमिक बचाव के रूप में fixed पोज़िशनिंग का उपयोग करने के बजाय ज्योमेट्री और क्लिपिंग का पता लगाएं।

क्या पोर्टल के माध्यम से रेंडरिंग पूरी समस्या का समाधान करती है?

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

Top layer एक बहुत उच्च वैश्विक लेयर टोकन से किस प्रकार भिन्न है?

Top-layer एलिमेंट्स सामान्य दस्तावेज़ सामग्री के ऊपर एक ब्राउज़र-प्रबंधित व्यवस्थित लेयर में पेंट किए जाते हैं और रूट stacking contexts बनाते हैं। प्रवेश क्रम उस लेयर के भीतर क्रम निर्धारित करता है। एक उच्च वैश्विक टोकन अभी भी दस्तावेज़ के संदर्भ ट्री में भाग लेता है और किसी पूर्वज द्वारा फंसा रह सकता है।

क्या किसी टीम को सभी स्थानीय z-index मानों पर प्रतिबंध लगा देना चाहिए?

नहीं। स्थानीय मान एक घटक के अंदर भागों को क्रमबद्ध करने के लिए उपयोगी होते हैं, जैसे कि एक छवि के ऊपर एक बैज। स्टिकी नेविगेशन, पुन: प्रयोज्य ओवरले और ड्रॉअर जैसी साझा सीमाओं पर ही एक छोटे नामित पैमाने का उपयोग करें। सीमा, न कि संख्या का आकार, यह निर्धारित करती है कि कोई मान वैश्विक है या नहीं।

आप इस प्रकार के रिग्रेशन को कैसे रोकेंगे?

कुछ साझा लेयर स्वामियों का दस्तावेजीकरण करें, पुन: प्रयोज्य ओवरले प्लेसमेंट को केंद्रीकृत करें, और ऐसी इंटरैक्शन स्टोरीज़ जोड़ें जो स्टिकी सामग्री, स्क्रॉल कंटेनर, मेनू और मोडल को जोड़ती हैं। एज प्लेसमेंट, स्क्रॉल, ज़ूम, कीबोर्ड व्यवहार और अन्य सक्रिय ओवरले को सत्यापित करें; केवल एक स्थिर स्नैपशॉट अनुबंध को सिद्ध नहीं कर सकता है।

सार्वजनिक स्रोत

संबंधित प्रश्न