एक प्रतिक्रियाशील छवि प्रारूप की आवश्यकता

विषय

• संकल्प भंडारण
• प्रतिक्रियाशील छवि प्रारूप के लाभ
• सामग्री प्रकाशक जो कोड नहीं करते हैं
• SRCSET विशेषता
• एक बार सहेजें, हर जगह छवियां
• IMG अभी मरा नहीं है

जीआईएफ और जेपीईजी वेब ब्राउज़र में समर्थित होने वाली पहली छवियां नहीं थीं, भले ही वे हमेशा के लिए हमारे साथ रहे हों। पीएनजी और इसके अल्फा पारदर्शिता फीचर को पहली बार देखने के बाद मुख्यधारा में अपनाने में कुछ समय लगा। और अब Google अपने नए वेबपी छवि प्रारूप पर जोर दे रहा है, लेकिन वेबपी के लिए छवि अपनाने की पहले से ही हिमनद गति धीमी होगी।

मैं वेबपी को बिना किसी नई क्रांतिकारी सुविधाओं (जैसे पीएनजी की अल्फा पारदर्शिता) की पेशकश किए बिना जीआईएफ और जेपीईजी के संकर के रूप में देखता हूं। हमें पहले से ही अनुकूली/उत्तरदायी छवियों के साथ एक समस्या है और यह एक ऐसी समस्या है जो एक क्रांतिकारी समाधान की मांग करती है।

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

संकल्प भंडारण

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

हमें समान छवियों के लिए एक फ़ाइल प्रारूप की आवश्यकता है। छवि के लिए मेटा जानकारी कैप्चर करने के बजाय, जो बहुत सीधी है, हमें छवि के विभिन्न रूपों को संग्रहीत करने की आवश्यकता है। एक छवि फ़ाइल में एक थंबनेल छवि, एक मोबाइल अनुकूल छवि, डेस्कटॉप अनुकूल संस्करण, रेटिना डिस्प्ले संस्करण और प्रिंट-अनुकूल छवि शामिल हो सकती है।

यह उत्तरदायी छवि प्रारूप केवल एक सपना नहीं है। एक छवि फ़ाइल प्रारूप पहले से मौजूद है जो ऐसा करता है: इसे फ्लैशपिक्स कहा जाता है। पार्टनर ईस्टमैन कोडक, माइक्रोसॉफ्ट और हेवलेट-पैकार्ड द्वारा 1996 में विकसित, छवि फ़ाइल प्रारूप अपने समय से आगे था, क्योंकि ब्राउज़र बाजार में इसे अपनाना नहीं था और यह सूचीहीन लग रहा था।

प्रतिक्रियाशील छवि प्रारूप के लाभ

उत्तरदायी छवि प्रारूप के लाभों में से एक यह है कि यह img तत्व और केवल img तत्व के निरंतर उपयोग की अनुमति देता है। Img तत्व वेब की हड्डियों, बहुत मज्जा में समाया हुआ है। चित्र> प्रस्ताव एक छवि को काम करने के लिए विभिन्न छवियों के एकाधिक स्रोत संदर्भों को मजबूर करके उस मानसिकता के खिलाफ चला गया। इतनी बुनियादी चीज़ के लिए यह बहुत अधिक अतिरिक्त काम है।

कुछ ने कहा है कि चित्र> तत्व सर्वसम्मति से संचालित, अच्छी तरह से तैयार किया गया है और प्रयोग करने योग्य समाधान है (देखें cssquirrel.com/blog/2012/05/15/the-egotistical-puppet-king-and-i/)।

मैं आपको उन तीन में से दो प्रदान करूंगा - चित्र> समाधान में आम सहमति थी और इसे अच्छी तरह से तैयार किया गया था, लेकिन यह एक उपयोगी समाधान नहीं था।

एक कारण है कि एक्सएचटीएमएल की सख्त कोडिंग शैलियों को छोड़ दिया गया था और एचटीएमएल 5 में ढीले एचटीएमएल 4 कोडिंग प्रथाओं को शामिल किया गया था। पचहत्तर प्रतिशत वेबसाइटें मान्य नहीं हैं (देखें dev.opera.com/articles/view/mama-markup-validation-report/), इसलिए नहीं कि हम उन्हें नहीं चाहते, बल्कि इसलिए कि हमने उन्हें कोडित किया है इस तरह या तो शुरुआत से या समय के साथ।

वेब डिज़ाइनरों, ब्लॉगर्स और गैर-तकनीकी लोगों को अपनी छवियों की कई प्रतियां बनाने और HTML की अतिरिक्त पंक्तियाँ लिखने के लिए कहना हर संभव प्रदर्शन परिदृश्य को खुश करने के लिए न केवल एक बहुत ही गैर-मानक दृष्टिकोण की तरह लगता है, यह बहुत व्यावहारिक भी नहीं है।

ऑडियो और वीडियो के लिए समाधान का जन्म ब्राउज़र वेंडर्स के टर्फ युद्धों और लाइसेंसिंग मुद्दों के कारण भिन्न फ़ाइल समर्थन को संतुलित करने के लिए हुआ था।वीडियो और ऑडियो तत्वों से पैदा हुए समाधान के साथ जाने का प्रयास करके यह था कि हम एक अद्वितीय गणित समस्या के उत्तर को किसी अन्य गणित समस्या में कॉपी कर रहे थे क्योंकि यह समान पूर्णांक का उपयोग करता था।

वेब पेज में एक छवि दिखाने के लिए HTML की कई पंक्तियों को तैयार करने की आवश्यकता नहीं है जैसा कि चित्र> तत्व में दिया गया था (देखें www.netmagazine.com/features/state-responsive-images)।

सामग्री प्रकाशक जो कोड नहीं करते हैं

एक और मुद्दा यह है कि अतिरिक्त मार्कअप के साथ छवियों को सम्मिलित करने की एक विधि के साथ WYSIWYG संपादकों, सामग्री प्रबंधन प्रणालियों में उनके संबंधित टूल बार और अपडेट किए गए पुराने वेब पेजों में व्यापक बदलाव की आवश्यकता होती है।

यह यूं ही नहीं होने वाला है। मिनी-Y2K स्तरों पर कुछ करने की आवश्यकता है (देखें www.computerworld.com/s/article/9142555/Y2K_The_good_the_bad_and_the_crazy) ताकि कंपनियां और संगठन इस मुद्दे को ठीक करने के लिए उस तरह की पूंजी खर्च करना शुरू कर सकें।

SRCSET विशेषता

हाल ही में, WHATWG ने चित्र> तत्व पर विचार करने के बाद अपने स्वयं के प्रस्ताव की घोषणा की (देखें www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset )। पहली नज़र में, यह निश्चित रूप से चित्र> तत्व की तुलना में अधिक प्रयोग करने योग्य, अधिक पीछे की ओर संगत समाधान है।

विशेषता के लिए वाक्य रचना को काम करने की आवश्यकता है क्योंकि जेरेमी कीथ चर्चा करते हैं (देखें adactio.com/journal/5474/), लेकिन इन मुद्दों को संबोधित करना आसान है और - उम्मीद है - कम नाटकीय हैं।

एक बार सहेजें, हर जगह छवियां

यदि कोई विकल्प दिया जाता है, हालांकि, मेरा मानना ​​​​है कि वेब डिज़ाइनर आतिशबाजी, फ़ोटोशॉप या उनकी पसंद के किसी भी पसंदीदा छवि संपादक से कलाकृति का एक टुकड़ा निर्यात करेंगे। फिर यह कंटेनर फ़ाइल एक सर्वर पर अपलोड की जाती है, जैसे कि हर दूसरी छवि फ़ाइल जिसे हमने पहले इस्तेमाल किया है और एक HTML पृष्ठ में img तत्व के माध्यम से संदर्भित किया है। अंतर केवल इतना है कि सर्वर और ब्राउज़र इस बात पर सहमत होते हैं कि इसके स्टोरेज लॉकर में किस छवि को संदर्भित किया जाना चाहिए।

IMG अभी मरा नहीं है

सरल आईएमजी ने हमें यहां तक ​​पहुंचाया है और यह हमें अभी तक विफल नहीं हुआ है। लेकिन SRCSET विशेषता का परिचय एक स्मार्ट कदम है और हमें समाधान के थोड़ा करीब ले जाता है। अब, बेहतर ब्राउज़र और सर्वर बनाकर छवि प्रारूपों को बेहतर और बेहतर बनाने के लिए देखते हैं।

वेब को एक छवि प्रारूप की आवश्यकता होती है, जहां सर्वर, ब्राउज़र द्वारा पूछे जाने पर, सही छवि प्रदान कर सके जिसमें सही रिज़ॉल्यूशन हो। हमें एक छवि प्रारूप की आवश्यकता है जो उचित समाधान निर्धारित करने के लिए सर्वर और ब्राउज़र के साथ मिलकर काम कर सके।

वेब डिज़ाइन के लिए एक नया छवि प्रारूप असंभव नहीं है। बस कभी-कभी ऐसा लगता है।