ब्लिंक रेंडरर में कलर विज़न की कमियों को सिम्युलेट करना

मथायस बायनस
माथियास बायनेंस

इस लेख में बताया गया है कि हमने DevTools और ब्लिंक रेंडरर में, कलर विज़न की कमी से जुड़े सिम्युलेशन को क्यों और कैसे लागू किया.

बैकग्राउंड: रंगों का खराब कंट्रास्ट

कम कंट्रास्ट टेक्स्ट, वेब पर अपने-आप पहचानी जा सकने वाली सुलभता से जुड़ी सबसे आम समस्या है.

वेब पर सामान्य सुलभता समस्याओं की एक सूची. अब तक, कम कंट्रास्ट वाला टेक्स्ट सबसे आम समस्या है.

WebAIM की ओर से शीर्ष 10 लाख वेबसाइटों के सुलभता विश्लेषण के मुताबिक, 86% से ज़्यादा होम पेजों का कंट्रास्ट कम है. औसतन, हर होम पेज पर कम कंट्रास्ट वाले टेक्स्ट के 36 अलग-अलग इंस्टेंस होते हैं.

कंट्रास्ट से जुड़ी समस्याओं को खोजने, समझने, और ठीक करने के लिए DevTools का इस्तेमाल करना

Chrome DevTools, कंट्रास्ट को बेहतर बनाने और वेब ऐप्लिकेशन के लिए ज़्यादा आसान कलर स्कीम चुनने में डेवलपर और डिज़ाइनर की मदद कर सकता है:

हमने हाल ही में इस सूची में एक नया टूल जोड़ा है और यह दूसरे टूल से अलग है. ऊपर दिए गए टूल मुख्य रूप से कंट्रास्ट अनुपात की जानकारी दिखाने और आपको ठीक करने के विकल्प देने पर फ़ोकस करते हैं. हमें पता चला कि डेवलपर के लिए समस्या की इस जगह को गहराई से understanding का तरीका अब भी DevTools से छूट रहा है. इसे ठीक करने के लिए, हमने DevTools रेंडरिंग टैब में दृष्टि की कमी का सिम्युलेशन लागू किया.

Puppeteer में, नए page.emulateVisionDeficiency(type) API की मदद से, इन सिम्युलेशन को प्रोग्राम के हिसाब से चालू किया जा सकता है.

रंगों की पहचान न कर पाना

करीब 20 में से 1 व्यक्ति कलर विज़न की कमी से पीड़ित होता है. इसे "कलर ब्लाइंडनेस" शब्द के तौर पर भी जाना जाता है. यह कम सटीक शब्द होता है. इस तरह की शारीरिक दिक्कतों से, अलग-अलग रंगों में अंतर कर पाना मुश्किल हो जाता है. इससे कंट्रास्ट की समस्याएं बढ़ सकती हैं.

पिघले हुए क्रेयॉन की रंग-बिरंगी तस्वीर, जिसमें किसी रंग से जुड़ी क्षमता से जुड़ी कोई गड़बड़ी नहीं है
पिले हुए क्रेयॉन की एक रंगीन फ़ोटो, जिसमें किसी रंग की पहचान से जुड़ी कोई कमी नहीं दिखाई गई है.
ALT_TEXT_HERE
पिघले हुए क्रेयॉन की रंगीन तस्वीर पर, ऐक्रोमेटॉप्सिया सिम्युलेट करने का असर.
पिघले हुए क्रेयॉन की रंगीन तस्वीर पर, ड्यूटरनोपिया को सिम्युलेट करने का असर.
पिघले हुए क्रेयॉन की रंगीन तस्वीर पर, डीयूरेनोपिया को सिम्युलेट करने का असर.
पिघले हुए क्रेयॉन की रंगीन तस्वीर पर, प्रोटानोपिया को सिम्युलेट करने का असर.
पिघले हुए क्रेयॉन की रंगीन तस्वीर पर, प्रोटानोपिया को सिम्युलेट करने का असर.
पिघले हुए क्रेयॉन की रंगीन तस्वीर पर, ट्रिटानोपिया की समस्या को सिम्युलेट करने का असर.
पिघले हुए क्रेयॉन की रंगीन तस्वीर पर, ट्रिटैनोपिया को सिम्युलेट करने का असर.

सामान्य दृष्टि वाले डेवलपर के तौर पर, आपको DevTools दिख सकता है. यह उन रंगों के लिए खराब कंट्रास्ट अनुपात दिखाता है जो आपको ठीक से दिखते हैं. ऐसा इसलिए होता है, क्योंकि कंट्रास्ट अनुपात वाले फ़ॉर्मूला में कलर विज़न की कमियों का ध्यान रखा जाता है! आप कुछ मामलों में अब भी कम कंट्रास्ट वाले टेक्स्ट को पढ़ सकते हैं, लेकिन दृष्टि बाधित लोगों में यह सुविधा नहीं होती.

डिज़ाइनर और डेवलपर को यह सुविधा देने से कि वे अपने वेब ऐप्लिकेशन पर दृष्टि की इन कमियों के असर को कैसे सिम्युलेट कर सकते हैं, हम इस टूल की मदद से वे चीज़ें उपलब्ध कराना चाहते हैं जो मौजूद नहीं हैं: DevTools से न सिर्फ़ आपको कंट्रास्ट से जुड़ी समस्याओं को ढूंढने और ठीक करने में मदद मिलेगी, बल्कि अब उन्हें समझना भी होगा!

एचटीएमएल, सीएसएस, SVG, और C++ की मदद से कलर विज़न की कमियों को सिम्युलेट करना

इससे पहले कि हम ब्लिंक रेंडरर को लागू करने वाली हमारी सुविधा के बारे में विस्तार से जानें, इससे हमें यह समझने में मदद मिलेगी कि वेब टेक्नोलॉजी का इस्तेमाल करके, ऐसी सुविधाएं किस तरह से लागू की जा सकती हैं.

कलर विज़न की कमी के इन सिम्युलेशन में से हर एक को ऐसे ओवरले के तौर पर देखा जा सकता है जो पूरे पेज को कवर करता है. वेब प्लैटफ़ॉर्म में ऐसा करने का तरीका बताया गया है: सीएसएस फ़िल्टर! सीएसएस 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 के लिए मल्टीप्लायर (बाएं से दाएं). साथ ही, कॉन्सटेंट शिफ़्ट वैल्यू के लिए पांचवीं वैल्यू. इसमें 4 पंक्तियां होती हैं: मैट्रिक्स की पहली पंक्ति का इस्तेमाल नए लाल मान का पता लगाने के लिए किया जाता है. दूसरी पंक्ति ग्रीन, तीसरी पंक्ति ब्लू, और आखिरी पंक्ति ऐल्फ़ा का पता लगाने के लिए इस्तेमाल किया जाता है.

आपको लग रहा होगा कि हमारे उदाहरण में सटीक आंकड़े कहां से मिले हैं. यह कलर मैट्रिक्स, डीयूरेनोपिया के बारे में सबसे सही जानकारी क्यों देता है? जवाब है: विज्ञान! ये मान मकाडो, ओलिवेरा, और फ़र्नांडीस के शारीरिक तौर पर सटीक कलर विज़न डेफ़िशलिटी सिम्युलेशन मॉडल पर आधारित हैं.

खैर, हमारे पास यह SVG फ़िल्टर है और अब हम इसे सीएसएस का इस्तेमाल करके, पेज पर मौजूद आर्बिट्रेरी एलिमेंट पर लागू कर सकते हैं. देखने से जुड़ी दूसरी कमियों के लिए भी हम इसी पैटर्न को दोहरा सकते हैं. यह कैसा दिखता है, इसका डेमो यहां दिया गया है:

अगर हम चाहें, तो DevTools सुविधा को इस तरह से बनाया जा सकता है: जब कोई उपयोगकर्ता DevTools यूज़र इंटरफ़ेस (यूआई) में किसी दृष्टि की कमी को एम्युलेट करता है, तब हम जांच किए गए दस्तावेज़ में SVG फ़िल्टर इंजेक्ट करते हैं. इसके बाद, हम रूट एलिमेंट पर फ़िल्टर स्टाइल लागू करते हैं. हालांकि, इस तरीके में कई समस्याएं हैं:

  • हो सकता है कि पेज के रूट एलिमेंट में पहले से ही एक फ़िल्टर मौजूद हो, जिसे हमारा कोड बदल सकता है.
  • हो सकता है कि पेज में पहले से ही id="deuteranopia" वाला कोई एलिमेंट मौजूद हो, जो कि हमारी फ़िल्टर की परिभाषा से मेल न खाता हो.
  • ऐसा हो सकता है कि यह पेज किसी खास DOM स्ट्रक्चर पर निर्भर हो. साथ ही, डीओएम में <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 डिपेंडेंसी से बचना

चलिए, दूसरे हिस्से से शुरुआत करते हैं: DOM में SVG फ़ाइल जोड़ने से कैसे बचा जा सकता है? इसका एक आइडिया यह है कि इसे किसी अलग 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-इन-एचटीएमएल, दोनों ही इस /> शॉर्टहैंड के साथ काम करते हैं, इसलिए हम इसका इस्तेमाल कर सकते हैं.

खैर, उन बदलावों के साथ, आखिर में हम इसे एक मान्य 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>

इसका फ़ायदा यह है कि अब हमें फ़ाइल को कहीं भी सेव करने की ज़रूरत नहीं है. इसके अलावा, हमें इसे अपने एचटीएमएल दस्तावेज़ में इस्तेमाल करने के लिए, डिस्क या नेटवर्क पर लोड करने की भी ज़रूरत नहीं है. इसलिए, पहले की तरह फ़ाइल नाम के बजाय, अब हम डेटा यूआरएल की ओर इशारा कर सकते हैं:

<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 कोड में बदलने की ज़रूरत नहीं है—ऐसा करने से सिर्फ़ कॉन्टेंट को पढ़ना मुश्किल होगा और फ़ाइल का साइज़ बढ़ जाएगा. हम हर लाइन के आखिर में बैकस्लैश जोड़ते हैं, ताकि यह पक्का किया जा सके कि डेटा यूआरएल में न्यूलाइन वर्ण, सीएसएस स्ट्रिंग लिटरल को खत्म न करें.

अब तक, हमने सिर्फ़ इस बारे में बात की है कि वेब टेक्नोलॉजी का इस्तेमाल करके देखने से जुड़ी समस्याओं को ठीक कैसे करें. दिलचस्प बात यह है कि ब्लिंक रेंडरर में, इसे लागू करने का हमारा तरीका भी काफ़ी हद तक मिलता-जुलता है. यहां 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 की एक ऐसी नई सीएसएस प्रॉपर्टी बनाने का सुझाव दिया जो filter की तरह काम करती हो, लेकिन उसका नाम अलग हो, जैसे कि --internal-devtools-filter. इसके बाद, हम खास लॉजिक जोड़ सकते हैं, ताकि यह पक्का किया जा सके कि यह प्रॉपर्टी कभी भी DevTools या डीओएम में कंप्यूट किए गए स्टाइल में न दिखे. हम यह भी पक्का कर सकते हैं कि यह सिर्फ़ उस एक एलिमेंट पर काम करे, जिस पर हमें इसकी ज़रूरत है: रूट एलिमेंट. हालांकि, यह तरीका कारगर नहीं होगा: हम ऐसे फ़ंक्शन की डुप्लीकेट कॉपी बनाएंगे जो filter में पहले से मौजूद है. अगर हम इस नॉन-स्टैंडर्ड प्रॉपर्टी को छिपाने की पूरी कोशिश करते हैं, तब भी वेब डेवलपर इसके बारे में पता लगा सकते हैं और इसका इस्तेमाल शुरू कर सकते हैं. हालांकि, यह वेब प्लैटफ़ॉर्म के लिए ठीक नहीं है. सीएसएस स्टाइल को लागू करने के लिए, हमें कोई दूसरा तरीका चाहिए. हालांकि, इसकी जानकारी डीओएम में देखी नहीं जा सकती. कोई आइडिया?

सीएसएस की खास जानकारी में, इस्तेमाल किए जाने वाले विज़ुअल फ़ॉर्मैटिंग मॉडल के बारे में बताने वाला एक सेक्शन है. इसका एक मुख्य सिद्धांत व्यूपोर्ट है. यह विज़ुअल व्यू होता है, जिससे उपयोगकर्ता वेब पेज को देखते हैं. इससे मिलता-जुलता सिद्धांत है शुरुआती ब्लॉक. यह स्टाइल किए जा सकने वाले व्यूपोर्ट <div> की तरह होता है, जो सिर्फ़ खास जानकारी के लेवल पर मौजूद होता है. यह स्पेसिफ़िकेशन पूरे जगह के इस “व्यूपोर्ट” कॉन्सेप्ट के बारे में बताता है. उदाहरण के लिए, आपको पता है कि कॉन्टेंट के फ़िट न होने पर ब्राउज़र स्क्रोलबार कैसे दिखाता है? इस “व्यूपोर्ट” के आधार पर, यह सब सीएसएस स्पेसिफ़िकेशन में बताया गया है.

यह viewport, ब्लिंक रेंडरर में और लागू करने से जुड़ी जानकारी में भी मौजूद होता है. यहां वह कोड दिया गया है जो निर्देशों के मुताबिक, डिफ़ॉल्ट व्यूपोर्ट स्टाइल लागू करता है:

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;
}

यह देखने के लिए कि यह कोड व्यूपोर्ट (या ज़्यादा सटीक रूप से: शुरुआती ब्लॉक वाले) z-index, display, position, और overflow को हैंडल करता है, आपको C++ या Blink के स्टाइल इंजन की बारीकियों को समझने की ज़रूरत नहीं है. शायद आपको सीएसएस के इन सभी कॉन्सेप्ट के बारे में पता होगा! कॉन्टेक्स्ट को स्टैक करने से जुड़े और भी फ़ायदे हैं, जो किसी सीएसएस प्रॉपर्टी का सीधे तौर पर अनुवाद नहीं करते. हालांकि, इस viewport ऑब्जेक्ट को Blink में सीएसएस का इस्तेमाल करके स्टाइल किया जा सकता है. ठीक वैसे ही जैसे किसी DOM एलिमेंट में किया जाता है. हालांकि, यह DOM का हिस्सा नहीं है.

इससे हमें वह मिलता है जो हम चाहते हैं! हम viewport ऑब्जेक्ट पर अपनी filter स्टाइल लागू कर सकते हैं, जो मॉनिटर की जा सकने वाली पेज स्टाइल या DOM में किसी भी तरह से रुकावट डाले बिना, रेंडरिंग पर विज़ुअल तौर पर असर डालता है.

नतीजा

यहां अपनी इस छोटी सी यात्रा को फिर से याद करने के लिए, हमने C++ के बजाय वेब टेक्नोलॉजी का इस्तेमाल करके एक प्रोटोटाइप बनाना शुरू किया. इसके बाद, इसके कुछ हिस्सों को ब्लिंक रेंडरर पर ले जाने का काम शुरू किया.

  • हमने सबसे पहले डेटा यूआरएल को इनलाइन करके अपने प्रोटोटाइप को ज़्यादा आत्म-निर्भर बनाया.
  • इसके बाद, हमने इंटरनल डेटा के यूआरएल को सीएसपी के हिसाब से बना दिया. ऐसा खास तौर पर, लोड होने के दौरान किया गया.
  • हमने स्टाइल को Blink-internal viewport में ले जाकर, लागू किए गए DOM-एग्नोस्टिक और प्रोग्राम के हिसाब से, अपने-आप होने वाली प्रोसेस को मॉनिटर नहीं किया.

इस प्रोसेस को लागू करने के बारे में खास बात यह है कि हमारे एचटीएमएल/सीएसएस/SVG फ़ॉर्मैट के प्रोटोटाइप ने आखिरी तकनीकी डिज़ाइन पर असर डाला. हमें वेब प्लैटफ़ॉर्म को इस्तेमाल करने का तरीका मिल गया है, यहां तक कि ब्लिंक रेंडरर पर भी!

ज़्यादा जानकारी के लिए, हमारा डिज़ाइन प्रस्ताव या Chromium ट्रैकिंग बग देखें. इसमें मिलते-जुलते सभी पैच के बारे में बताया गया है.

झलक दिखाने वाले चैनलों को डाउनलोड करना

अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर, Chrome Canary, Dev या बीटा का इस्तेमाल करें. झलक दिखाने वाले इन चैनलों की मदद से, आपको DevTools की नई सुविधाओं का ऐक्सेस मिलता है. साथ ही, सबसे नए वेब प्लैटफ़ॉर्म एपीआई को टेस्ट किया जा सकता है और उपयोगकर्ताओं के आने से पहले ही अपनी साइट पर समस्याओं का पता लगाया जा सकता है!

Chrome DevTools टीम से संपर्क करना

पोस्ट में हुई नई सुविधाओं और बदलावों या DevTools से जुड़ी किसी भी चीज़ के बारे में, नीचे दिए गए विकल्पों का इस्तेमाल करें.

  • crbug.com के ज़रिए हमें कोई सुझाव या सुझाव सबमिट करें.
  • DevTools में ज़्यादा विकल्प   ज़्यादा दिखाएं   > सहायता > DevTools से जुड़ी समस्याओं की शिकायत करें का इस्तेमाल करके, DevTools से जुड़ी समस्या की शिकायत करें.
  • @ChromeDevTool पर ट्वीट करें.
  • हमारे DevTools YouTube वीडियो या DevTools सलाह YouTube वीडियो में नया क्या है पर टिप्पणी करें.