प्रॉम्प्ट और दायरा
एक क्रॉस-ब्राउज़र डिज़ाइन सिस्टम उन जगहों पर स्वाभाविक एंट्री एनिमेशन और व्यू ट्रांज़िशन चाहता है जहाँ नए CSS at-rules समर्थित हैं, जबकि अन्य जगहों पर एक स्थिर अनुभव बनाए रखता है। 2026 का Chrome Web UI अपडेट @supports के अंदर विशिष्ट at-rules की पहचान करने का वर्णन करता है। एक ऐसा रोलआउट डिज़ाइन करें जो फ़र्स्ट पेंट, एक्सेसिबिलिटी और थीम की निरंतरता को बनाए रखे।
इंटरव्यूअर क्या जांच रहा है
इंटरव्यूअर यह जांच रहा है कि क्या आप सिंटैक्स पहचान को पूर्ण व्यवहार से अलग करते हैं, और क्या आप कैस्केड लेयर्स, फ़ॉलबैक, रिड्यूस्ड-मोशन हैंडलिंग, सर्वर रेंडरिंग और मॉनिटरिंग डिज़ाइन कर सकते हैं। एक मजबूत उत्तर क्षमता परीक्षण के रूप में ब्राउज़र नामों को हार्ड-कोड करने से बचता है।
पहले स्पष्ट करने योग्य प्रश्न
- क्या एन्हांसमेंट केवल सजावटी है, या इंटरैक्शन किसी ट्रांज़िशन के पूरा होने पर निर्भर करता है?
- जब नया नियम असमर्थित हो तो न्यूनतम स्वीकार्य अनुभव क्या है?
prefers-reduced-motion, उच्च कंट्रास्ट और कीबोर्ड संचालन को प्राथमिकता कैसे मिलती है?- क्या रोलआउट में एम्बेडेड WebViews, पुराने ब्राउज़र और एक SSR फ़र्स्ट पेंट शामिल होना चाहिए?
30-सेकंड का उत्तर
“मैं बेस लेआउट, अवस्थाओं (states) और इंटरैक्शन को डिफ़ॉल्ट CSS में पूर्ण बनाऊँगा, फिर at-rule क्षमता क्वेरी के पीछे वैकल्पिक शैलियाँ जोड़ूँगा। पहचान केवल यह तय करती है कि एन्हांसमेंट को सक्षम किया जाए या नहीं; यह रनटाइम स्थिति या एक्सेसिबिलिटी जांच को प्रतिस्थापित नहीं करती है, और रिड्यूस्ड मोशन हमेशा प्राथमिकता पाता है। पुराने ब्राउज़रों को एक स्थिर नो-एनिमेशन पाथ मिलता है जबकि सक्षम ब्राउज़रों को ट्रांज़िशन मिलते हैं। मैं विस्तार करने से पहले एक वास्तविक ब्राउज़र मैट्रिक्स, विज़ुअल रिग्रेशन, कीबोर्ड संचालन और फ़र्स्ट-पेंट मेट्रिक्स को सत्यापित करूँगा।”
चरण-दर-चरण समाधान
1. बेसलाइन अनुभव को परिभाषित करें
डिफ़ॉल्ट लेयर में एनीमेशन-एंड इवेंट पर निर्भर किए बिना पूर्ण लेआउट, फ़ोकस शैलियाँ, त्रुटि फ़ीडबैक और कार्रवाई योग्य अवस्थाएँ शामिल होनी चाहिए। अनमाउंट, रूट परिवर्तन और नेटवर्क विफलताओं को अभी भी सीधे लक्ष्य स्थिति तक पहुँचना चाहिए।
2. क्षमता को स्थिति से अलग करें
at-rule समर्थन को CSS क्षमता लेयर में रखें और कंपोनेंट अवस्थाओं जैसे open या leaving को क्लासेज या एट्रिब्यूट्स में रखें। एक क्षमता क्वेरी यह उत्तर देती है कि क्या ब्राउज़र किसी नियम को पार्स कर सकता है; अवस्था चयन यह उत्तर देता है कि कंपोनेंट को अब क्या दिखाना चाहिए। वे एक ही ब्राउज़र शाखा नहीं हैं।
3. कैस्केड और फ़ॉलबैक को व्यवस्थित करें
पहले बेस नियमों को लोड करें, फिर @supports के अंदर एन्हांसमेंट नियम जोड़ें। एन्हांसमेंट को केवल वैकल्पिक प्रॉपर्टीज़ को ओवरराइड करना चाहिए; जब पार्सिंग विफल हो जाती है, तो अज्ञात ब्लॉक को बेस शैलियों को नुकसान पहुँचाए बिना अनदेखा कर दिया जाना चाहिए। एन्हांसमेंट को महत्वपूर्ण बेस आयामों (dimensions) या रंगों को रीसेट न करने दें।
4. मोशन प्राथमिकताओं का सम्मान करें
एन्हांसमेंट लेयर के भीतर, फ़ोकस, बंद करने और त्रुटि फ़ीडबैक को स्पष्ट रखते हुए, ट्रांज़िशन को छोटा या अक्षम करके prefers-reduced-motion: reduce का सम्मान करें। व्यू ट्रांज़िशन का समर्थन कभी भी उपयोगकर्ता की प्राथमिकता पर हावी नहीं होता है।
5. SSR और WebViews को कवर करें
पहले HTML को क्लाइंट डिटेक्शन की प्रतीक्षा नहीं करनी चाहिए। सर्वर पर बेसलाइन संरचना को रेंडर करें और क्लाइंट को वैकल्पिक एन्हांसमेंट जोड़ने दें। ब्लैंक स्क्रीन और लेआउट शिफ्ट को खारिज करने के लिए एम्बेडेड WebViews, पुराने ब्राउज़रों, आंशिक समर्थन और अक्षम एनीमेशन का परीक्षण करें।
6. सत्यापित करें और रिलीज़ करें
एक ब्राउज़र और फीचर मैट्रिक्स बनाएं, फिर विज़ुअल रिग्रेशन, कीबोर्ड और स्क्रीन-रीडर जांच, CLS/LCP तुलना और नमूना त्रुटि लॉग चलाएं। पहले एक कंपोनेंट या कम जोखिम वाले पेज को कैनरी रिलीज़ करें; यदि रिग्रेशन या शिकायतें बढ़ती हैं, तो एन्हांसमेंट स्विच को हटा दें और बेसलाइन पाथ को बनाए रखें।
मॉडल उत्तर
मैं पहले नए सिंटैक्स के बिना एक पूर्ण बेसलाइन लेआउट, स्टेट मॉडल और एक्सेसिबिलिटी व्यवहार को लागू करूँगा, फिर @supports at-rule क्वेरी के पीछे वैकल्पिक एनीमेशन जोड़ूँगा। क्वेरी पार्स क्षमता की जाँच करती है; कंपोनेंट स्थिति क्लासेज या एट्रिब्यूट्स में रहती है, और रिड्यूस्ड मोशन को उच्च प्राथमिकता प्राप्त होती है। SSR बेसलाइन HTML उत्सर्जित करता है, इसलिए एक विफल एन्हांसमेंट को अनदेखा कर दिया जाता है। रिलीज़ से पहले मैं CLS/LCP और त्रुटि फ़ीडबैक पर नज़र रखते हुए पुराने ब्राउज़रों, WebViews, SSR, कीबोर्ड संचालन और विज़ुअल रिग्रेशन का परीक्षण करूँगा। एक कंपोनेंट को कैनरी करें और यदि यह विफल हो जाता है तो केवल एन्हांसमेंट स्विच को अक्षम करें।
सामान्य गलतियाँ
- ब्राउज़र नामों पर ब्रांचिंग करना → यूज़र-एजेंट ड्रिफ्ट और गलत वर्गीकरण → क्षमताओं (capabilities) को क्वेरी करें।
- पार्सिंग समर्थन को पूर्ण व्यवहार मानना → आंशिक कार्यान्वयन भिन्न होते हैं → एक वास्तविक ब्राउज़र मैट्रिक्स और रिग्रेशन सूट चलाएं।
- एन्हांसमेंट को बेस आयामों को ओवरराइड करने देना → असमर्थित ब्राउज़र लेआउट को तोड़ देते हैं → केवल वैकल्पिक प्रॉपर्टीज़ को ओवरराइड करें।
- रिड्यूस्ड मोशन को अनदेखा करना → उपयोगकर्ता नियंत्रण खो देते हैं → एन्हांसमेंट लेयर में मीडिया क्वेरी को फिर से संभालें।
- फ़र्स्ट पेंट से पहले क्लाइंट डिटेक्शन की प्रतीक्षा करना → ब्लैंक स्क्रीन या लेआउट शिफ्ट → बेसलाइन अनुभव को SSR करें।
फ़ॉलो-अप प्रश्न और उत्तर
क्या फीचर पर भरोसा करने के लिए @supports का समर्थन पर्याप्त है?
नहीं। यह केवल बताता है कि पार्सर स्थिति को स्वीकार करता है। लक्षित ब्राउज़रों में विशिष्ट at-rule, इवेंट टाइमिंग और फ़ॉलबैक पाथ को सत्यापित करें।
पुराने CSS को क्यों न हटाएँ?
नई क्षमताएं WebViews, एंटरप्राइज ब्राउज़रों या सहायक-तकनीक (assistive-technology) परिवेशों में अनुपस्थित हो सकती हैं। बेसलाइन एक टिकाऊ अनुबंध है, जबकि एन्हांसमेंट स्वतंत्र रूप से हटाने योग्य होना चाहिए।
आप रिड्यूस्ड मोशन का परीक्षण कैसे करते हैं?
स्वचालित और मैन्युअल परीक्षणों में prefers-reduced-motion: reduce को सक्षम करें। पुष्टि करें कि एनीमेशन को छोटा करने या हटाने से भी फ़ोकस, स्थिति और क्लोज़ ऑपरेशन स्पष्ट रहते हैं।
एन्हांसमेंट डिफ़ॉल्ट कब बन सकता है?
केवल तब जब लक्षित कवरेज, विज़ुअल और एक्सेसिबिलिटी रिग्रेशन, परफॉरमेंस मेट्रिक्स और त्रुटि दरें गेट्स (gates) को पूरा करती हैं, जबकि बेसलाइन फ़ॉलबैक अभी भी उपलब्ध है।