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

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.permissions.request() के ज़रिए साफ़ तौर पर अनुमति मांगने का तरीका कहा जाता था. हालांकि, स्पेसिफ़िकेशन के रिपॉज़िटरी में समस्या #83 के बारे में चर्चा करने के बाद, इसे Permissions API से हटा दिया गया. इन तरीकों (इस्तेमाल करने पर साफ़ तौर पर अनुमति मांगना और साफ़ तौर पर अनुमति का अनुरोध करना) में से "सही" तरीका चुनने के बारे में काफ़ी चर्चा की गई है. हालांकि, इस बारे में कोई साफ़ जवाब नहीं मिला है.

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

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

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

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

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

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

संदर्भ के हिसाब से अनुमति मांगना

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

आसानी से पहले जैसा नहीं किया जा सकता

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

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

जानकारी देने वाला <permission> एलिमेंट

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

<permission type="camera" />

ध्यान दें: पेज में एम्बेड की गई अनुमति कंट्रोल (पीईपीसी, जिसे "पीईपी-सी" कहा जाता है) एक बड़े प्रोग्राम का नाम है. इसका मकसद, कॉन्टेंट एरिया में ज़्यादा कंट्रोल एम्बेड करना है. इस वजह से, आपको कभी-कभी लोगों को <permission> को पीईपीसी के तौर पर रेफ़र करते हुए दिख सकता है.

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

type एट्रिब्यूट

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

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

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

lang एट्रिब्यूट

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

ध्यान दें: ऑरिजिन ट्रायल के दौरान, lang एट्रिब्यूट का इस्तेमाल नहीं किया जा सकेगा. इसके बजाय, ब्राउज़र में सेट की गई भाषा का इस्तेमाल किया जाएगा.

व्यवहार

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

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

  

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

  

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

  

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

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

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

प्रॉपर्टी	नियम
color, background-color	इनका इस्तेमाल, टेक्स्ट और बैकग्राउंड का रंग सेट करने के लिए किया जा सकता है. टेक्स्ट को साफ़ तौर पर पढ़ा जा सके, इसके लिए दो रंगों के बीच का कंट्रास्ट ज़रूरत के मुताबिक होना चाहिए. कंट्रास्ट का अनुपात कम से कम 3 होना चाहिए. अल्फा चैनल की वैल्यू 1 होनी चाहिए.
font-size, zoom	यह वैल्यू, small और xxxlarge के बराबर होनी चाहिए. ऐसा न करने पर, एलिमेंट बंद कर दिया जाएगा. font-size का हिसाब लगाते समय, ज़ूम को ध्यान में रखा जाएगा.
outline-offset	नेगेटिव वैल्यू को 0 में बदल दिया जाएगा.
margin (सभी)	नेगेटिव वैल्यू को 0 में बदल दिया जाएगा.
font-weight	200 से कम वैल्यू को 200 पर सेट कर दिया जाएगा.
font-style	normal और italic के अलावा अन्य वैल्यू को normal में बदल दिया जाएगा.
word-spacing	0.5em से ज़्यादा की वैल्यू को 0.5em पर सेट कर दिया जाएगा. 0 से कम वैल्यू को 0 पर सेट कर दिया जाएगा.
display	inline-block और none के अलावा अन्य वैल्यू को inline-block पर सेट कर दिया जाएगा.
letter-spacing	0.2em से ज़्यादा की वैल्यू को 0.2em पर सेट कर दिया जाएगा. -0.05em से कम वैल्यू को -0.05em पर सेट कर दिया जाएगा.
min-height	इसकी डिफ़ॉल्ट वैल्यू 1em होगी. अगर वैल्यू दी गई है, तो डिफ़ॉल्ट और दी गई वैल्यू के बीच की सबसे बड़ी वैल्यू का इस्तेमाल किया जाएगा.
max-height	इसकी डिफ़ॉल्ट वैल्यू 3em होगी. अगर वैल्यू दी गई है, तो डिफ़ॉल्ट और दी गई वैल्यू के बीच की कम से कम वैल्यू का इस्तेमाल किया जाएगा.
min-width	इसकी डिफ़ॉल्ट वैल्यू fit-content होगी. अगर वैल्यू दी गई है, तो डिफ़ॉल्ट और दी गई वैल्यू के बीच की सबसे बड़ी वैल्यू को कैलकुलेट किया जाएगा.
max-width	इसकी डिफ़ॉल्ट वैल्यू, fit-content की तीन गुनी होगी. अगर वैल्यू दी गई है, तो डिफ़ॉल्ट और दी गई वैल्यू के बीच की सबसे कम वैल्यू को कैलकुलेट किया जाएगा.
padding-top	यह सिर्फ़ तब लागू होगा, जब height को auto पर सेट किया गया हो. इस मामले में, 1em से ज़्यादा की वैल्यू को 1em पर ठीक कर दिया जाएगा और padding-bottom को padding-top की वैल्यू पर सेट कर दिया जाएगा.
padding-left	यह सिर्फ़ तब लागू होगा, जब width को auto पर सेट किया गया हो. इस मामले में, 5em से ज़्यादा की वैल्यू को 5em पर ठीक कर दिया जाएगा और padding-right को padding-left. की वैल्यू पर सेट कर दिया जाएगा
transform	वीडियो में विज़ुअल इफ़ेक्ट का इस्तेमाल करके, उसे गलत तरीके से दिखाने की अनुमति नहीं है. फ़िलहाल, हम सिर्फ़ 2D ट्रांसलेशन और प्रॉपोर्टional अप-स्केलिंग स्वीकार करते हैं.

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

• 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 में दिखाया जाता है.

ध्यान दें: ऑरिजिन ट्रायल के दौरान, :invalid स्यूडो-क्लास काम नहीं करेगा.

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: यह इवेंट तब ट्रिगर होता है, जब उपयोगकर्ता ने एलिमेंट से ट्रिगर किए गए अनुमति के अनुरोध को खारिज कर दिया हो. उदाहरण के लिए, 'बंद करें' बटन पर क्लिक करके या अनुरोध के बाहर क्लिक करके.

  ध्यान दें: ऑरिजिन ट्रायल के दौरान, इसे ondismiss कहा जाएगा. हालांकि, इसका आखिरी नाम onpromptdismiss होगा. 'ondismiss' in HTMLPermissionElement.prototype का इस्तेमाल करके, काम करने वाले इवेंट के नाम का पता लगाया जा सकता है.

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

  ध्यान दें: ऑरिजिन ट्रायल के दौरान, इसे onresolve कहा जाएगा. हालांकि, इसका आखिरी नाम onpromptaction होगा. इस्तेमाल किए जा सकने वाले इवेंट के नाम का पता लगाने के लिए, 'onresolve' in HTMLPermissionElement.prototype
  का इस्तेमाल किया जा सकता है.

• 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 में मौजूद सार्वजनिक सिग्नल से, हमें और दूसरे ब्राउज़र को पता चलेगा कि आपके पास इस एलिमेंट में दिलचस्पी है.

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

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

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

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

आभार

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