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

Mathias Bynens

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

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

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

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

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

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

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

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

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

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

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

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

सामान्य दृष्टि वाले डेवलपर के तौर पर, आपको 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) एसवीजी फ़िल्टर की परिभाषा, जो फ़िलहाल डीओएम का हिस्सा है.

<!-- 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>
  <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>

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

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

ध्यान दें कि इस तकनीक से, हमें एसवीजी फ़िल्टर की पूरी सुविधाएं मिलती हैं. इसके लिए, हमें कुछ भी फिर से लागू करने या कुछ नया करने की ज़रूरत नहीं होती. हम 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;
}

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

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

नतीजा

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

  • हमने सबसे पहले, डेटा यूआरएल को इनलाइन करके अपने प्रोटोटाइप को ज़्यादा बेहतर बनाया.
  • इसके बाद, हमने उन इंटरनल डेटा यूआरएल को सीएसपी के हिसाब से बनाया. इसके लिए, हमने उनके लोड होने के तरीके में बदलाव किया.
  • हमने स्टाइल को Blink के अंदर मौजूद viewport में ले जाकर, इसे लागू करने की प्रोसेस को डीओएम से अलग और प्रोग्राम के हिसाब से निगरानी से बाहर कर दिया है.

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

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

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

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

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

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