इस लेख में बताया गया है कि हमने DevTools और ब्लिंक रेंडरर में कलर विज़न कम करने वाले सिम्युलेशन को क्यों और कैसे लागू किया.
बैकग्राउंड: खराब कलर कंट्रास्ट
कम कंट्रास्ट वाला टेक्स्ट, वेब पर अपने-आप पहचानी जा सकने वाली सुलभता की सबसे आम समस्या है.
WebAIM की टॉप 10 लाख वेबसाइटों के सुलभता विश्लेषण के मुताबिक, 86% से ज़्यादा होम पेजों का कंट्रास्ट कम होता है. औसतन, हर होम पेज पर कम कंट्रास्ट वाले टेक्स्ट के 36 अलग-अलग इंस्टेंस होते हैं.
कंट्रास्ट से जुड़ी समस्याओं को खोजने, समझने, और ठीक करने के लिए DevTools का इस्तेमाल करना
Chrome DevTools, कंट्रास्ट को बेहतर बनाने और वेब ऐप्लिकेशन के लिए ज़्यादा आसानी से ऐक्सेस की जा सकने वाली कलर स्कीम चुनने में डेवलपर और डिज़ाइनर की मदद कर सकता है:
- वेब पेज पर सबसे ऊपर मौजूद 'जांच मोड' टूलटिप में, टेक्स्ट एलिमेंट का कंट्रास्ट अनुपात दिखाया जाता है.
- DevTools कलर पिकर, टेक्स्ट एलिमेंट के लिए खराब कंट्रास्ट अनुपात को कॉल करता है. साथ ही, मैन्युअल तरीके से बेहतर रंग चुनने के लिए सुझाए गए कंट्रास्ट लाइन दिखाता है. साथ ही, यह ऐक्सेस किए जा सकने वाले रंग का सुझाव भी दे सकता है.
- सीएसएस की खास जानकारी वाला पैनल और लाइटहाउस सुलभता की ऑडिट रिपोर्ट, दोनों में आपके पेज पर कम कंट्रास्ट वाले टेक्स्ट एलिमेंट की सूची होती है.
हमने हाल ही में इस सूची में एक नया टूल जोड़ा है और यह अन्य टूल से कुछ अलग है. ऊपर दिए गए टूल मुख्य रूप से कंट्रास्ट अनुपात की जानकारी दिखाने पर फ़ोकस करते हैं. साथ ही, आपको इसे ठीक करने के विकल्प देते हैं. हमें पता चला कि डेवलपर के पास अब भी वह तरीका नहीं है जिसकी मदद से डेवलपर, इस समस्या को बेहतर तरीके से समझ सकें. इसे ठीक करने के लिए, हमने DevTools रेंडरिंग टैब में देखने की क्षमता में कमी का सिम्युलेशन लागू किया है.
Puppeteer में, नए page.emulateVisionDeficiency(type) एपीआई की मदद से, इन सिम्युलेशन को प्रोग्राम के हिसाब से चालू किया जा सकता है.
कलर विज़न की कमियां
करीब 20 में से एक व्यक्ति, कलर ब्लाइंडनेस की समस्या से पीड़ित है. इसे कम सटीक शब्द "कलर ब्लाइंडनेस" भी कहा जाता है. इस तरह की दिक्कतों से, अलग-अलग रंगों को पहचानने में मुश्किल होती है, जिससे कंट्रास्ट की समस्याएं बढ़ सकती हैं.
नियमित नज़र वाले डेवलपर के तौर पर, शायद आपको DevTools में उन रंगों के पेयर के लिए खराब कंट्रास्ट रेशियो दिखे जो विज़ुअल तौर पर आपकी पसंद के मुताबिक दिखते हैं. ऐसा इसलिए होता है, क्योंकि कंट्रास्ट रेशियो फ़ॉर्मूला, कलर विज़न की कमियों को ध्यान में रखता है! आप अब भी कुछ मामलों में कम कंट्रास्ट वाला टेक्स्ट पढ़ सकते हैं, लेकिन दृष्टिबाधित लोगों को यह अधिकार नहीं मिलता.
डिज़ाइनर और डेवलपर को उनके वेब ऐप्लिकेशन पर, दृष्टि की इन कमियों के असर को समझने की अनुमति देकर, हमारा मकसद है कि वे इसमें मौजूद सारी ज़रूरी जानकारी दें: DevTools न सिर्फ़ कंट्रास्ट से जुड़ी समस्याएं ढूंढने और उन्हें ठीक करने में आपकी मदद कर सकता है, बल्कि अब आप इन्हें समझ भी सकते हैं!
एचटीएमएल, CSS, SVG, और C++ का इस्तेमाल करके, कलर विज़न कमियों को सिम्युलेट करना
इससे पहले कि हम अपनी सुविधा के बारे में Blink रेंडरर लागू करें, हमें यह समझने में मदद मिलती है कि वेब टेक्नोलॉजी की मदद से आप इसके जैसी ही सुविधाएं कैसे लागू करेंगे.
कलर विज़न की कमी के हर सिम्युलेशन को एक ओवरले की तरह देखा जा सकता है, जो पूरे पेज को कवर कर लेता है. वेब प्लैटफ़ॉर्म में ऐसा किया जा सकता है: सीएसएस फ़िल्टर! सीएसएस filter प्रॉपर्टी का इस्तेमाल करके, पहले से तय कुछ फ़िल्टर फ़ंक्शन इस्तेमाल किए जा सकते हैं, जैसे कि blur, contrast, grayscale, hue-rotate वगैरह. ज़्यादा कंट्रोल के लिए, filter प्रॉपर्टी एक ऐसा यूआरएल भी स्वीकार करती है जो कस्टम SVG फ़िल्टर की परिभाषा पर ले जा सकता है:
<style>
:root {
filter: url(#deuteranopia);
}
</style>
<svg>
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000">
</feColorMatrix>
</filter>
</svg>
ऊपर दिए गए उदाहरण में, कलर मैट्रिक्स के आधार पर कस्टम फ़िल्टर की परिभाषा का इस्तेमाल किया गया है. वहीं, नया रंग बनाने के लिए, हर पिक्सल की [Red, Green, Blue, Alpha] कलर वैल्यू को मैट्रिक्स से गुणा किया जाता है [R′, G′, B′, A′].
मैट्रिक्स की हर लाइन में पांच वैल्यू होती हैं: R, G, B, और A के लिए एक मल्टीप्लायर (बाएं से दाएं के क्रम में) R, G, B, और A के लिए. साथ ही, कॉन्सटैंट शिफ़्ट वैल्यू के लिए पांचवां वैल्यू. इसमें चार पंक्तियां होती हैं: मैट्रिक्स की पहली पंक्ति का इस्तेमाल, लाल रंग की नई वैल्यू, दूसरी लाइन ग्रीन, तीसरी पंक्ति, और आखिरी पंक्ति ऐल्फ़ा का पता लगाने के लिए किया जाता है.
आप लोग सोच रहे होंगे कि हमारे उदाहरण में दी गई सटीक संख्याएं कहां से आती हैं. इस रंग मैट्रिक्स को ड्यूटीरानोपिया का अच्छा अनुमान क्यों लगता है? इसका जवाब है: विज्ञान! ये वैल्यू मशाडो, ऑलिवेरा, और फर्नांडीस के शारीरिक रूप से सटीक कलर विज़न डेफ़िशिएंसी सिम्युलेशन मॉडल पर आधारित हैं.
वैसे भी, हमारे पास यह SVG फ़िल्टर है और अब हम उसे सीएसएस का इस्तेमाल करके पेज पर आर्बिट्रेरी एलिमेंट पर लागू कर सकते हैं. देखने से जुड़ी अन्य समस्याओं के लिए भी यही पैटर्न दोहराया जा सकता है. यह कैसा दिखता है, इसके बारे में यहां एक डेमो दिया गया है:
अगर हम चाहें, तो DevTools की सुविधा को इस तरह से बनाया जा सकता है: जब कोई व्यक्ति, DevTools के यूज़र इंटरफ़ेस (यूआई) में दृष्टि की कमी को एम्युलेट करता है, तो हम जांच किए गए दस्तावेज़ में SVG फ़िल्टर इंजेक्ट करते हैं. इसके बाद, रूट एलिमेंट पर फ़िल्टर स्टाइल लागू करते हैं. हालांकि, इस तरीके में कई समस्याएं हैं:
- ऐसा हो सकता है कि पेज के रूट एलिमेंट पर पहले से ही एक फ़िल्टर मौजूद हो, जिसे हमारा कोड बदल सकता है.
- ऐसा हो सकता है कि पेज में पहले से ही
id="deuteranopia"वाला एलिमेंट मौजूद हो और यह हमारे फ़िल्टर की परिभाषा से मेल न खाता हो. - पेज एक खास डीओएम स्ट्रक्चर पर निर्भर हो सकता है. इसलिए, डीओएम में
<svg>को शामिल करने से, शायद इन अनुमानों का उल्लंघन हो.
एज मामलों को छोड़ दें, तो इस तरीके में मुख्य समस्या यह है कि हम पेज में प्रोग्राम के हिसाब से निगरानी करने लायक बदलाव करेंगे. अगर कोई DevTools इस्तेमाल करने वाला व्यक्ति डीओएम की जांच करता है, तो उसे अचानक ऐसा <svg> एलिमेंट दिख सकता है जिसे उसने कभी नहीं जोड़ा या ऐसा सीएसएस filter जो उसने कभी लिखा ही नहीं. इससे भ्रम की स्थिति पैदा होगी! DevTools में इस सुविधा को लागू करने के लिए, हमें एक ऐसा समाधान चाहिए जिसमें ये कमियां न हों.
आइए, देखते हैं कि कम रुकावट डालने वाला कॉन्टेंट कैसे बनाया जा सकता है. इस समाधान के दो हिस्सों को छिपाना होगा: 1) filter प्रॉपर्टी के साथ सीएसएस स्टाइल और 2) SVG फ़िल्टर की परिभाषा, जो फ़िलहाल डीओएम का हिस्सा है.
<!-- Part 1: the CSS style with the filter property -->
<style>
:root {
filter: url(#deuteranopia);
}
</style>
<!-- Part 2: the SVG filter definition -->
<svg>
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000">
</feColorMatrix>
</filter>
</svg>
दस्तावेज़ में मौजूद SVG डिपेंडेंसी से बचना
दूसरे हिस्से से शुरू करते हैं: हम SVG को DOM में जोड़ने से कैसे बच सकते हैं? इसका एक आइडिया यह है कि इसे एक अलग SVG फ़ाइल में ट्रांसफ़र करें. हम ऊपर दिए गए एचटीएमएल से <svg>…</svg> को कॉपी कर सकते हैं और इसे filter.svg के तौर पर सेव कर सकते हैं—लेकिन हमें पहले कुछ बदलाव करने होंगे! एचटीएमएल में इनलाइन SVG, एचटीएमएल पार्स करने के नियमों का पालन करता है. इसका मतलब यह है कि आप कुछ मामलों में एट्रिब्यूट की वैल्यू से जुड़े कोटेशन को हटाने जैसी चीज़ों को इस्तेमाल कर सकते हैं. हालांकि, अलग-अलग फ़ाइलों में SVG को मान्य एक्सएमएल होना चाहिए—और एक्सएमएल पार्स करना, एचटीएमएल की तुलना में ज़्यादा सख्त है. यहां हमारा SVG-in-HTML स्निपेट एक बार फिर से दिया गया है:
<svg>
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000">
</feColorMatrix>
</filter>
</svg>
इस मान्य स्टैंडअलोन SVG (और इस तरह एक्सएमएल) को बनाने के लिए हमें कुछ बदलाव करने होंगे. क्या आपको पता है कि कौनसा?
<svg xmlns="http://www.w3.org/2000/svg">
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000" />
</filter>
</svg>
पहला बदलाव, सबसे ऊपर एक्सएमएल नेमस्पेस का एलान है. दूसरा जोड़ा गया है, “सॉलिडस” — यह स्लैश से पता चलता है कि <feColorMatrix> टैग, एलिमेंट को खोलता और बंद करता है. हालांकि, यह आखिरी बदलाव ज़रूरी नहीं है (इसके बजाय, हम सिर्फ़ </feColorMatrix> क्लोज़िंग टैग का इस्तेमाल कर सकते हैं). हालांकि, एक्सएमएल और SVG-in-HTML, दोनों ही इस /> शॉर्टहैंड का इस्तेमाल करते हैं. इसलिए, हम इसका इस्तेमाल भी कर सकते हैं.
वैसे भी, इन बदलावों की वजह से, आखिर में हम इसे एक मान्य SVG फ़ाइल के तौर पर सेव कर सकते हैं. साथ ही, अपने एचटीएमएल दस्तावेज़ में सीएसएस filter प्रॉपर्टी की वैल्यू से इस पर कर्सर ले जा सकते हैं:
<style>
:root {
filter: url(filters.svg#deuteranopia);
}
</style>
हुर्राह, अब हमें दस्तावेज़ में SVG इंजेक्ट करने की ज़रूरत नहीं है! यह पहले से ही बहुत बेहतर है. लेकिन... अब हम एक अलग फ़ाइल पर निर्भर हैं. यह अब भी डिपेंडेंसी है. क्या हमें इससे छुटकारा मिल सकता है?
हम जानते हैं कि हमें किसी फ़ाइल की ज़रूरत नहीं होती. हम डेटा यूआरएल का इस्तेमाल करके, पूरी फ़ाइल को यूआरएल में कोड में बदल सकते हैं. इसके लिए, हम SVG फ़ाइल का कॉन्टेंट लेते हैं, data: प्रीफ़िक्स जोड़ते हैं, सही MIME टाइप कॉन्फ़िगर करते हैं, और हमें एक मान्य डेटा यूआरएल मिलता है जो उसी SVG फ़ाइल का प्रतिनिधित्व करता है:
data:image/svg+xml,
<svg xmlns="http://www.w3.org/2000/svg">
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000" />
</filter>
</svg>
इसका लाभ यह है कि अब हमें फ़ाइल को अपने HTML दस्तावेज़ में उपयोग करने के लिए कहीं भी संग्रहित करने या डिस्क से या नेटवर्क पर लोड करने की आवश्यकता नहीं होती. पहले की तरह फ़ाइल नाम पर जाने के बजाय, अब हम डेटा यूआरएल पर कर्सर ले जा सकते हैं:
<style>
:root {
filter: url('data:image/svg+xml,\
<svg xmlns="http://www.w3.org/2000/svg">\
<filter id="deuteranopia">\
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000\
0.280 0.673 0.047 0.000 0.000\
-0.012 0.043 0.969 0.000 0.000\
0.000 0.000 0.000 1.000 0.000" />\
</filter>\
</svg>#deuteranopia');
}
</style>
पहले की तरह ही, यूआरएल के आखिर में भी हम उस फ़िल्टर का आईडी बताते हैं जिसका हमें इस्तेमाल करना है. ध्यान दें कि यूआरएल में SVG दस्तावेज़ को Base64-एन्कोड करने की ज़रूरत नहीं है. ऐसा करने से सिर्फ़ पढ़ने पर असर पड़ेगा और फ़ाइल का साइज़ बढ़ेगा. हमने हर लाइन के आखिर में बैकस्लैश जोड़ा है, ताकि यह पक्का किया जा सके कि डेटा यूआरएल में न्यूलाइन के वर्ण, सीएसएस स्ट्रिंग की लिटरल वैल्यू को खत्म न करें.
अब तक हमने सिर्फ़ इस बारे में बात की है कि वेब टेक्नोलॉजी की मदद से, दृष्टि कमियों को ठीक कैसे करें. दिलचस्प बात यह है कि Blink रेंडरर में हमारा आखिरी इंप्लीमेंटेशन असल में काफ़ी मिलता-जुलता है. यहां C++ हेल्पर यूटिलिटी दी गई है, जिसे हमने समान तकनीक पर आधारित, फ़िल्टर परिभाषा वाला डेटा यूआरएल बनाने के लिए जोड़ा है:
AtomicString CreateFilterDataUrl(const char* piece) {
AtomicString url =
"data:image/svg+xml,"
"<svg xmlns=\"http://www.w3.org/2000/svg\">"
"<filter id=\"f\">" +
StringView(piece) +
"</filter>"
"</svg>"
"#f";
return url;
}
साथ ही, यहां बताया गया है कि अपनी ज़रूरत के हिसाब से सभी फ़िल्टर बनाने के लिए, हम इसका इस्तेमाल किस तरह कर रहे हैं:
AtomicString CreateVisionDeficiencyFilterUrl(VisionDeficiency vision_deficiency) {
switch (vision_deficiency) {
case VisionDeficiency::kAchromatopsia:
return CreateFilterDataUrl("…");
case VisionDeficiency::kBlurredVision:
return CreateFilterDataUrl("<feGaussianBlur stdDeviation=\"2\"/>");
case VisionDeficiency::kDeuteranopia:
return CreateFilterDataUrl(
"<feColorMatrix values=\""
" 0.367 0.861 -0.228 0.000 0.000 "
" 0.280 0.673 0.047 0.000 0.000 "
"-0.012 0.043 0.969 0.000 0.000 "
" 0.000 0.000 0.000 1.000 0.000 "
"\"/>");
case VisionDeficiency::kProtanopia:
return CreateFilterDataUrl("…");
case VisionDeficiency::kTritanopia:
return CreateFilterDataUrl("…");
case VisionDeficiency::kNoVisionDeficiency:
NOTREACHED();
return "";
}
}
ध्यान दें कि यह तकनीक हमें किसी भी चीज़ को फिर से लागू किए या किसी व्हील को फिर से नया बनाए बिना, SVG फ़िल्टर की पूरी क्षमता का ऐक्सेस देती है. हम ब्लिंक रेंडरर सुविधा लागू कर रहे हैं, लेकिन हम वेब प्लैटफ़ॉर्म का इस्तेमाल करके ऐसा कर रहे हैं.
ठीक है, हम SVG फ़िल्टर को बनाने और उन्हें डेटा यूआरएल में बदलने का तरीका पता लगा चुके हैं. इसका इस्तेमाल हम सीएसएस filter प्रॉपर्टी की वैल्यू में कर सकते हैं. क्या आपको इस तकनीक में कोई समस्या आ रही है? ऐसा हो सकता है कि हम सभी मामलों में, लोड होने वाले डेटा यूआरएल पर भरोसा नहीं कर सकते. ऐसा इसलिए होता है, क्योंकि टारगेट पेज में ऐसा Content-Security-Policy हो सकता है जो डेटा यूआरएल को ब्लॉक करता है. हमारा फ़ाइनल ब्लिंक-लेवल लागू करने पर, लोड होने के दौरान इन "इंटरनल" डेटा यूआरएल के लिए सीएसपी को बायपास करने का खास ध्यान रखा जाता है.
किनारे की बातों को छोड़ दें, हमने कुछ अच्छी प्रगति की है. अब हम एक ही दस्तावेज़ में इनलाइन <svg> के मौजूद होने पर निर्भर नहीं हैं. इसलिए, हमने अपने समाधान को कम करके, सिर्फ़ एक सीएसएस filter प्रॉपर्टी की परिभाषा कर दिया है. बढ़िया! चलिए, अब इसे भी हटा लेते हैं.
दस्तावेज़ में मौजूद सीएसएस डिपेंडेंसी से बचना
आपको याद दिला दें कि हम अभी तक के प्रोग्राम में:
<style>
:root {
filter: url('data:…');
}
</style>
हम अब भी इस सीएसएस filter प्रॉपर्टी का इस्तेमाल करते हैं. इसकी वजह से, असल दस्तावेज़ में filter प्रॉपर्टी को छोड़कर, चीज़ों में गड़बड़ी आ सकती है. DevTools में आपके दिए गए फ़ॉर्मूला के आधार पर तैयार किए गए स्टाइल की जांच करते समय भी यह दिखेगा, जिससे भ्रम की स्थिति पैदा होगी. हम इन समस्याओं से कैसे बच सकते हैं? हमें दस्तावेज़ में कोई फ़िल्टर जोड़ने का तरीका खोजना होगा, ताकि डेवलपर को प्रोग्राम के हिसाब से फ़िल्टर न लगाया जा सके.
हमें एक आइडिया आया, जिसमें Chrome के लिए Chrome के अंदर की जाने वाली एक नई सीएसएस प्रॉपर्टी बनाई गई थी. यह प्रॉपर्टी, filter की तरह काम करती है, लेकिन उसका नाम अलग है, जैसे कि --internal-devtools-filter. इसके बाद, हम यह पक्का करने के लिए एक खास लॉजिक जोड़ सकते हैं कि यह प्रॉपर्टी, DevTools या DOM में कंप्यूट किए गए स्टाइल में कभी न दिखे. हम यह भी पक्का कर सकते हैं कि यह सिर्फ़ उस एक एलिमेंट पर काम करे जिसकी हमें ज़रूरत है: रूट एलिमेंट पर. हालांकि, यह समाधान सबसे बढ़िया नहीं होगा: हम filter में पहले से मौजूद फ़ंक्शन की डुप्लीकेट कॉपी बनाएंगे, और अगर हम इस गैर-मानक प्रॉपर्टी को छिपाने की पूरी कोशिश करते हैं, तब भी वेब डेवलपर इसके बारे में पता लगा सकते हैं और उसका उपयोग करना शुरू कर सकते हैं, जो वेब प्लैटफ़ॉर्म के लिए बुरा होगा. हमें सीएसएस स्टाइल को लागू करने का कोई दूसरा तरीका चाहिए, जो डीओएम में मॉनिटर किए बिना किया जा सके. कोई आइडिया है?
सीएसएस की खास बातों में एक सेक्शन है, जो इस्तेमाल किए जाने वाले विज़ुअल फ़ॉर्मैटिंग मॉडल के बारे में जानकारी देता है. साथ ही, व्यूपोर्ट भी इसके मुख्य सिद्धांतों में से एक है. यह एक ऐसा विज़ुअल व्यू है जिससे उपयोगकर्ता, वेब पेज से सलाह लेते हैं. एक काफ़ी मिलता-जुलता कॉन्सेप्ट शुरुआती ब्लॉक शामिल है, जो एक स्टाइल वाले व्यूपोर्ट <div> की तरह है जो सिर्फ़ स्पेसिफ़िकेशन लेवल पर मौजूद होता है. यह खास जानकारी, हर जगह "व्यूपोर्ट" के सिद्धांत से जुड़ी है. उदाहरण के लिए, आपको पता है कि कॉन्टेंट फ़िट न होने पर, ब्राउज़र स्क्रोलबार कैसे दिखाता है? यह पूरी जानकारी सीएसएस की खास जानकारी में, इस “व्यूपोर्ट” के आधार पर दी गई है.
यह viewport, Blink रेंडरर में मौजूद होता है. साथ ही, यह लागू करने की जानकारी के साथ-साथ इसमें भी मौजूद होता है. यहां कोड दिया गया है, जो स्पेसिफ़िकेशन के हिसाब से डिफ़ॉल्ट व्यूपोर्ट स्टाइल लागू करता है:
scoped_refptr<ComputedStyle> StyleResolver::StyleForViewport() {
scoped_refptr<ComputedStyle> viewport_style =
InitialStyleForElement(GetDocument());
viewport_style->SetZIndex(0);
viewport_style->SetIsStackingContextWithoutContainment(true);
viewport_style->SetDisplay(EDisplay::kBlock);
viewport_style->SetPosition(EPosition::kAbsolute);
viewport_style->SetOverflowX(EOverflow::kAuto);
viewport_style->SetOverflowY(EOverflow::kAuto);
// …
return viewport_style;
}
आपको C++ या Blink के स्टाइल इंजन की बारीकियों को समझने की ज़रूरत नहीं है, ताकि आप यह जान सकें कि यह कोड व्यूपोर्ट के (या ज़्यादा सटीक तरीके से: शुरुआती ब्लॉक वाले z-index, display, position, और overflow) को हैंडल करता है. सीएसएस के इन सभी सिद्धांतों के बारे में आपको शायद पता होगा! कॉन्टेक्स्ट को स्टैक करने से जुड़े इसके और भी फ़ायदे हैं, जो सीधे सीएसएस प्रॉपर्टी में नहीं बदलते, लेकिन कुल मिलाकर इस viewport ऑब्जेक्ट को ब्लिंक में जाकर सीएसएस का इस्तेमाल करके स्टाइल किया जा सकता है. यह बिलकुल एक डीओएम एलिमेंट की तरह है. हालांकि, यह डीओएम का हिस्सा नहीं है.
इससे हमें असल में वह मिलता है जो हमें चाहिए! हम viewport ऑब्जेक्ट पर अपनी filter स्टाइल लागू कर सकते हैं. इससे, रेंडरिंग पर असर पड़ता है. ऐसा, मॉनिटर किए जा सकने वाले पेज के स्टाइल या डीओएम में किसी भी तरह की रुकावट के बिना किया जा सकता है.
नतीजा
अपने इस छोटे से सफ़र को फिर से याद करने के लिए, हमने C++ के बजाय वेब तकनीक का इस्तेमाल करके एक प्रोटोटाइप बनाकर शुरुआत की और उसके कुछ हिस्सों को Blink रेंडरर में ले जाने पर काम करना शुरू किया.
- हमने सबसे पहले डेटा यूआरएल को इनलाइन करके अपने प्रोटोटाइप को और बेहतर बनाया.
- इसके बाद, हमने इंटरनल डेटा यूआरएल को सीएसपी-फ़्रेंडली बनाया. इसके लिए, हमने खास केस में लोड होने वाले यूआरएल इस्तेमाल किए.
- हमने स्टाइल को Blink-internal
viewportमें ले जाकर, लागू करने के तरीके के तौर पर DOM- फ़्लैग किए गए को सेट किया है.
इसे लागू करने की खास बात यह है कि हमारे एचटीएमएल/सीएसएस/SVG प्रोटोटाइप ने फ़ाइनल टेक्निकल डिज़ाइन पर असर डाला. हमें वेब प्लैटफ़ॉर्म को इस्तेमाल करने का तरीका मिल गया है, यहां तक कि ब्लिंक रेंडरर में भी!
ज़्यादा जानकारी के लिए, हमारे डिज़ाइन प्रपोज़ल या Chromium ट्रैकिंग बग देखें. इसमें, मिलते-जुलते सभी पैच के बारे में बताया गया है.
झलक दिखाने वाले चैनलों को डाउनलोड करें
Chrome Canary, Dev या बीटा को अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर इस्तेमाल करें. झलक दिखाने वाले इन चैनलों की मदद से, DevTools की नई सुविधाओं को ऐक्सेस किया जा सकता है और वेब प्लैटफ़ॉर्म के बेहतरीन एपीआई की जांच की जा सकती है. साथ ही, उपयोगकर्ताओं से पहले ही अपनी साइट की समस्याओं का पता लगाया जा सकता है!
Chrome DevTools की टीम से संपर्क करना
पोस्ट में नई सुविधाओं और बदलावों या DevTools से जुड़ी किसी भी अन्य चीज़ के बारे में चर्चा करने के लिए, नीचे दिए गए विकल्पों का इस्तेमाल करें.
- crbug.com के ज़रिए हमें कोई सुझाव या फ़ीडबैक सबमिट करें.
- ज़्यादा विकल्प
> का इस्तेमाल करके DevTools से जुड़ी समस्या की शिकायत करें सहायता > DevTools में DevTools से जुड़ी समस्याओं की शिकायत करें. - @ChromeDevTools पर ट्वीट करें.
- DevTools YouTube वीडियो या DevTools के बारे में सलाह YouTube वीडियो में नया क्या है, इस पर टिप्पणी करें.