हर बार जब आप CSS3 के लिए एक स्वामित्व सुविधा देते हैं - बिल्ली का बच्चा मर जाता है

अनुवादक से: मालिकाना ( एक या दो बार लेखों का अनुवाद) के विषय को जारी रखते हुए, ली वेरौ ने अपना लेख ए लिस्ट पर अलग से लिखा, जिसमें वह वेब डेवलपर्स के लिए सलाह देती है। लेख शीर्षक का अनुवाद करने के लिए :)

आधिकारिक बयान: हर बार जब आप CSS3 में एक मालिकाना विशेषता जोड़ते हैं, तो एक बिल्ली का बच्चा मर जाता है। कोई भी -webkit- सुविधा जो विनिर्देशों में मौजूद नहीं है (कम से कम ड्राफ्ट में) CSS3 से संबंधित नहीं है । हां, कुछ विशेषताएं CSS3 के रूप में गुजरती हैं, लेकिन वे CSS3 का हिस्सा नहीं हैं। और यह नाइटपैकिंग नहीं है । यह एक बहुत ही महत्वपूर्ण बिंदु है, क्योंकि यह राज्य कुछ कंपनियों (* khe * Apple * khe *) को मानकीकरण प्रक्रिया को अनदेखा करने के लिए प्रोत्साहित करता है, जो कि वे WebKit में आए थे, और इसे व्हील के बाद सबसे अच्छा आविष्कार के रूप में डेवलपर्स के बीच लोकप्रिय बनाने के लिए लागू किया गया था। नए चमकदार खिलौने हमें अंधा कर देते हैं और हम उन्हें पालना भी शुरू कर देते हैं, जिससे व्यापक उपयोग में योगदान होता है।

नए ट्रिंकेट का उपयोग करने की हमारी खोज में, हम अक्सर भूल जाते हैं कि पिछले एक दशक में कितने लोगों ने हमें बिना शाखा और हैक के कोड लिखने की अनुमति देने के लिए संघर्ष किया है, और यह उम्मीद करते हैं कि यह हर जगह समान हो। यदि आप एक-दो साल से अधिक समय से वेब विकास में हैं, तो आपको यह निश्चित रूप से याद रखना चाहिए कि ऐसा हमेशा नहीं हुआ है। अब वेब मानकों का मुख्य कारण, ब्राउज़र युद्ध में एक कठिन जीत है।

आपको आश्चर्य हो सकता है, लेकिन ब्राउज़र वॉर के दौरान वेब मानकों का अस्तित्व था । W3C की स्थापना 1994 में हुई थी । हालाँकि, तब ब्राउज़र डेवलपर्स ने मानकों के बारे में परवाह नहीं की, और उन्होंने वसीयत में नवाचारों को पेश किया। नतीजतन, ब्राउज़रों का वेब मानकों से बहुत कम लेना-देना था। क्या यह आपको कुछ याद दिलाता है? आज की मालिकाना सुविधाएँ समान ActiveX और IE फ़िल्टर (इंटरनेट एक्सप्लोरर में नोट फ़िल्टर संपत्ति) से बेहतर नहीं हैं। बस इतना अंतर है कि आज का पीआर बेहतर है, लेकिन अभी तक हम सभी को इसका परिणाम नहीं मिला है। मानो या न मानो, IE6 सुविधाएँ, भी, एक बार बहुत उत्साह के साथ प्राप्त की गई थीं ।

हां, कभी-कभी ब्राउज़र अच्छी चीजें प्रदान करते हैं जो समय के साथ मानकीकृत हो जाते हैं (XMLHttpRequest, Drag & Drop API, contentEditable, Web फ़ॉन्ट्स उनमें से कुछ हैं)। हालांकि, कुछ भी नवाचार और मानकीकरण प्रक्रिया को रोकता नहीं है। यह उन्हें प्रासंगिक W3C कार्य समूह के लिए कुछ शांत करने के लिए आने से नहीं रोकता है, एक प्रस्ताव प्रस्तुत करने और इसे लागू करने के लिए लंबे समय तक भागने से पहले सामूहिक चर्चा के माध्यम से इसमें सुधार करता है। अगर Microsoft ने Drag & Drop API के लिए ऐसा किया होता, तो आज इस API का उपयोग करने के लिए उसे टैम्बोरिन की आवश्यकता नहीं होती।

मालिकाना विशेषताएं जो मानकीकरण प्रक्रिया से नहीं गुजरती हैं, आमतौर पर विचार खराब होने पर भी खराब डिजाइन होती हैं। उदाहरण के लिए, CSS ग्रेडिएंट एक अच्छा विचार था, लेकिन -webkit-gradient () बेमानी था और इसमें त्रुटियां थीं। वेब फोंट एक अच्छा विचार था, लेकिन उस के लिए फ़ाइलों का उपयोग न करें। मानकीकरण प्रक्रिया न केवल संगतता के साथ मदद करती है, बल्कि प्रत्येक सुविधा के डिजाइन में सुधार करने में भी मदद करती है, बड़ी संख्या में विविध राय के लिए धन्यवाद।

यहां कुछ कुख्यात सीएसएस गुण हैं जो एक ही समय में काफी लोकप्रिय हैं:

• -webkit-बॉक्स को प्रतिबिंबित
• -webkit-पाठ-स्ट्रोक
• -webkit-मुखौटा
• -webkit- पृष्ठभूमि-क्लिप: पाठ;
• -webkit-पाठ आकार समायोजित
• -webkit-टैप-प्रकाश डाला रंग
• -webkit-पाठ भरण रंग

उपसर्ग वाली प्रत्येक संपत्ति स्वामित्व वाली नहीं है। उनमें से कुछ मानकों में शामिल सुविधाओं का सिर्फ एक प्रयोगात्मक कार्यान्वयन है। यह हमें अगले प्रश्न की ओर ले जाता है।

यदि कोई विशेषता स्वामित्व है तो मैं कैसे निर्धारित कर सकता हूं?

मेरे पास यह तरीका है: Google खोज बार में मैं फीचर का नाम (उद्धरण चिह्नों में) लिखता हूं और साइट के अंत में जोड़ता हूं: w3.org ताकि खोज केवल w3.org डोमेन के भीतर हो। कुछ उदाहरण:

• "बॉक्स-छाया" साइट: w3.org
• "बॉक्स-प्रतिबिंबित" साइट: w3.org

यदि आप परिणामों को देखते हैं, तो पहली सुविधा के लिए, पहला विकल्प W3C विनिर्देश का एक लिंक है। दूसरे के लिए, परिणाम केवल मेलिंग सूची को संदर्भित करते हैं, और यह एक संकेत है कि इसके लिए कोई विनिर्देश नहीं है।

मैं क्या कर सकता हूँ?

शुरुआत के लिए, मालिकाना सुविधाओं का उपयोग बिल्कुल भी न करें। उनका उपयोग न करें, उन्हें लोकप्रिय न करें, और निश्चित रूप से उन पर भरोसा न करें। लेकिन मैं समझता हूं कि यह काम करने की तुलना में आसान है। यदि आप पूरी तरह से मालिकाना सुविधाओं को नहीं छोड़ सकते हैं, तो यहां कुछ युक्तियां दी गई हैं। मुझे यकीन है कि आप उनका अनुसरण कर सकते हैं:

• सुनिश्चित करें कि सुविधा का उपयोग प्रगतिशील वृद्धि के सिद्धांतों से मिलता है (लगभग। रूसी में एक एनालॉग नहीं मिला। अनुवाद विकल्प क्रमिक सुधार है) ताकि डिजाइन इसके बिना काम कर सके।
• ऐसी विशेषताओं के बारे में बात न करें, लेकिन यदि आप अभी भी बताते हैं, तो यह सुनिश्चित करना सुनिश्चित करें कि वे मालिकाना हैं और इसका मतलब क्या है।
• यदि आप अपने कोड में इस तरह की सुविधा का उपयोग करते हैं, तो कुछ टिप्पणी जोड़ें, जैसे / * सावधानी: गैर-मानक संपत्ति * / । बहुत से लोग मौजूदा साइटों का अध्ययन करके सीखते हैं। यहां तक ​​कि अगर आप व्याख्यान नहीं देते हैं और शैक्षिक लेख नहीं लिखते हैं, तो भी आप अप्रत्यक्ष रूप से अपने कोड की प्रत्येक पंक्ति के साथ बाकी को पढ़ाते हैं।
• लेख, रिपोर्ट, डेमो आदि की आलोचना करें, जो चेतावनी के बिना ऐसी विशेषताओं को लोकप्रिय बनाते हैं, या जो केवल एक विक्रेता उपसर्ग का उपयोग करते हैं (जो कि एक बहुत गंभीर समस्या भी है )। या, बेहतर, यदि संभव हो तो इसे ठीक करें ।

मैं किसी विशेषता को मानकीकृत करने में कैसे मदद कर सकता हूं?

यदि आप पाते हैं कि आप एक मालिकाना विशेषता का उपयोग कर रहे हैं, तो इसे मानकीकृत करने में भाग लें। मैं कुछ चरणों की सिफारिश कर सकता हूं, जो कि सामान्य तौर पर किसी भी प्रस्ताव पर लागू किए जा सकते हैं:

1. मानकों की पेशकश करने वाले विकल्पों का अन्वेषण करें।
   
   सबसे पहले, उन विकल्पों का अध्ययन करें जो विनिर्देशों में हैं। वे खराब या उचित ब्राउज़र समर्थन के बिना हो सकते हैं, लेकिन कम से कम आपको पता चल जाएगा कि भविष्य में क्या करना है। आप भविष्य के लिए सुविधाओं के लिए समर्थन भी जोड़ सकते हैं, जिससे संबंधित समर्थन प्रकट होने पर आप अन्य ब्राउज़रों को नहीं छोड़ेंगे।
   आप ब्राउज़र ट्रैकर में एक टिकट बनाकर सुविधाओं की शुरूआत को गति दे सकते हैं जो इसका समर्थन नहीं करता है, और यदि टिकट पहले से ही खुला है, तो एक टिप्पणी छोड़ दें, यह दिखाएं कि यह आपके लिए कितना महत्वपूर्ण है। नई सुविधाओं को प्राथमिकता देते समय ब्राउज़र डेवलपर्स इसे ध्यान में रखते हैं।
   
   
2. जाँच करें, हो सकता है कि फीचर पर पहले से ही चर्चा हो रही हो।
   
   W3C सुविधाओं की चर्चा करता है और मेलिंग सूचियों का उपयोग करके उन्हें पूर्णता में लाता है। प्रत्येक कार्य समूह का अपना समाचार पत्र होता है। कभी-कभी समूह एक साथ आते हैं जब एक विशेषता विकसित होती है जिसमें कई प्रौद्योगिकियां शामिल होती हैं। उदाहरण के लिए, CSS वर्किंग ग्रुप www-style वितरण का उपयोग करता है, और SVG वर्किंग ग्रुप www-svg वितरण का उपयोग करता है। हालांकि, सीएसएस और एसवीजी दोनों को प्रभावित करने वाली सुविधाओं के लिए, सार्वजनिक-एफएक्स मेलिंग सूची का उपयोग किया जाता है ।
   यदि आप एक फीचर चर्चा पाते हैं, लेकिन यह चर्चा कुछ भी नहीं हुई है, तो आप चर्चा को फिर से शुरू करने का प्रयास कर सकते हैं। लेकिन पहले, सभी पत्राचार का अध्ययन करें और सुनिश्चित करें कि आपके तर्क अभी तक चर्चा में नहीं आए हैं और आपको कुछ जोड़ना है।
   
   
3. एक सुविधा का सुझाव दें
   
   अपने प्रस्ताव में अधिक से अधिक संबंधित जानकारी शामिल करने का प्रयास करें। आप निर्दिष्ट कर सकते हैं:
   
   • किसी सुविधा का उपयोग किए जाने पर स्थिति। यह बहुत महत्वपूर्ण है। कोई भी नई सुविधाओं को मानकीकृत करने में दिलचस्पी नहीं लेता है जो दुर्लभ मामलों में उपयोग की जाती हैं। दिखाएं कि प्रस्तावित सुविधा क्या है और इसका उपयोग कैसे किया जा सकता है।
   • आपका उपयोग अनुभव। आप क्या पसंद करते हैं, आप क्या बदलना पसंद करेंगे, इसे किस तरह से व्यापक कार्यों के लिए सामान्यीकृत किया जा सकता है, आदि।
   निर्धारित करें कि आपका प्रस्ताव किस विनिर्देश पर लागू होता है (सीएसएस विशिष्टताओं की पूरी सूची यहां पाई जा सकती है )। उसके बाद, चर्चा शीर्षक की शुरुआत में विनिर्देश पहचानकर्ता जोड़ें । उदाहरण के लिए, मान और यूनिट मॉड्यूल (मान और मात्रा) पर चर्चा करने के लिए, आपको [css3-values] जोड़ने की जरूरत है (प्रत्येक विनिर्देशन के लिए पहचानकर्ता इसके URL में पाए जा सकते हैं)। यह सुनिश्चित करता है कि विनिर्देश के संपादकों के लिए आपके प्रस्ताव को खोजना आसान होगा, साथ ही विशिष्ट विनिर्देश में रुचि रखने वाले सभी को चर्चा का पालन करने की अनुमति देगा।
   यह भी याद रखना चाहिए कि नई विशेषताओं को उन विशिष्टताओं में नहीं जोड़ा गया है जो पहले से ही उम्मीदवार की सिफारिश की स्थिति (सिफारिश के लिए उम्मीदवार) तक पहुंच चुकी हैं, और निश्चित रूप से यह सभी बाद की स्थितियों के लिए भी सही है, अर्थात प्रस्तावित सिफारिश (प्रस्तावित सिफारिश और सिफारिश) स्वीकृत विनिर्देशन)। उदाहरण के लिए, यदि आप एक नया चयनकर्ता जोड़ने का सुझाव देते हैं, तो इसे चयनकर्ता स्तर 3 मॉड्यूल में जोड़ने की पेशकश न करें, जिसकी सिफारिश की स्थिति है। हालाँकि, आप इसे चयनकर्ता स्तर 4 मॉड्यूल में जोड़ने का सुझाव दे सकते हैं।
   यदि आप मानकीकरण प्रक्रिया के बारे में अधिक जानना चाहते हैं, तो fantasai द्वारा सीएसएस WG श्रृंखला के अंदर अद्भुत देखें।
   

यह सब जटिल और उबाऊ है!

किसी भी पर्यावरणीय समस्या के बारे में यही कहा जा सकता है। हां, आज की समस्याओं को हल करने के लिए केवल मालिकाना सुविधाओं का उपयोग करना निश्चित रूप से अधिक कठिन है। लेकिन लंबे समय में, यह सभी के हितों में है।

ए लिस्ट के अतिरिक्त पत्रिका और लेखक [एस] की अनुमति से अनुवादित।