नए एचटीएमएल की <अनुमति> एलिमेंट के लिए ऑरिजिन ट्रायल

Thomas Steiner

वेब ऐप्लिकेशन में, जगह की जानकारी ऐक्सेस करने जैसी ज़रूरी सुविधाओं का इस्तेमाल करने की अनुमति मांगने के कई तरीके हैं. इन तरीकों में कई समस्याएं आती हैं. इसलिए, Chrome की अनुमतियां देने वाली टीम, डिक्लेरेटिव तरीके का इस्तेमाल कर रही है. यह एक खास एचटीएमएल <permission> एलिमेंट है. यह एलिमेंट, Chrome 126 से ऑरिजिन ट्रायल में है. हमारा मकसद इसे स्टैंडर्ड बनाना है.

अनुमति का अनुरोध करने के ज़रूरी तरीके

जब वेब ऐप्लिकेशन को बेहतरीन सुविधाओं को ऐक्सेस करने की ज़रूरत होती है, तो उन्हें अनुमति मांगनी पड़ती है. उदाहरण के लिए, जब Google Maps को Geolocation API का इस्तेमाल करके उपयोगकर्ता की जगह की जानकारी चाहिए होती है, तो ब्राउज़र उपयोगकर्ता को सूचना देते हैं. साथ ही, अक्सर उपयोगकर्ता को यह फ़ैसला सेव करने का विकल्प भी मिलता है. यह अनुमतियों की खास जानकारी में अच्छी तरह से बताया गया सिद्धांत है.

पहली बार इस्तेमाल करने पर, साफ़ तौर पर अनुरोध करने के बजाय, अनुमान के आधार पर अनुमति मांगना

Geolocation API एक बेहतरीन एपीआई है. यह पहली बार इस्तेमाल करने पर, उपयोगकर्ता से अनुमति लेने के तरीके पर काम करता है. उदाहरण के लिए, जब कोई ऐप्लिकेशन navigator.geolocation.getCurrentPosition() तरीके को कॉल करता है, तो पहली कॉल पर अनुमतियों का अनुरोध करने वाला प्रॉम्प्ट अपने-आप पॉप-अप हो जाता है. navigator.mediaDevices.getUserMedia(), इसका एक और उदाहरण है.

अन्य एपीआई, जैसे कि सूचना एपीआई या डिवाइस ओरिएंटेशन और मोशन एपीआई, आम तौर पर अनुमति का अनुरोध करने के लिए एक स्टैटिक तरीका इस्तेमाल करते हैं. जैसे, Notification.requestPermission() या DeviceMotionEvent.requestPermission().

अनुमति मांगने के लिए ज़रूरी तरीकों से जुड़ी चुनौतियां

अनुमति के लिए स्पैम ईमेल

पहले, वेबसाइटें navigator.mediaDevices.getUserMedia() या Notification.requestPermission() जैसे तरीकों को कॉल कर सकती थीं. हालांकि, वेबसाइट लोड होने पर navigator.geolocation.getCurrentPosition() को भी तुरंत कॉल किया जा सकता था. उपयोगकर्ता के वेबसाइट से इंटरैक्ट करने से पहले, अनुमति मांगने वाला प्रॉम्प्ट पॉप-अप हो जाता है. इसे कभी-कभी अनुमति से जुड़ा स्पैम भी कहा जाता है. इससे दोनों तरीकों पर असर पड़ता है. पहली बार इस्तेमाल करने पर, अनुमति के लिए सीधे तौर पर न पूछने के साथ-साथ, साफ़ तौर पर अनुमति मांगने पर भी इसका असर पड़ता है.

ब्राउज़र से जुड़ी कमियां और उपयोगकर्ता के जेस्चर से जुड़ी ज़रूरी शर्तें

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

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

अनुमति के बारे में जानकारी देना

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

पहले जैसा करना आसान नहीं है

आखिर में, उपयोगकर्ताओं के लिए किसी ऐसे पेज पर नेविगेट करना बहुत आसान होता है जहां उन्हें कोई काम की जानकारी नहीं मिलती. उदाहरण के लिए, अगर किसी उपयोगकर्ता ने किसी सुविधा के ऐक्सेस को ब्लॉक कर दिया है, तो उसे साइट की जानकारी वाले ड्रॉप-डाउन के बारे में पता होना चाहिए. यहां जाकर, वह अनुमतियां रीसेट कर सकता है या ब्लॉक की गई अनुमतियों को फिर से चालू कर सकता है. सबसे खराब स्थिति में, दोनों विकल्पों के लिए पेज को पूरी तरह से फिर से लोड करना ज़रूरी होता है, ताकि अपडेट की गई सेटिंग लागू हो सके. वेबसाइटों के पास, उपयोगकर्ताओं को अनुमति की मौजूदा स्थिति बदलने के लिए कोई आसान शॉर्टकट देने की सुविधा नहीं होती. उन्हें उपयोगकर्ताओं को यह बताना होता है कि वे अपनी सेटिंग कैसे बदलें. जैसा कि Google Maps के इस स्क्रीनशॉट में सबसे नीचे दिखाया गया है.

अगर अनुमति देना ज़रूरी है, जैसे कि वीडियो कॉन्फ़्रेंसिंग ऐप्लिकेशन के लिए माइक्रोफ़ोन का ऐक्सेस, तो Google Meet जैसे ऐप्लिकेशन, दखल देने वाले डायलॉग दिखाते हैं. इनमें उपयोगकर्ता को यह निर्देश दिया जाता है कि अनुमति को अनब्लॉक कैसे करें.

निर्देश के बदले सुझाव देने वाला <permission> एलिमेंट

इस पोस्ट में बताई गई चुनौतियों को हल करने के लिए, Chrome की अनुमतियां टीम ने एक नए एचटीएमएल एलिमेंट, <permission> के लिए ऑरिजिन ट्रायल लॉन्च किया है. इस एलिमेंट की मदद से डेवलपर, वेबसाइटों के लिए उपलब्ध सुविधाओं के सबसेट का इस्तेमाल करने की अनुमति मांग सकते हैं. इसका इस्तेमाल इस उदाहरण में दिखाए गए तरीके से किया जाता है:

<permission type="camera" />

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

type एट्रिब्यूट

type एट्रिब्यूट में, स्पेस से अलग की गई उन अनुमतियों की सूची होती है जिनके लिए आपने अनुरोध किया है. इस लेख को लिखते समय, इन वैल्यू का इस्तेमाल किया जा सकता है: 'camera', 'microphone', और camera microphone (इनके बीच में स्पेस होना चाहिए). यह एलिमेंट डिफ़ॉल्ट रूप से, बटन की तरह रेंडर होता है. इसमें उपयोगकर्ता एजेंट की स्टाइलिंग शामिल होती है.

type-ext एट्रिब्यूट

कुछ अनुमतियों के लिए अतिरिक्त पैरामीटर इस्तेमाल किए जा सकते हैं. इनके लिए, type-ext एट्रिब्यूट में स्पेस से अलग किए गए की-वैल्यू पेयर इस्तेमाल किए जा सकते हैं. जैसे, जियोलोकेशन की अनुमति के लिए precise:true.

lang एट्रिब्यूट

बटन का टेक्स्ट ब्राउज़र से मिलता है और इसे एक जैसा होना चाहिए. इसलिए, इसे सीधे तौर पर अपनी पसंद के मुताबिक नहीं बनाया जा सकता. ब्राउज़र, टेक्स्ट की भाषा को बदलता है. यह बदलाव, दस्तावेज़ या पैरंट एलिमेंट चेन की इनहेरिट की गई भाषा या lang एट्रिब्यूट के आधार पर होता है. इसका मतलब है कि डेवलपर को <permission> एलिमेंट को खुद स्थानीय भाषा में बदलने की ज़रूरत नहीं है. अगर <permission> एलिमेंट, ऑरिजिन ट्रायल स्टेज से आगे बढ़ता है, तो हर अनुमति के टाइप के लिए कई स्ट्रिंग या आइकॉन इस्तेमाल किए जा सकते हैं, ताकि ज़्यादा विकल्प मिल सकें. अगर आपको <permission> एलिमेंट का इस्तेमाल करना है और किसी खास स्ट्रिंग या आइकॉन की ज़रूरत है, तो हमसे संपर्क करें!

व्यवहार

जब उपयोगकर्ता <permission> एलिमेंट के साथ इंटरैक्ट करता है, तो वह अलग-अलग चरणों से गुज़र सकता है:

• अगर उन्होंने पहले किसी सुविधा के लिए अनुमति नहीं दी थी, तो वे हर बार वेबसाइट पर जाने के बाद, उसे सुविधा इस्तेमाल करने की अनुमति दे सकते हैं. इसके अलावा, वे सिर्फ़ मौजूदा विज़िट के लिए अनुमति दे सकते हैं.

  

• अगर उन्होंने पहले इस सुविधा को अनुमति दी थी, तो वे इसे जारी रख सकते हैं या बंद कर सकते हैं.

  

• अगर उन्होंने पहले किसी सुविधा को अनुमति नहीं दी थी, तो वे अब भी अनुमति न देने का विकल्प चुन सकते हैं. इसके अलावा, वे इस बार अनुमति दे सकते हैं.

  

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

सीएसएस डिज़ाइन

यह पक्का करने के लिए कि उपयोगकर्ता, बटन को आसानी से पहचान सकें और उसे बेहतर सुविधाओं को ऐक्सेस करने के लिए इस्तेमाल कर सकें, <permission> एलिमेंट की स्टाइलिंग पर पाबंदी लगाई गई है. अगर स्टाइलिंग से जुड़ी पाबंदियां आपके इस्तेमाल के उदाहरण के लिए काम नहीं करती हैं, तो हमें यह जानकर खुशी होगी कि ऐसा क्यों और कैसे हो रहा है! हालांकि, स्टाइलिंग से जुड़ी सभी ज़रूरतों को पूरा नहीं किया जा सकता. हम उम्मीद करते हैं कि ऑरिजिन ट्रायल के बाद, <permission> एलिमेंट की ज़्यादा स्टाइलिंग करने के सुरक्षित तरीके खोजे जा सकें. यहां दी गई टेबल में, कुछ ऐसी प्रॉपर्टी के बारे में बताया गया है जिन पर पाबंदियां लागू होती हैं या जिनके लिए खास नियम बनाए गए हैं. किसी भी नियम का उल्लंघन होने पर, <permission> एलिमेंट बंद हो जाएगा और इसके साथ इंटरैक्ट नहीं किया जा सकेगा. इससे इंटरैक्ट करने की कोशिश करने पर, अपवाद दिखेंगे. इन्हें JavaScript की मदद से पकड़ा जा सकता है. गड़बड़ी के मैसेज में, उल्लंघन के बारे में ज़्यादा जानकारी होगी.

इन सीएसएस प्रॉपर्टी का इस्तेमाल सामान्य तरीके से किया जा सकता है:

• font-kerning
• font-optical-sizing
• font-stretch
• font-synthesis-weight
• font-synthesis-style
• font-synthesis-small-caps
• font-feature-settings
• forced-color-adjust
• text-rendering
• align-self
• anchor-name aspect-ratio
• border (और सभी border-* प्रॉपर्टी)
• clear
• color-scheme
• contain
• contain-intrinsic-width
• contain-intrinsic-height
• container-name
• container-type
• counter-*
• flex-*
• float
• height
• isolation
• justify-self
• left
• order
• orphans
• outline-* (outline-offset के लिए पहले बताए गए अपवाद के साथ)
• overflow-anchor
• overscroll-behavior-*
• page
• position
• position-anchor
• content-visibility
• right
• scroll-margin-*
• scroll-padding-*
• text-spacing-trim
• top
• visibility
• x
• y
• ruby-position
• user-select
• width
• will-change
• z-index

इसके अलावा, लॉजिक के हिसाब से एक जैसी सभी प्रॉपर्टी का इस्तेमाल किया जा सकता है. उदाहरण के लिए, inline-size, width के बराबर है. हालांकि, इसके लिए वही नियम लागू होंगे जो इनकी बराबर वाली प्रॉपर्टी के लिए लागू होते हैं.

स्यूडो-क्लास

दो खास स्यूडो-क्लास हैं. इनकी मदद से, <permission> एलिमेंट को उसकी स्थिति के आधार पर स्टाइल किया जा सकता है:

• :granted: :granted सूडो-क्लास की मदद से, अनुमति मिलने पर खास स्टाइलिंग की जा सकती है.
• :invalid: :invalid सूडो-क्लास की मदद से, एलिमेंट के अमान्य होने पर खास स्टाइलिंग की जा सकती है. उदाहरण के लिए, जब इसे क्रॉस-ऑरिजिन iframe में दिखाया जाता है.

permission {
  background-color: green;
}

permission:granted {
  background-color: light-green;
}

/* Not supported during the origin trial. */
permission:invalid {
  background-color: gray;
}

JavaScript इवेंट

<permission> एलिमेंट का इस्तेमाल, Permissions API के साथ किया जाता है. ऐसे कई इवेंट हैं जिनके लिए सूचनाएं पाने की सुविधा चालू की जा सकती है:

• onpromptdismiss: यह इवेंट तब ट्रिगर होता है, जब उपयोगकर्ता ने एलिमेंट से ट्रिगर हुए अनुमति वाले प्रॉम्प्ट को खारिज कर दिया हो. उदाहरण के लिए, बंद करें बटन पर क्लिक करके या प्रॉम्प्ट के बाहर क्लिक करके.

• onpromptaction: यह इवेंट तब ट्रिगर होता है, जब उपयोगकर्ता ने एलिमेंट से ट्रिगर हुई अनुमति वाली सूचना पर कोई कार्रवाई की हो. इसका यह मतलब नहीं है कि अनुमति की स्थिति बदल गई है. ऐसा हो सकता है कि उपयोगकर्ता ने कोई ऐसी कार्रवाई की हो जिससे स्थिति में कोई बदलाव न हुआ हो. जैसे, किसी अनुमति को जारी रखने की अनुमति देना.

• onvalidationstatuschange: यह इवेंट तब ट्रिगर होता है, जब एलिमेंट "valid" से "invalid" में बदलता है. अगर उपयोगकर्ता किसी एलिमेंट पर क्लिक करता है, तो ब्राउज़र सिग्नल की इंटिग्रिटी पर भरोसा करता है. ऐसे में, एलिमेंट को "valid" माना जाता है. अगर ऐसा नहीं होता है, तो एलिमेंट को "invalid" माना जाता है. उदाहरण के लिए, जब एलिमेंट को कुछ हद तक अन्य एचटीएमएल कॉन्टेंट से छिपाया जाता है.

इन इवेंट के लिए, इवेंट लिसनर को सीधे तौर पर एचटीएमएल कोड (<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />) में रजिस्टर किया जा सकता है. इसके अलावा, <permission> एलिमेंट पर addEventListener() का इस्तेमाल करके भी रजिस्टर किया जा सकता है. इसका उदाहरण यहां दिया गया है.

<permission type="camera" />
<script>
  const permission = document.querySelector('permission');
  permission.addEventListener('promptdismiss', showCameraWarning);

  function showCameraWarning() {
    // Show warning that the app isn't fully usable
    // unless the camera permission is granted.
  }

  const permissionStatus = await navigator.permissions.query({name: "camera"});
  
  permissionStatus.addEventListener('change', () => {
    // Run the check when the status changes.
    if (permissionStatus.state === "granted") {
      useCamera();
    }
  });

  // Run the initial check.
  if (permissionStatus.state === "granted") {
    useCamera();
  }
</script>

फ़ीचर का पता लगाने की सुविधा

अगर कोई ब्राउज़र किसी एचटीएमएल एलिमेंट के साथ काम नहीं करता है, तो वह उसे नहीं दिखाएगा. इसका मतलब है कि अगर आपके एचटीएमएल कोड में <permission> एलिमेंट मौजूद है, तो ब्राउज़र को इसके बारे में जानकारी न होने पर कुछ नहीं होता. आपको अब भी JavaScript का इस्तेमाल करके, सहायता का पता लगाना पड़ सकता है. उदाहरण के लिए, किसी सामान्य <button> पर क्लिक करने से ट्रिगर होने वाला अनुमति प्रॉम्प्ट बनाने के लिए.

if ('HTMLPermissionElement' in window) {
  // The `<permission>` element is supported.
}

ऑरिजिन ट्रायल

अगर आपको अपनी साइट पर असल उपयोगकर्ताओं के साथ <permission> एलिमेंट आज़माना है, तो ऑरिजिन ट्रायल के लिए साइन अप करें. ऑरिजिन ट्रायल शुरू करना लेख पढ़ें. इसमें ऑरिजिन ट्रायल का इस्तेमाल करने के लिए, अपनी साइट को तैयार करने के बारे में निर्देश दिए गए हैं. ऑरिजिन ट्रायल, Chrome 126 से 131 (19 फ़रवरी, 2025) तक चलेगा.

डेमो

GitHub पर डेमो देखें और सोर्स कोड देखें. यहां ऐसे ब्राउज़र पर मिलने वाले अनुभव का स्क्रीनशॉट दिया गया है जिस पर यह सुविधा काम करती है.

सुझाव/राय दें या शिकायत करें

हमें यह जानकर खुशी होगी कि <permission> आपके इस्तेमाल के उदाहरण के लिए कैसे काम करता है. रिपॉज़िटरी में मौजूद समस्याओं में से किसी एक का जवाब दें या नई समस्या की जानकारी दें. <permission> एलिमेंट के लिए, repo में मौजूद सार्वजनिक सिग्नल से हमें और अन्य ब्राउज़र को पता चलेगा कि आपको इसमें दिलचस्पी है.

अक्सर पूछे जाने वाले सवाल

• यह, Permissions API के साथ इस्तेमाल किए जाने वाले सामान्य <button> से बेहतर कैसे है? <button> पर क्लिक करना, उपयोगकर्ता की एक गतिविधि है. हालांकि, ब्राउज़र के पास यह पुष्टि करने का कोई तरीका नहीं है कि यह अनुमति मांगने के अनुरोध से जुड़ा है. अगर उपयोगकर्ता ने <permission> पर क्लिक किया है, तो ब्राउज़र को यह पक्का हो सकता है कि क्लिक, अनुमति के अनुरोध से जुड़ा है. इससे ब्राउज़र को ऐसे फ़्लो को आसान बनाने में मदद मिलती है जो किसी और तरीके से ज़्यादा जोखिम भरे हो सकते हैं. उदाहरण के लिए, उपयोगकर्ता को किसी अनुमति को ब्लॉक करने की कार्रवाई को आसानी से पहले जैसा करने की सुविधा देना.
• अगर अन्य ब्राउज़र पर <permission> एलिमेंट काम नहीं करता है, तो क्या होगा? <permission> एलिमेंट का इस्तेमाल, प्रोग्रेसिव एन्हांसमेंट के तौर पर किया जा सकता है. जिन ब्राउज़र पर यह सुविधा काम नहीं करती है उन पर अनुमति देने के लिए, क्लासिक वर्शन वाली प्रोसेस का इस्तेमाल किया जा सकता है. उदाहरण के लिए, सामान्य <button> पर क्लिक करने के आधार पर. अनुमतियों से जुड़ी टीम भी एक पॉलीफ़िल पर काम कर रही है. GitHub repo को स्टार करें, ताकि इसके तैयार होने पर आपको सूचना मिल सके.
• क्या इस बारे में अन्य ब्राउज़र वेंडर से बात की गई थी? <permission> एलिमेंट पर, साल 2023 में W3C TPAC में ब्रेकआउट सेशन के दौरान चर्चा की गई थी. सार्वजनिक सेशन के नोट पढ़े जा सकते हैं. Chrome की टीम ने दोनों वेंडर से, स्टैंडर्ड के बारे में औपचारिक तौर पर जानकारी देने के लिए भी कहा है. इसके लिए, मिलते-जुलते लिंक सेक्शन देखें. <permission> एलिमेंट के बारे में, हम दूसरे ब्राउज़र के साथ लगातार बातचीत कर रहे हैं. हमें उम्मीद है कि हम इसे स्टैंडर्ड बना पाएंगे.
• क्या यह वाकई एक खाली एलिमेंट होना चाहिए? इस बारे में अब भी बहस जारी है कि <permission> को एक खाली एलिमेंट होना चाहिए या नहीं. अगर आपको कोई सुझाव/राय देनी है या शिकायत करनी है, तो इस समस्या के बारे में बताएं.

इसी विषय से जुड़े कुछ लिंक

• समझाने वाला
• WebKit Standards Position
• Mozilla Standards Position

Acknowledgements

इस दस्तावेज़ की समीक्षा बालाज़ एंगेडी, थॉमस न्गुयेन, पेनेलोपी मैकलोकलान, मैरियन हारबाख, डेविड वॉरेन, और राशेल ऐंड्रयू ने की है.