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

Thomas Steiner

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

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

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

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

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

Notification API या Device Orientation and Motion API जैसे अन्य एपीआई के लिए, आम तौर पर अनुमति का अनुरोध करने का एक खास तरीका होता है. यह तरीका, स्टैटिक तरीके से किया जाता है. जैसे, 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 pseudo-class, खास स्टाइलिंग की अनुमति तब देता है, जब एलिमेंट किसी अमान्य स्थिति में हो. उदाहरण के लिए, जब उसे किसी क्रॉस-ऑरिजिन 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> एलिमेंट के लिए रिपो में मौजूद सार्वजनिक सिग्नल से, हमें और दूसरे ब्राउज़र को पता चलेगा कि आपके पास उसमें दिलचस्पी है.

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

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

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

• एक्सप्लेनर
• WebKit स्टैंडर्ड की स्थिति
• Mozilla के स्टैंडर्ड के बारे में जानकारी

स्वीकार की गई

इस दस्तावेज़ की समीक्षा Balázs Engedy, थॉमस गुएन, पेनेलोप मैकलाचैन, मैरियन हार्बैक, डेविड वॉरेन, रेचल एंड्रयू ने की है.