একটি নতুন HTML <অনুমতি> এর জন্য একটি মূল ট্রায়াল উপাদান

Thomas Steiner

ওয়েব অ্যাপে লোকেশন অ্যাক্সেসের মতো শক্তিশালী বৈশিষ্ট্যগুলি ব্যবহার করার জন্য অনুমতি চাওয়ার জন্য বেশ কয়েকটি অপরিহার্য পদ্ধতি রয়েছে। এই পদ্ধতিগুলির সাথে বেশ কয়েকটি চ্যালেঞ্জ আসে, যে কারণে Chrome অনুমতি দল একটি নতুন ঘোষণামূলক পদ্ধতি নিয়ে পরীক্ষা-নিরীক্ষা করছে: একটি ডেডিকেটেড HTML <permission> উপাদান। এই উপাদানটি Chrome 126 থেকে উৎপাদিত হয়েছে এবং শেষ পর্যন্ত আমরা এটিকে মানসম্মত করার আশা করি।

অনুমতি চাওয়ার জন্য প্রয়োজনীয় পদ্ধতি

যখন ওয়েব অ্যাপগুলিকে শক্তিশালী বৈশিষ্ট্যগুলিতে অ্যাক্সেসের প্রয়োজন হয়, তখন তাদের অনুমতি চাইতে হয়। উদাহরণস্বরূপ, যখন গুগল ম্যাপ জিওলোকেশন এপিআই ব্যবহার করে ব্যবহারকারীর অবস্থান জানতে চায়, তখন ব্রাউজারগুলি ব্যবহারকারীকে অনুরোধ করবে, প্রায়শই সেই সিদ্ধান্ত সংরক্ষণ করার বিকল্প সহ। এটি অনুমতি স্পেসিফিকেশনে একটি সুনির্দিষ্ট ধারণা ।

প্রথম ব্যবহারেই স্পষ্টভাবে জিজ্ঞাসা করা বনাম স্পষ্টভাবে আগে থেকে অনুরোধ করা

জিওলোকেশন এপিআই একটি শক্তিশালী এপিআই এবং এটি প্রথম ব্যবহারের জন্য পরোক্ষভাবে জিজ্ঞাসা করার পদ্ধতির উপর নির্ভর করে। উদাহরণস্বরূপ, যখন কোনও অ্যাপ navigator.geolocation.getCurrentPosition() পদ্ধতিতে কল করে, তখন প্রথম কলের সাথে সাথেই অনুমতি প্রম্পট স্বয়ংক্রিয়ভাবে পপ আপ হয়। আরেকটি উদাহরণ হল navigator.mediaDevices.getUserMedia() ।

অন্যান্য API, যেমন 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 অনুমতি দল একটি নতুন HTML উপাদান, <permission> এর জন্য একটি অরিজিন ট্রায়াল শুরু করেছে। এই উপাদানটি ডেভেলপারদের ওয়েবসাইটগুলিতে উপলব্ধ শক্তিশালী বৈশিষ্ট্যগুলির একটি উপসেট ব্যবহারের জন্য ঘোষণামূলকভাবে অনুমতি চাইতে দেয়। এর সহজতম আকারে, আপনি এটি নিম্নলিখিত উদাহরণের মতো ব্যবহার করতে পারেন:

<permission type="camera" />

<permission> একটি void উপাদান হিসেবে ব্যবহার করা উচিত কিনা তা নিয়ে এখনও সক্রিয়ভাবে বিতর্ক চলছে। void উপাদান হল HTML-এ একটি স্ব-বন্ধ উপাদান যার কোনও চাইল্ড নোড থাকতে পারে না, যার অর্থ HTML-এ এর কোনও end ট্যাগ নাও থাকতে পারে।

type অ্যাট্রিবিউট

type অ্যাট্রিবিউটে আপনার অনুরোধ করা অনুমতিগুলির একটি স্থান-বিভাজিত তালিকা রয়েছে। এই লেখার সময়, অনুমোদিত মানগুলি হল 'camera' , 'microphone' , এবং camera microphone (স্থান দ্বারা পৃথক)। ডিফল্টরূপে এই উপাদানটি বেয়ারবোনস ব্যবহারকারী এজেন্ট স্টাইলিং সহ বোতামগুলির মতো রেন্ডার করে।

type-ext অ্যাট্রিবিউট

কিছু অনুমতির জন্য যা অতিরিক্ত প্যারামিটারের জন্য অনুমতি দেয়, type-ext অ্যাট্রিবিউট স্থান-বিচ্ছিন্ন কী-মান জোড়া গ্রহণ করে, যেমন, উদাহরণস্বরূপ, ভূ-অবস্থান অনুমতির জন্য precise:true ।

lang অ্যাট্রিবিউট

বোতামের টেক্সট ব্রাউজার দ্বারা সরবরাহ করা হয় এবং এটি সামঞ্জস্যপূর্ণ হওয়ার জন্য তৈরি করা হয়, তাই এটি সরাসরি কাস্টমাইজ করা যায় না। ব্রাউজারটি ডকুমেন্টের উত্তরাধিকারসূত্রে প্রাপ্ত ভাষা বা প্যারেন্ট এলিমেন্ট চেইন, অথবা একটি ঐচ্ছিক lang অ্যাট্রিবিউটের উপর ভিত্তি করে টেক্সটের ভাষা পরিবর্তন করে। এর অর্থ হল ডেভেলপারদের <permission> এলিমেন্টটি নিজেরাই স্থানীয়করণ করতে হবে না। যদি <permission> এলিমেন্টটি অরিজিন ট্রায়াল পর্যায়ের বাইরে চলে যায়, তাহলে নমনীয়তা বাড়ানোর জন্য প্রতিটি অনুমতির ধরণের জন্য বেশ কয়েকটি স্ট্রিং বা আইকন সমর্থিত হতে পারে। আপনি যদি <permission> এলিমেন্টটি ব্যবহার করতে আগ্রহী হন এবং একটি নির্দিষ্ট স্ট্রিং বা আইকনের প্রয়োজন হয়, তাহলে যোগাযোগ করুন !

আচরণ

যখন ব্যবহারকারী <permission> এলিমেন্টের সাথে ইন্টারঅ্যাক্ট করে, তখন তারা বিভিন্ন ধাপ অতিক্রম করতে পারে:

• যদি তারা আগে কোনও বৈশিষ্ট্যের অনুমতি না দিয়ে থাকে, তাহলে তারা প্রতিটি ভিজিটে এটির অনুমতি দিতে পারে, অথবা বর্তমান ভিজিটের জন্য এটির অনুমতি দিতে পারে।

  

• যদি তারা আগে এই বৈশিষ্ট্যটির অনুমতি দিয়ে থাকে, তাহলে তারা এটির অনুমতি দেওয়া চালিয়ে যেতে পারে, অথবা এটির অনুমতি দেওয়া বন্ধ করতে পারে।

  

• যদি তারা আগে কোনও বৈশিষ্ট্যকে অনুমতি না দিয়ে থাকে, তাহলে তারা এটিকে অনুমতি না দেওয়া চালিয়ে যেতে পারে, অথবা এবারও অনুমতি দিতে পারে।

  

<permission> এলিমেন্টের টেক্সট স্ট্যাটাসের উপর ভিত্তি করে স্বয়ংক্রিয়ভাবে আপডেট হয়। উদাহরণস্বরূপ, যদি কোনও ফিচার ব্যবহারের অনুমতি দেওয়া হয়, তাহলে টেক্সটটি পরিবর্তিত হয়ে বলা হয় যে ফিচারটি অনুমোদিত। যদি প্রথমে অনুমতি দেওয়ার প্রয়োজন হয়, তাহলে টেক্সটটি পরিবর্তিত হয়ে ব্যবহারকারীকে ফিচারটি ব্যবহার করার জন্য আমন্ত্রণ জানায়। দুটি অবস্থা দেখতে আগের স্ক্রিনশটটি নিম্নলিখিত স্ক্রিনশটের সাথে তুলনা করুন।

সিএসএস ডিজাইন

ব্যবহারকারীরা যাতে শক্তিশালী ক্ষমতা অ্যাক্সেস করার জন্য বোতামটিকে সহজেই একটি পৃষ্ঠ হিসেবে চিনতে পারেন, তার জন্য <permission> এলিমেন্টের স্টাইলিং সীমাবদ্ধ। যদি স্টাইলিং সীমাবদ্ধতা আপনার ব্যবহারের ক্ষেত্রে কাজ না করে, তাহলে আমরা কীভাবে এবং কেন তা জানতে আগ্রহী ! যদিও সমস্ত স্টাইলিং চাহিদা পূরণ করা সম্ভব নয়, আমরা আশা করছি যে অরিজিন ট্রায়ালের পরে <permission> এলিমেন্টের আরও স্টাইলিং করার নিরাপদ উপায় আবিষ্কার করা যাবে। নিম্নলিখিত সারণীতে এমন কিছু বৈশিষ্ট্যের বিবরণ দেওয়া হয়েছে যার উপর বিধিনিষেধ বা বিশেষ নিয়ম প্রয়োগ করা হয়েছে। যদি কোনও নিয়ম লঙ্ঘন করা হয়, তাহলে <permission> এলিমেন্টটি অক্ষম করা হবে এবং এর সাথে ইন্টারঅ্যাক্ট করা যাবে না। এর সাথে ইন্টারঅ্যাক্ট করার যেকোনো প্রচেষ্টার ফলে ব্যতিক্রম দেখা দেবে যা জাভাস্ক্রিপ্ট ব্যবহার করে ধরা পড়তে পারে। ত্রুটি বার্তায় সনাক্ত হওয়া লঙ্ঘনের বিষয়ে আরও বিশদ থাকবে।

নিম্নলিখিত CSS বৈশিষ্ট্যগুলি স্বাভাবিক হিসাবে ব্যবহার করা যেতে পারে:

• 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 বিশেষ স্টাইলিং করার অনুমতি দেয় যখন উপাদানটি একটি অবৈধ অবস্থায় থাকে, উদাহরণস্বরূপ, যখন এটি একটি ক্রস-অরিজিন আইফ্রেমে পরিবেশিত হয়।

permission {
  background-color: green;
}

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

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

জাভাস্ক্রিপ্ট ইভেন্ট

<permission> এলিমেন্টটি Permissions API এর সাথে একসাথে ব্যবহার করার জন্য তৈরি। বেশ কিছু ইভেন্ট শোনা যেতে পারে:

• onpromptdismiss : এই ইভেন্টটি তখনই কার্যকর হয় যখন উপাদানটির দ্বারা ট্রিগার করা অনুমতি প্রম্পট ব্যবহারকারী দ্বারা বাতিল করা হয় (উদাহরণস্বরূপ, বন্ধ বোতামে ক্লিক করে বা প্রম্পটের বাইরে ক্লিক করে)।

• onpromptaction : এই ইভেন্টটি তখনই কার্যকর হয় যখন ব্যবহারকারীর দ্বারা ট্রিগার করা অনুমতি প্রম্পটটি সমাধান হয়ে যায় যখন ব্যবহারকারী প্রম্পটে কিছু পদক্ষেপ নেয়। এর অর্থ এই নয় যে অনুমতির অবস্থা পরিবর্তিত হয়েছে, ব্যবহারকারী এমন কোনও পদক্ষেপ নিতে পারেন যা স্থিতাবস্থা বজায় রাখে (যেমন অনুমতি প্রদান অব্যাহত রাখা)।

• onvalidationstatuschange : যখন উপাদানটি "valid" থেকে "invalid" তে স্যুইচ করে তখন এই ইভেন্টটি কার্যকর হয়। ব্যবহারকারী যদি সিগন্যালটি ক্লিক করে তবে ব্রাউজার যখন সিগন্যালের অখণ্ডতার উপর বিশ্বাস করে তখন উপাদানটিকে "valid" বলে মনে করা হয়, এবং অন্যথায় "invalid" মনে করা হয়, উদাহরণস্বরূপ, যখন উপাদানটি অন্যান্য HTML কন্টেন্ট দ্বারা আংশিকভাবে আটকে থাকে।

আপনি এই ইভেন্টগুলির জন্য ইভেন্ট লিসেনারের নিবন্ধন সরাসরি HTML কোডে ( <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>

বৈশিষ্ট্য সনাক্তকরণ

যদি কোন ব্রাউজার কোন HTML এলিমেন্ট সাপোর্ট না করে, তাহলে এটি তা দেখাবে না। এর মানে হল, যদি আপনার HTML কোডে <permission> এলিমেন্ট থাকে, তাহলে ব্রাউজার যদি এটি না জানে তাহলে কিছুই হবে না। আপনি এখনও জাভাস্ক্রিপ্ট ব্যবহার করে সাপোর্ট সনাক্ত করতে চাইতে পারেন, উদাহরণস্বরূপ, একটি নিয়মিত <button> ক্লিকের মাধ্যমে ট্রিগার করা একটি অনুমতি প্রম্পট তৈরি করতে।

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

অরিজিন ট্রায়াল

আপনার সাইটে প্রকৃত ব্যবহারকারীদের সাথে <permission> উপাদানটি চেষ্টা করার জন্য, অরিজিন ট্রায়ালের জন্য সাইন আপ করুন । অরিজিন ট্রায়াল ব্যবহারের জন্য আপনার সাইটকে কীভাবে প্রস্তুত করবেন তার নির্দেশাবলীর জন্য "অরিজিন ট্রায়াল দিয়ে শুরু করুন" পড়ুন। অরিজিন ট্রায়ালটি Chrome 126 থেকে 131 (19 ফেব্রুয়ারী, 2025) পর্যন্ত চলবে।

ডেমো

ডেমোটি ঘুরে দেখুন এবং GitHub-এ সোর্স কোডটি দেখুন। এখানে একটি সাপোর্টিং ব্রাউজারে অভিজ্ঞতার একটি স্ক্রিনশট দেওয়া হল।

প্রতিক্রিয়া

আপনার ব্যবহারের ক্ষেত্রে <permission> কীভাবে কাজ করে তা আমরা আপনার কাছ থেকে জানতে আগ্রহী। রিপোজিটরিতে থাকা যেকোনো একটি সমস্যার সমাধান করতে দ্বিধা করবেন না, অথবা একটি নতুন সমস্যা ফাইল করবেন। <permission> এলিমেন্টের জন্য রেপোতে থাকা পাবলিক সিগন্যাল আমাদের এবং অন্যান্য ব্রাউজারগুলিকে জানাবে যে আপনি এতে আগ্রহী।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

• Permissions API-এর সাথে যুক্ত একটি নিয়মিত <button> চেয়ে এটি কীভাবে ভালো? <button> এর একটি ক্লিক ব্যবহারকারীর অঙ্গভঙ্গি, কিন্তু ব্রাউজারগুলির কাছে এটি যাচাই করার কোনও উপায় নেই যে এটি অনুমতি চাওয়ার অনুরোধের সাথে সংযুক্ত। যদি ব্যবহারকারী একটি <permission> ক্লিক করে থাকেন, তাহলে ব্রাউজার নিশ্চিত হতে পারে যে ক্লিকটি একটি অনুমতি অনুরোধের সাথে সম্পর্কিত। এটি ব্রাউজারকে এমন প্রবাহগুলিকে সহজতর করতে দেয় যা অন্যথায় অনেক বেশি ঝুঁকিপূর্ণ হবে। উদাহরণস্বরূপ, ব্যবহারকারীকে সহজেই অনুমতি ব্লক করা পূর্বাবস্থায় ফিরিয়ে আনতে দেয়।
• যদি অন্য ব্রাউজারগুলি <permission> উপাদানটিকে সমর্থন না করে তবে কী হবে? <permission> উপাদানটিকে একটি প্রগতিশীল বর্ধন হিসাবে ব্যবহার করা যেতে পারে। অ-সমর্থিত ব্রাউজারগুলিতে, একটি ক্লাসিক অনুমতি প্রবাহ ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, একটি নিয়মিত <button> ক্লিকের উপর ভিত্তি করে। অনুমতি দলটি একটি পলিফিলের উপরও কাজ করছে। GitHub রেপো প্রস্তুত হলে বিজ্ঞপ্তি পেতে তারকাচিহ্নিত করুন।
• অন্যান্য ব্রাউজার বিক্রেতাদের সাথে কি এই বিষয়ে আলোচনা করা হয়েছিল? <permission> উপাদানটি 2023 সালে W3C TPAC-তে একটি ব্রেকআউট সেশনে সক্রিয়ভাবে আলোচনা করা হয়েছিল। আপনি পাবলিক সেশন নোটগুলি পড়তে পারেন। Chrome টিম উভয় বিক্রেতার কাছ থেকে আনুষ্ঠানিক স্ট্যান্ডার্ড পজিশনের জন্যও অনুরোধ করেছে, সম্পর্কিত লিঙ্ক বিভাগটি দেখুন। <permission> উপাদানটি অন্যান্য ব্রাউজারগুলির সাথে আলোচনার একটি চলমান বিষয় এবং আমরা এটিকে মানসম্মত করার আশা করছি।
• এটি কি আসলেই একটি অকার্যকর উপাদান হওয়া উচিত? <permission> একটি অকার্যকর উপাদান হওয়া উচিত কিনা তা নিয়ে এখনও সক্রিয়ভাবে বিতর্ক চলছে। যদি আপনার কোন প্রতিক্রিয়া থাকে, তাহলে সমস্যাটি সম্পর্কে যোগাযোগ করুন।

সম্পর্কিত লিঙ্কগুলি

• ব্যাখ্যাকারী
• ওয়েবকিট স্ট্যান্ডার্ড পজিশন
• মজিলা স্ট্যান্ডার্ডস পজিশন

স্বীকৃতি

এই নথিটি বালাজস এনগেডি , থমাস নগুয়েন , পেনেলোপ ম্যাকলাচলান , মারিয়ান হারবাখ , ডেভিড ওয়ারেন এবং র‍্যাচেল অ্যান্ড্রু পর্যালোচনা করেছেন।

Thomas Steiner

ওয়েব অ্যাপে লোকেশন অ্যাক্সেসের মতো শক্তিশালী বৈশিষ্ট্যগুলি ব্যবহার করার জন্য অনুমতি চাওয়ার জন্য বেশ কয়েকটি অপরিহার্য পদ্ধতি রয়েছে। এই পদ্ধতিগুলির সাথে বেশ কয়েকটি চ্যালেঞ্জ আসে, যে কারণে Chrome অনুমতি দল একটি নতুন ঘোষণামূলক পদ্ধতি নিয়ে পরীক্ষা-নিরীক্ষা করছে: একটি ডেডিকেটেড HTML <permission> উপাদান। এই উপাদানটি Chrome 126 থেকে উৎপাদিত হয়েছে এবং শেষ পর্যন্ত আমরা এটিকে মানসম্মত করার আশা করি।

অনুমতি চাওয়ার জন্য প্রয়োজনীয় পদ্ধতি

যখন ওয়েব অ্যাপগুলিকে শক্তিশালী বৈশিষ্ট্যগুলিতে অ্যাক্সেসের প্রয়োজন হয়, তখন তাদের অনুমতি চাইতে হয়। উদাহরণস্বরূপ, যখন গুগল ম্যাপ জিওলোকেশন এপিআই ব্যবহার করে ব্যবহারকারীর অবস্থান জানতে চায়, তখন ব্রাউজারগুলি ব্যবহারকারীকে অনুরোধ করবে, প্রায়শই সেই সিদ্ধান্ত সংরক্ষণ করার বিকল্প সহ। এটি অনুমতি স্পেসিফিকেশনে একটি সুনির্দিষ্ট ধারণা ।

প্রথম ব্যবহারেই স্পষ্টভাবে জিজ্ঞাসা করা বনাম স্পষ্টভাবে আগে থেকে অনুরোধ করা

জিওলোকেশন এপিআই একটি শক্তিশালী এপিআই এবং এটি প্রথম ব্যবহারের জন্য পরোক্ষভাবে জিজ্ঞাসা করার পদ্ধতির উপর নির্ভর করে। উদাহরণস্বরূপ, যখন কোনও অ্যাপ navigator.geolocation.getCurrentPosition() পদ্ধতিতে কল করে, তখন প্রথম কলের সাথে সাথেই অনুমতি প্রম্পট স্বয়ংক্রিয়ভাবে পপ আপ হয়। আরেকটি উদাহরণ হল navigator.mediaDevices.getUserMedia() ।

অন্যান্য API, যেমন 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 অনুমতি দল একটি নতুন HTML উপাদান, <permission> এর জন্য একটি অরিজিন ট্রায়াল শুরু করেছে। এই উপাদানটি ডেভেলপারদের ওয়েবসাইটগুলিতে উপলব্ধ শক্তিশালী বৈশিষ্ট্যগুলির একটি উপসেট ব্যবহারের জন্য ঘোষণামূলকভাবে অনুমতি চাইতে দেয়। এর সহজতম আকারে, আপনি এটি নিম্নলিখিত উদাহরণের মতো ব্যবহার করতে পারেন:

<permission type="camera" />

<permission> একটি void উপাদান হিসেবে ব্যবহার করা উচিত কিনা তা নিয়ে এখনও সক্রিয়ভাবে বিতর্ক চলছে। void উপাদান হল HTML-এ একটি স্ব-বন্ধ উপাদান যার কোনও চাইল্ড নোড থাকতে পারে না, যার অর্থ HTML-এ এর কোনও end ট্যাগ নাও থাকতে পারে।

type অ্যাট্রিবিউট

type অ্যাট্রিবিউটে আপনার অনুরোধ করা অনুমতিগুলির একটি স্থান-বিভাজিত তালিকা রয়েছে। এই লেখার সময়, অনুমোদিত মানগুলি হল 'camera' , 'microphone' , এবং camera microphone (স্থান দ্বারা পৃথক)। ডিফল্টরূপে এই উপাদানটি বেয়ারবোনস ব্যবহারকারী এজেন্ট স্টাইলিং সহ বোতামগুলির মতো রেন্ডার করে।

type-ext অ্যাট্রিবিউট

কিছু অনুমতির জন্য যা অতিরিক্ত প্যারামিটারের জন্য অনুমতি দেয়, type-ext অ্যাট্রিবিউট স্থান-বিচ্ছিন্ন কী-মান জোড়া গ্রহণ করে, যেমন, উদাহরণস্বরূপ, ভূ-অবস্থান অনুমতির জন্য precise:true ।

lang অ্যাট্রিবিউট

বোতামের টেক্সট ব্রাউজার দ্বারা সরবরাহ করা হয় এবং এটি সামঞ্জস্যপূর্ণ হওয়ার জন্য তৈরি করা হয়, তাই এটি সরাসরি কাস্টমাইজ করা যায় না। ব্রাউজারটি ডকুমেন্টের উত্তরাধিকারসূত্রে প্রাপ্ত ভাষা বা প্যারেন্ট এলিমেন্ট চেইন, অথবা একটি ঐচ্ছিক lang অ্যাট্রিবিউটের উপর ভিত্তি করে টেক্সটের ভাষা পরিবর্তন করে। এর অর্থ হল ডেভেলপারদের <permission> এলিমেন্টটি নিজেরাই স্থানীয়করণ করতে হবে না। যদি <permission> এলিমেন্টটি অরিজিন ট্রায়াল পর্যায়ের বাইরে চলে যায়, তাহলে নমনীয়তা বাড়ানোর জন্য প্রতিটি অনুমতির ধরণের জন্য বেশ কয়েকটি স্ট্রিং বা আইকন সমর্থিত হতে পারে। আপনি যদি <permission> এলিমেন্টটি ব্যবহার করতে আগ্রহী হন এবং একটি নির্দিষ্ট স্ট্রিং বা আইকনের প্রয়োজন হয়, তাহলে যোগাযোগ করুন !

আচরণ

যখন ব্যবহারকারী <permission> এলিমেন্টের সাথে ইন্টারঅ্যাক্ট করে, তখন তারা বিভিন্ন ধাপ অতিক্রম করতে পারে:

• যদি তারা আগে কোনও বৈশিষ্ট্যের অনুমতি না দিয়ে থাকে, তাহলে তারা প্রতিটি ভিজিটে এটির অনুমতি দিতে পারে, অথবা বর্তমান ভিজিটের জন্য এটির অনুমতি দিতে পারে।

  

• যদি তারা আগে এই বৈশিষ্ট্যটির অনুমতি দিয়ে থাকে, তাহলে তারা এটির অনুমতি দেওয়া চালিয়ে যেতে পারে, অথবা এটির অনুমতি দেওয়া বন্ধ করতে পারে।

  

• যদি তারা আগে কোনও বৈশিষ্ট্যকে অনুমতি না দিয়ে থাকে, তাহলে তারা এটিকে অনুমতি না দেওয়া চালিয়ে যেতে পারে, অথবা এবারও অনুমতি দিতে পারে।

  

<permission> এলিমেন্টের টেক্সট স্ট্যাটাসের উপর ভিত্তি করে স্বয়ংক্রিয়ভাবে আপডেট হয়। উদাহরণস্বরূপ, যদি কোনও ফিচার ব্যবহারের অনুমতি দেওয়া হয়, তাহলে টেক্সটটি পরিবর্তিত হয়ে বলা হয় যে ফিচারটি অনুমোদিত। যদি প্রথমে অনুমতি দেওয়ার প্রয়োজন হয়, তাহলে টেক্সটটি পরিবর্তিত হয়ে ব্যবহারকারীকে ফিচারটি ব্যবহার করার জন্য আমন্ত্রণ জানায়। দুটি অবস্থা দেখতে আগের স্ক্রিনশটটি নিম্নলিখিত স্ক্রিনশটের সাথে তুলনা করুন।

সিএসএস ডিজাইন

ব্যবহারকারীরা যাতে শক্তিশালী ক্ষমতা অ্যাক্সেস করার জন্য বোতামটিকে সহজেই একটি পৃষ্ঠ হিসেবে চিনতে পারেন, তার জন্য <permission> এলিমেন্টের স্টাইলিং সীমাবদ্ধ। যদি স্টাইলিং সীমাবদ্ধতা আপনার ব্যবহারের ক্ষেত্রে কাজ না করে, তাহলে আমরা কীভাবে এবং কেন তা জানতে আগ্রহী ! যদিও সমস্ত স্টাইলিং চাহিদা পূরণ করা সম্ভব নয়, আমরা আশা করছি যে অরিজিন ট্রায়ালের পরে <permission> এলিমেন্টের আরও স্টাইলিং করার নিরাপদ উপায় আবিষ্কার করা যাবে। নিম্নলিখিত সারণীতে এমন কিছু বৈশিষ্ট্যের বিবরণ দেওয়া হয়েছে যার উপর বিধিনিষেধ বা বিশেষ নিয়ম প্রয়োগ করা হয়েছে। যদি কোনও নিয়ম লঙ্ঘন করা হয়, তাহলে <permission> এলিমেন্টটি অক্ষম করা হবে এবং এর সাথে ইন্টারঅ্যাক্ট করা যাবে না। এর সাথে ইন্টারঅ্যাক্ট করার যেকোনো প্রচেষ্টার ফলে ব্যতিক্রম দেখা দেবে যা জাভাস্ক্রিপ্ট ব্যবহার করে ধরা পড়তে পারে। ত্রুটি বার্তায় সনাক্ত হওয়া লঙ্ঘনের বিষয়ে আরও বিশদ থাকবে।

নিম্নলিখিত CSS বৈশিষ্ট্যগুলি স্বাভাবিক হিসাবে ব্যবহার করা যেতে পারে:

• 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 বিশেষ স্টাইলিং করার অনুমতি দেয় যখন উপাদানটি একটি অবৈধ অবস্থায় থাকে, উদাহরণস্বরূপ, যখন এটি একটি ক্রস-অরিজিন আইফ্রেমে পরিবেশিত হয়।

permission {
  background-color: green;
}

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

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

জাভাস্ক্রিপ্ট ইভেন্ট

<permission> এলিমেন্টটি Permissions API এর সাথে একসাথে ব্যবহার করার জন্য তৈরি। বেশ কিছু ইভেন্ট শোনা যেতে পারে:

• onpromptdismiss : এই ইভেন্টটি তখনই কার্যকর হয় যখন উপাদানটির দ্বারা ট্রিগার করা অনুমতি প্রম্পট ব্যবহারকারী দ্বারা বাতিল করা হয় (উদাহরণস্বরূপ, বন্ধ বোতামে ক্লিক করে বা প্রম্পটের বাইরে ক্লিক করে)।

• onpromptaction : এই ইভেন্টটি তখনই কার্যকর হয় যখন ব্যবহারকারীর দ্বারা ট্রিগার করা অনুমতি প্রম্পটটি সমাধান হয়ে যায় যখন ব্যবহারকারী প্রম্পটে কিছু পদক্ষেপ নেয়। এর অর্থ এই নয় যে অনুমতির অবস্থা পরিবর্তিত হয়েছে, ব্যবহারকারী এমন কোনও পদক্ষেপ নিতে পারেন যা স্থিতাবস্থা বজায় রাখে (যেমন অনুমতি প্রদান অব্যাহত রাখা)।

• onvalidationstatuschange : যখন উপাদানটি "valid" থেকে "invalid" তে স্যুইচ করে তখন এই ইভেন্টটি কার্যকর হয়। ব্যবহারকারী যদি সিগন্যালটি ক্লিক করে তবে ব্রাউজার যখন সিগন্যালের অখণ্ডতার উপর বিশ্বাস করে তখন উপাদানটিকে "valid" বলে মনে করা হয়, এবং অন্যথায় "invalid" মনে করা হয়, উদাহরণস্বরূপ, যখন উপাদানটি অন্যান্য HTML কন্টেন্ট দ্বারা আংশিকভাবে আটকে থাকে।

আপনি এই ইভেন্টগুলির জন্য ইভেন্ট লিসেনারের নিবন্ধন সরাসরি HTML কোডে ( <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>

বৈশিষ্ট্য সনাক্তকরণ

যদি কোন ব্রাউজার কোন HTML এলিমেন্ট সাপোর্ট না করে, তাহলে এটি তা দেখাবে না। এর মানে হল, যদি আপনার HTML কোডে <permission> এলিমেন্ট থাকে, তাহলে ব্রাউজার যদি এটি না জানে তাহলে কিছুই হবে না। আপনি এখনও জাভাস্ক্রিপ্ট ব্যবহার করে সাপোর্ট সনাক্ত করতে চাইতে পারেন, উদাহরণস্বরূপ, একটি নিয়মিত <button> ক্লিকের মাধ্যমে ট্রিগার করা একটি অনুমতি প্রম্পট তৈরি করতে।

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

অরিজিন ট্রায়াল

আপনার সাইটে প্রকৃত ব্যবহারকারীদের সাথে <permission> উপাদানটি চেষ্টা করার জন্য, অরিজিন ট্রায়ালের জন্য সাইন আপ করুন । অরিজিন ট্রায়াল ব্যবহারের জন্য আপনার সাইটকে কীভাবে প্রস্তুত করবেন তার নির্দেশাবলীর জন্য "অরিজিন ট্রায়াল দিয়ে শুরু করুন" পড়ুন। অরিজিন ট্রায়ালটি Chrome 126 থেকে 131 (19 ফেব্রুয়ারী, 2025) পর্যন্ত চলবে।

ডেমো

ডেমোটি ঘুরে দেখুন এবং GitHub-এ সোর্স কোডটি দেখুন। এখানে একটি সাপোর্টিং ব্রাউজারে অভিজ্ঞতার একটি স্ক্রিনশট দেওয়া হল।

প্রতিক্রিয়া

We would love to hear from you how <permission> works for your use case. Feel free to respond to one of the Issues in the repository , or file a new one. Public signals in the repo for the <permission> element will let us and other browsers know you're interested in it.

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

• How is this better than a regular <button> paired with the Permissions API? A click of a <button> is a user gesture, but browsers have no way of verifying that it's connected to the request for asking for permission. If the user has clicked a <permission> , the browser can be sure that the click is related to a permission request. This allows the browser to facilitate flows that otherwise would be a lot more risky. For example, allowing the user to easily undo the blocking of a permission.
• What if other browsers don't support the <permission> element? The <permission> element can be used as a progressive enhancement. On non-supporting browsers, a classic permission flow can be used. For example, based on the click of a regular <button> . The permissions team are also working on a polyfill. Star the GitHub repo to be notified when it's ready.
• Was this discussed with other browser vendors? The <permission> element was actively discussed at W3C TPAC in 2023 in a breakout session . You can read the public session notes . The Chrome team has also asked for formal Standards Positions from both vendors, see the Related links section. The <permission> element is an ongoing topic of discussions with other browsers and we're hoping to standardize it.
• Should this actually be a void element? It's still being actively debated whether <permission> should be a void element or not. If you have feedback, chime in on the Issue.

সম্পর্কিত লিঙ্কগুলি

• ব্যাখ্যাকারী
• WebKit Standards Position
• Mozilla Standards Position

স্বীকৃতি

This document was reviewed by Balázs Engedy , Thomas Nguyen , Penelope McLachlan , Marian Harbach , David Warren , and Rachel Andrew .