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

Mathias Bynens

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

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

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

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

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

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

• वेब पेज पर सबसे ऊपर मौजूद 'जांच मोड' टूलटिप में, टेक्स्ट एलिमेंट का कंट्रास्ट रेशियो दिखता है.
• DevTools का कलर पिकर, टेक्स्ट एलिमेंट के लिए खराब कंट्रास्ट अनुपात की जानकारी देता है. साथ ही, बेहतर रंगों को मैन्युअल तरीके से चुनने में मदद करने के लिए, सुझाई गई कंट्रास्ट लाइन दिखाता है. यह ऐसे रंगों के सुझाव भी दे सकता है जिन्हें आसानी से पढ़ा जा सकता है.
• सीएसएस की खास जानकारी वाला पैनल और लाइटहाउस सुलभता की ऑडिट रिपोर्ट, दोनों में आपके पेज पर कम कंट्रास्ट वाले टेक्स्ट एलिमेंट की सूची होती है.

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

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

कलर विज़न की कमियां

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

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

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

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

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

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

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

• ऐसा हो सकता है कि पेज के रूट एलिमेंट पर पहले से ही एक फ़िल्टर मौजूद हो, जिसे हमारा कोड बदल सकता है.
• ऐसा हो सकता है कि पेज में पहले से ही id="deuteranopia" वाला एलिमेंट मौजूद हो और यह हमारे फ़िल्टर की परिभाषा से मेल न खाता हो.
• हो सकता है कि पेज किसी खास डीओएम स्ट्रक्चर पर निर्भर हो. ऐसे में, डीओएम में <svg> डालने पर, इन मान्यताओं का उल्लंघन हो सकता है.

इस तरीके में, एज केस के अलावा एक और समस्या है. यह समस्या यह है कि हम पेज में ऐसे बदलाव कर रहे हैं जिन्हें प्रोग्राम के ज़रिए देखा जा सकता है. अगर कोई DevTools उपयोगकर्ता DOM की जांच करता है, तो उसे अचानक ऐसा <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 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 फ़ाइल के तौर पर सेव कर सकते हैं. साथ ही, अपने HTML दस्तावेज़ में CSS 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 फ़िल्टर की पूरी क्षमता का ऐक्सेस देती है. हम Blink रेंडरर की सुविधा लागू कर रहे हैं. हालांकि, हम ऐसा वेब प्लैटफ़ॉर्म का फ़ायदा उठाकर कर रहे हैं.

ठीक है, हमने एसवीजी फ़िल्टर बनाने और उन्हें डेटा यूआरएल में बदलने का तरीका जान लिया है. इनका इस्तेमाल, सीएसएस filter प्रॉपर्टी वैल्यू में किया जा सकता है. क्या आपको इस तकनीक में कोई समस्या आ रही है? ऐसा लगता है कि हम सभी मामलों में लोड किए जा रहे डेटा यूआरएल पर भरोसा नहीं कर सकते, क्योंकि टारगेट पेज पर ऐसा Content-Security-Policy हो सकता है जो डेटा यूआरएल को ब्लॉक करता हो. Blink-लेवल पर लागू किए गए हमारे फ़ाइनल वर्शन में, लोड करने के दौरान इन “इंटरनल” डेटा यूआरएल के लिए सीएसपी को बायपास करने का खास ध्यान रखा जाता है.

ऐज केस को छोड़कर, हमने कुछ अच्छी तरक्की की है. अब हम एक ही दस्तावेज़ में इनलाइन <svg> के मौजूद होने पर निर्भर नहीं हैं. इसलिए, हमने अपने समाधान को कम करके, सिर्फ़ एक सीएसएस filter प्रॉपर्टी की परिभाषा कर दिया है. बढ़िया! अब इसे भी हटा दें.

दस्तावेज़ में मौजूद सीएसएस डिपेंडेंसी से बचना

हमने अब तक जो काम किए हैं उनके बारे में यहां बताया गया है:

<style>
  :root {
    filter: url('data:…');
  }
</style>

हम अब भी इस सीएसएस filter प्रॉपर्टी पर निर्भर हैं. इससे, असली दस्तावेज़ में मौजूद filter को बदला जा सकता है और चीज़ें गड़बड़ हो सकती हैं. DevTools में आपके दिए गए फ़ॉर्मूला के आधार पर तैयार किए गए स्टाइल की जांच करते समय भी यह दिखेगा, जिससे भ्रम की स्थिति पैदा होगी. इन समस्याओं से कैसे बचा जा सकता है? हमें दस्तावेज़ में फ़िल्टर जोड़ने का ऐसा तरीका ढूंढना होगा जिससे डेवलपर, प्रोग्राम के हिसाब से उस फ़िल्टर को न देख पाएं.

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

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

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

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

झलक वाले चैनल डाउनलोड करना

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

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

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

• crbug.com पर जाकर, हमें सुझाव/राय दें या शिकायत करें. साथ ही, किसी सुविधा का अनुरोध करें.
• DevTools में more_vert ज़्यादा विकल्प > सहायता > DevTools से जुड़ी समस्या की शिकायत करें का इस्तेमाल करके DevTools से जुड़ी समस्या की शिकायत करें.
• @ChromeDevTools पर ट्वीट करें.
• DevTools YouTube वीडियो में नया क्या है या DevTools सलाह YouTube वीडियो पर टिप्पणी की जा सकती हैं.