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

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 के बराबर है) का इस्तेमाल किया जा सकता है. इसके लिए, उन ही नियमों का पालन किया जाना चाहिए जो उनके बराबर हैं.

सूडो-क्लास

दो खास pseudo-classes हैं, जो <permission> एलिमेंट को स्थिति के हिसाब से स्टाइल करने की सुविधा देते हैं:

• :granted: अनुमति मिलने पर, :granted pseudo-class एट्रिब्यूट की मदद से खास स्टाइलिंग की जा सकती है.
• :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> एलिमेंट को अनुमतियां एपीआई के साथ इस्तेमाल किया जाना चाहिए. ऐसे कई इवेंट हैं जिन्हें सुना जा सकता है:

• 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 रेपो के तैयार होने पर सूचना पाने के लिए, उस पर स्टार का निशान लगाएं.
• क्या इस बारे में दूसरे ब्राउज़र वेंडर के साथ चर्चा की गई थी? साल 2023 में, एक ब्रेकआउट सेशन के दौरान, W3C TPAC में <permission> एलिमेंट के बारे में चर्चा की गई थी. सार्वजनिक सेशन के नोट पढ़े जा सकते हैं. Chrome टीम ने दोनों वेंडर से औपचारिक मानक स्थिति के बारे में बताने के लिए भी कहा है. इसी विषय से जुड़े लिंक सेक्शन देखें. <permission> एलिमेंट पर दूसरे ब्राउज़र के साथ चर्चा जारी है और हमें उम्मीद है कि हम इसके लिए स्टैंडर्ड तय करेंगे.
• क्या इसे सच में एक अमान्य एलिमेंट होना चाहिए? इस पर अब भी इस पर चर्चा चल रही है कि <permission> को एक शून्य एलिमेंट होना चाहिए या नहीं. अगर आपका कोई सुझाव/शिकायत/राय है, तो इस समस्या के बारे में अपनी राय दें.

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

• पूरी जानकारी देने वाला वीडियो
• WebKit के मानकों की जगह
• Mozilla मानक स्थिति

स्वीकार की गई

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