निर्देश देने वाले सिंटैक्स

<picture> एलिमेंट अपने-आप कुछ भी रेंडर नहीं करता. इसके बजाय, यह किसी अंदरूनी <img> एलिमेंट के लिए फ़ैसले लेने वाले इंजन की तरह काम करता है, कि उसे क्या रेंडर करना है. <picture> एक ऐसे उदाहरण को फ़ॉलो करता है जिसे <audio> और <video> एलिमेंट ने पहले ही सेट कर दिया है: रैपर एलिमेंट जिसमें अलग-अलग <source> एलिमेंट हों.

<picture>
   <source …>
   <source …>
    <img …>
</picture …>

इनर <img> से, आपको पुराने ब्राउज़र के लिए भरोसेमंद फ़ॉलबैक पैटर्न मिलते हैं. साथ ही, इनमें रिस्पॉन्सिव इमेज भी काम नहीं करतीं: अगर उपयोगकर्ता के ब्राउज़र में <picture> एलिमेंट की पहचान नहीं होती, तो उसे अनदेखा कर दिया जाता है. इसके बाद, <source> एलिमेंट को भी खारिज कर दिया जाता है, क्योंकि ब्राउज़र या तो उन्हें बिलकुल नहीं पहचानेगा या <video> या <audio> पैरंट के बिना उनके लिए काम का कोई कॉन्टेक्स्ट नहीं होगा. अंदरूनी <img> एलिमेंट को कोई भी ब्राउज़र पहचान लेगा. साथ ही, src में बताए गए सोर्स को सही तरीके से रेंडर किया जाएगा.

"कला निर्देशित" <picture> वाली इमेज

पेज में इमेज के साइज़ के आधार पर, किसी इमेज के कॉन्टेंट या आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) में बदलाव करने को आम तौर पर, "आर्ट डायरेक्शन" कहा जाता है रिस्पॉन्सिव इमेज. srcset और sizes को इस तरह से डिज़ाइन किया गया है कि यह उपयोगकर्ता के ब्राउज़र के निर्देशों के मुताबिक, सोर्स को आसानी से स्विच करके काम करता है. हालांकि, पेज लेआउट की तरह ही कई बार, ब्रेकपॉइंट में कॉन्टेंट को बेहतर तरीके से हाइलाइट करने के लिए भी बदलाव किया जा सकता है. उदाहरण के लिए: छोटे सेंट्रल फ़ोकस के साथ पूरी चौड़ाई वाली हेडर इमेज, बड़े व्यूपोर्ट पर सही तरीके से काम कर सकती है:

हालांकि, छोटे व्यूपोर्ट के हिसाब से साइज़ छोटा करने पर, इमेज का मुख्य फ़ोकस खो सकता है:

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

यह एक तरह से "काट-छांट" सीएसएस के ज़रिए हासिल किया जा सकता है, लेकिन उपयोगकर्ता को उस इमेज को बनाने वाले पूरे डेटा का अनुरोध करना होगा. भले ही वे उसे कभी न देख पाएं.

हर source एलिमेंट में ऐसे एट्रिब्यूट होते हैं जो source: media को चुनने की शर्तें तय करते हैं. यह एलिमेंट, मीडिया क्वेरी और type, जो मीडिया टाइप (जिसे पहले "MIME टाइप" कहा जाता था) को स्वीकार करता है. सोर्स में मौजूद पहला <source> उपयोगकर्ता के वर्तमान ब्राउज़िंग संदर्भ से मिलान करने के लिए चुना गया है और उस source पर srcset विशेषता की सामग्री को चुना गया है का इस्तेमाल उस संदर्भ के लिए सही उम्मीदवार तय करने के लिए किया जाएगा. इस उदाहरण में, media एट्रिब्यूट के साथ पहला source जो उपयोगकर्ता के व्यूपोर्ट साइज़ से मेल खाता है, उसे चुना जाएगा:

<picture>
  <source media="(min-width: 1200px)" srcset="wide-crop.jpg">
  <img src="close-crop.jpg" alt="…">
</picture>

आपको हमेशा अंदरूनी img को आखिरी क्रम में रखना चाहिए—अगर source एलिमेंट में से कोई भी एलिमेंट अपने media या type से मेल नहीं खाता इमेज "डिफ़ॉल्ट" के तौर पर काम करेगी स्रोत. अगर आप min-width मीडिया क्वेरी का इस्तेमाल कर रहे हैं, तो आप चाहते हैं कि सबसे बड़ी मीडिया क्वेरी हो पहले देखें, जैसा कि ऊपर दिए गए कोड में देखा गया है. max-width मीडिया क्वेरी का इस्तेमाल करते समय, आपको सबसे छोटे सोर्स को पहले रखना चाहिए.

<picture>
   <source media="(max-width: 400px)" srcset="mid-bp.jpg">
   <source media="(max-width: 800px)" srcset="high-bp.jpg">
   <img src="highest-bp.jpg" alt="…">
</picture>

जब किसी सोर्स को आपकी तय की गई शर्तों के हिसाब से चुना जाता है, तो source पर srcset एट्रिब्यूट को <img> को मान लिया था कि इसे <img> पर ही तय किया गया था—इसका मतलब है कि आपके पास आर्ट-डायरेक्ट इमेज को ऑप्टिमाइज़ करने के लिए, sizes का इस्तेमाल करने का विकल्प है सोर्स भी हैं.

<picture>
   <source media="(min-width: 800px)" srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w">
   <source srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w">
   <img src="fallback.jpg" alt="…" sizes="calc(100vw - 2em)">
</picture>

बेशक, चुने गए <source> एलिमेंट के आधार पर अलग-अलग अनुपात वाली इमेज, परफ़ॉर्मेंस की समस्या पैदा करती है: <img> सिर्फ़ एक width और height एट्रिब्यूट के साथ काम करता है. हालांकि, इन एट्रिब्यूट को हटाने से उपयोगकर्ता अनुभव काफ़ी खराब हो सकता है. यह देखने के लिए, तुलना के आधार पर हाल ही में—लेकिन बेहतर तरीके से काम करता है—एचटीएमएल में जोड़ना स्पेसिफ़िकेशन में, <source> एलिमेंट पर height और width एट्रिब्यूट का इस्तेमाल करने की अनुमति है. ये तरीके अपनाने पर, लेआउट शिफ़्ट कम भी हो जाते हैं जैसा कि वे <img> में करते हैं, जिसमें <source> एलिमेंट के चुने गए किसी भी एलिमेंट के लिए आपके लेआउट में सही जगह रिज़र्व रखी गई है.

<picture>
   <source
      media="(min-width: 800px)"
      srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w"
      width="1600"
      height="800">
   <img src="fallback.jpg"
      srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w"
      sizes="calc(100vw - 2em)"
      width="1200"
      height="750"
      alt="…">
</picture>

यह ध्यान देना ज़रूरी है कि व्यूपोर्ट के साइज़ के आधार पर फ़ैसले लेने के अलावा, कला के दिशा-निर्देश का इस्तेमाल कई कामों में भी किया जा सकता है. यह ध्यान में रखते हुए किया जाना चाहिए कि इनमें से ज़्यादातर मामलों को srcset/sizes की मदद से ज़्यादा बेहतर तरीके से हैंडल किया जा सकता है. उदाहरण के लिए, इमेज के किसी सोर्स को बेहतर तरीके से चुनना उपयोगकर्ता की पसंद के हिसाब से उपलब्ध कलर स्कीम के मुताबिक हो:

<picture>
   <source media="(prefers-color-scheme: dark)" srcset="hero-dark.jpg">
   <img srcset="hero-light.jpg">
</picture>

type एट्रिब्यूट

type एट्रिब्यूट की मदद से, <picture> एलिमेंट के एक अनुरोध वाले डिसिज़न इंजन का इस्तेमाल किया जा सकता है, ताकि सिर्फ़ इमेज फ़ॉर्मैट दिखाए जा सकें इस्तेमाल कर सकते हैं.

जैसा कि आपने इमेज फ़ॉर्मैट और कंप्रेस करने के बारे में जाना है, तो जिस एन्कोडिंग को ब्राउज़र पार्स नहीं कर सकता उसे पहचान करके भी नहीं पहचाना जा सकेगा इमेज डेटा.

<picture> एलिमेंट के आने से पहले, आपको नए इमेज फ़ॉर्मैट दिखाने के लिए फ़्रंट-एंड टूल का इस्तेमाल करना होगा ब्राउज़र, किसी इमेज फ़ाइल का अनुरोध करने और उसे पार्स करने की कोशिश करता है. ऐसा, यह तय करने से पहले कि इमेज फ़ाइल को हटाना है या नहीं और फिर फ़ॉलबैक लोड करना है. ऐप्लिकेशन सामान्य उदाहरण इन पंक्तियों के साथ स्क्रिप्ट था:

   <img src="image.webp"
    data-fallback="image.jpg"
    onerror="this.src=this.getAttribute('data-fallback'); this.onerror=null;"
    alt="...">

इस पैटर्न के बाद भी, हर ब्राउज़र में image.webp के लिए अनुरोध किया जाएगा. इसका मतलब है कि ब्राउज़र के लिए पैसे ट्रांसफ़र करने में कोई रुकावट नहीं आती WebP फ़ॉर्मैट में काम नहीं करेगा. जो ब्राउज़र इसके बाद WebP एन्कोडिंग को पार्स नहीं कर पाते वे onerror इवेंट को फेंककर स्वैप करेंगे data-fallback वैल्यू को src में. यह एक बेकार समाधान था, लेकिन फिर से, इस तरह का तरीका ही एकमात्र विकल्प था फ़्रंट-एंड पर उपलब्ध है. याद रखें कि ब्राउज़र किसी कस्टम स्क्रिप्टिंग के का इस्तेमाल करने के लिए प्रोत्साहित किया जाता है—या यहां तक कि पार्स भी किया जा सकता है—इसलिए हम इस प्रक्रिया को पहले से नहीं कर सके.

<picture> एलिमेंट को उन ग़ैर-ज़रूरी अनुरोधों से बचने के लिए साफ़ तौर पर डिज़ाइन किया गया है. हालांकि, ब्राउज़र के लिए अब भी ऐसा नहीं होता है किसी ऐसे फ़ॉर्मैट की पहचान करने के लिए जो अनुरोध किए बिना काम नहीं करता, type एट्रिब्यूट ब्राउज़र को सोर्स के बारे में चेतावनी देता है अप-फ़्रंट एन्कोडिंग करता है, ताकि यह तय कर सके कि अनुरोध करना है या नहीं.

type एट्रिब्यूट में, मीडिया टाइप (पहले इसे MIME type कहा जाता था) एट्रिब्यूट की वैल्यू दी जाती है हर <source> की srcset एट्रिब्यूट में बताई गई इमेज सोर्स का वैल्यू डालें. इससे ब्राउज़र को अपनी पूरी जानकारी मिलती है को तुरंत यह तय करना होगा कि source से मिले इमेज कैंडिडेट को डिकोड किया जा सकता है या नहीं अनुरोध—अगर मीडिया टाइप की पहचान न हो पाए, तो <source> और उसके सभी उम्मीदवारों को अनदेखा कर दिया जाता है और ब्राउज़र आगे बढ़ जाता है.

<picture>
 <source type="image/webp" srcset="pic.webp">
 <img src="pic.jpg" alt="...">
</picture>

यहां WebP एन्कोडिंग की सुविधा देने वाला कोई भी ब्राउज़र, type एट्रिब्यूट में बताए गए image/webp मीडिया टाइप को पहचान लेगा <source> एलिमेंट में से उस <source> को चुनें. ऐसा इसलिए, क्योंकि हमने srcset में सिर्फ़ एक उम्मीदवार दिया है, जो अंदरूनी pic.webp का अनुरोध करने, ट्रांसफ़र करने, और रेंडर करने के लिए <img>. ऐसा कोई भी ब्राउज़र source को अनदेखा करेगा जिसमें WebP की सुविधा नहीं है. इसके अलावा, किसी भी निर्देश को छोड़कर, <img> src के कॉन्टेंट को उसी तरह रेंडर करेगा जैसा 1992 से किया जाता है. यहां आपको type="image/jpeg" के साथ दूसरे <source> एलिमेंट की जानकारी देने की ज़रूरत नहीं है. हालांकि, आपके पास JPEG के लिए पूरी तरह से काम करने की सुविधा है.

उपयोगकर्ता चाहे किसी भी तरह से ब्राउज़ कर रहा हो, ये सभी चीज़ें एक फ़ाइल ट्रांसफ़र से पूरी होती हैं और किसी भी बैंडविथ को इमेज के ऐसे सोर्स जिन्हें रेंडर नहीं किया जा सकता. यह भविष्य की सोच है. साथ ही, नए और ज़्यादा बेहतर फ़ाइल फ़ॉर्मैट अलग-अलग मीडिया टाइप का इस्तेमाल कर रहे हैं. साथ ही, हम picture की मदद से इनका फ़ायदा ले सकते हैं—बिना JavaScript और सर्वर साइड वाले डिपेंडेंसी और <img> की सारी स्पीड.

रिस्पॉन्सिव इमेज का भविष्य

यहां बताए गए सभी मार्कअप पैटर्न, मानक तय करने के लिहाज़ से काफ़ी अहम थे: <img> के रूप में वेब पर स्थापित और केंद्रीय रूप से एक बड़ी उपलब्धि थी. साथ ही, उन समस् याओं के सुइट का मक़सद था समाधान भी बहुत बड़े स्तर पर थे. अगर आपको लगता है कि इन तरीकों से काफ़ी सुधार किया जा सकता है तो आप बिलकुल सही हैं. शुरू से ही, इन मानकों का मकसद, आने वाले समय के लिए एक बेसलाइन उपलब्ध कराना था बनाई जाने वाली टेक्नोलॉजी के बारे में.

ये सभी समाधान ज़रूरी तौर पर मार्कअप पर निर्भर करते हैं, ताकि सर्वर के शुरुआती पेलोड में शामिल किया जा सके, साथ ही, ब्राउज़र को इमेज के सोर्स के लिए अनुरोध करने का समय दे देता है—एक ऐसी सीमा जिसकी वजह से sizes एट्रिब्यूट की वैल्यू को स्वीकार करना मुश्किल होता है.

हालांकि, इन सुविधाओं को वेब प्लैटफ़ॉर्म पर लॉन्च किए जाने के बाद, इमेज के अनुरोधों को टालने का एक नेटिव तरीका पेश किया गया. loading="lazy" एट्रिब्यूट वाले <img> एलिमेंट का अनुरोध तब तक नहीं किया जाता, जब तक पेज के लेआउट की जानकारी नहीं हो जाती. ऐसा करने से रोका जा सकता है पेज को रेंडर करने की प्रोसेस के दौरान, उपयोगकर्ता के शुरुआती व्यूपोर्ट के बाहर की इमेज के लिए अनुरोध करना. इससे, पेज को रेंडर करने से बचा जा सकता है ग़ैर-ज़रूरी अनुरोध शामिल नहीं किए गए हैं. चूंकि ये अनुरोध किए जाते समय ब्राउज़र पेज लेआउट को पूरी तरह से समझता है, इसलिए एचटीएमएल स्पेसिफ़िकेशन के अलावा, sizes="auto" एट्रिब्यूट का सुझाव दिया गया है इसलिए, मैन्युअल तरीके से sizes एट्रिब्यूट का इस्तेमाल करने से बचें.

कुछ बेहतरीन बदलावों को लागू करने के लिए, <picture> एलिमेंट में भी कुछ बदलाव किए गए हैं जिस तरह से हम पेज लेआउट की स्टाइल बदलते हैं. व्यूपोर्ट की जानकारी, लेआउट के हाई-लेवल फ़ैसला लेने के लिए एक अहम जानकारी होती है. हालांकि, यह हमें डेवलपमेंट के लिए पूरी तरह से कॉम्पोनेंट-लेवल का तरीका अपनाने से रोकता है. इसका मतलब है कि एक ऐसा कॉम्पोनेंट जिसे पेज लेआउट का कोई भी हिस्सा, जिसमें वे स्टाइल शामिल हैं जो कॉम्पोनेंट के ज़रिए लिए गए स्पेस के मुताबिक काम करते हैं. इस चिंता की वजह से कंटेनर क्वेरी बनाने में मदद करता है: यह एलिमेंट को स्टाइल करने का एक तरीका है न कि सिर्फ़ व्यूपोर्ट के बजाय, उनके पैरंट कंटेनर के साइज़ पर आधारित हों.

हालांकि, कंटेनर क्वेरी सिंटैक्स सिर्फ़ स्थिर है और ब्राउज़र पर काम करने की सुविधा बहुत सीमित है, लिखते समय—इसे चालू करने वाली ब्राउज़र टेक्नोलॉजी के अलावा, <picture> एलिमेंट को इसका मतलब है: एक संभावित container एट्रिब्यूट, जो इस आधार पर <source> को चुनने की शर्तें पूरी करने की अनुमति देता है व्यूपोर्ट के साइज़ के बजाय, <picture> एलिमेंट के <img> स्पेस का इस्तेमाल करता है.

अगर आपको यह बात सही नहीं लगती, तो इसकी भी एक अच्छी वजह है: वेब के मानकों के बारे में ये चर्चाएं चल रही हैं, लेकिन इनमें कोई समस्या नहीं है अभी उनका इस्तेमाल नहीं कर सकता.

हालांकि, रिस्पॉन्सिव इमेज मार्कअप समय के साथ सिर्फ़ आसानी से काम करने का वादा करता है, जैसे कि किसी भी वेब टेक्नोलॉजी के लिए, फिर भी ऐसी कई सुविधाएं हैं के लिए डिज़ाइन किया है, ताकि इस मार्कअप के लिए हाथ से लिखने का बोझ कम किया जा सके. अगले मॉड्यूल में, हम इमेज फ़ॉर्मैट, कंप्रेस करने, और रिस्पॉन्सिव इमेज (स्क्रीन के हिसाब से साइज़ बदलने वाली इमेज) के बारे में अब तक सीखी गई हर चीज़ को आधुनिक डेवलपमेंट वर्कफ़्लो के साथ इंटिग्रेट करने का तरीका देखेंगे.