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

Thomas Steiner

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

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

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

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

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

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

অন্যান্য API, যেমন 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() ওয়েবসাইট লোড হওয়ার সাথে সাথেই কল করতে পারত। ব্যবহারকারী ওয়েবসাইটের সাথে যোগাযোগ করার আগেই একটি অনুমতি প্রম্পট পপ আপ হত। এটিকে কখনও কখনও অনুমতি স্প্যাম হিসাবে বর্ণনা করা হয় এবং উভয় পদ্ধতিকেই প্রভাবিত করে, প্রথম ব্যবহারের সময় পরোক্ষভাবে জিজ্ঞাসা করার পাশাপাশি স্পষ্টভাবে আগে থেকে অনুরোধ করার জন্য।

ব্রাউজার প্রশমন এবং ব্যবহারকারীর অঙ্গভঙ্গির প্রয়োজনীয়তা

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

আরেকটি প্রশমন হল তাৎক্ষণিক অপব্যবহার প্রশমন যোগ করা, যেমন শুরুতেই বৈশিষ্ট্যগুলি সম্পূর্ণরূপে ব্লক করা, অথবা অনুমতি প্রম্পটটি অ-মোডাল, কম হস্তক্ষেপকারী উপায়ে দেখানো।

অনুমতির প্রাসঙ্গিকীকরণ

আরেকটি চ্যালেঞ্জ, বিশেষ করে বড় স্ক্রিনে, হল অনুমতি প্রম্পটটি সাধারণত যেভাবে প্রদর্শিত হয়: মৃত্যুর রেখার উপরে, অর্থাৎ, ব্রাউজার উইন্ডোর সেই এলাকার বাইরে যেখানে অ্যাপটি আঁকতে পারে। এটি অপ্রত্যাশিত নয় যে ব্যবহারকারীরা উইন্ডোর নীচের একটি বোতামে ক্লিক করলে তাদের ব্রাউজার উইন্ডোর উপরের প্রম্পটটি মিস করবেন। ব্রাউজার স্প্যাম প্রশমনের সময় এই সমস্যাটি প্রায়শই আরও বেড়ে যায়।

সহজে পূর্বাবস্থায় ফেরানো যায় না

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

যদি অনুমতিই অভিজ্ঞতার মূল চাবিকাঠি হয়, উদাহরণস্বরূপ, ভিডিও কনফারেন্সিং অ্যাপ্লিকেশনের জন্য মাইক্রোফোন অ্যাক্সেস, তাহলে Google Meet-এর মতো অ্যাপগুলি হস্তক্ষেপমূলক ডায়ালগ দেখায় যা ব্যবহারকারীকে অনুমতিটি কীভাবে আনব্লক করতে হয় তা নির্দেশ করে।

একটি ঘোষণামূলক <permission> উপাদান

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

<permission type="camera" />

দ্রষ্টব্য: পৃষ্ঠা এমবেডেড অনুমতি নিয়ন্ত্রণ (PEPC, উচ্চারণ "PEP-C") হল বৃহত্তর সামগ্রিক প্রোগ্রামের নাম যা কন্টেন্ট এলাকায় আরও নিয়ন্ত্রণ এম্বেড করে। এই কারণেই আপনি মাঝে মাঝে লোকেদের <permission> কে PEPC হিসাবে উল্লেখ করতে দেখতে পারেন।

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

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

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

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

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

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

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

দ্রষ্টব্য: অরিজিন ট্রায়ালের সময়, lang অ্যাট্রিবিউটটি সমর্থিত হবে না। পরিবর্তে, ব্রাউজারটি যে ভাষায় সেট করা আছে তা ব্যবহার করা হবে।

আচরণ

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

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

  

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

  

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

  

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

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

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

সম্পত্তি	নিয়ম
color , background-color	যথাক্রমে টেক্সট এবং ব্যাকগ্রাউন্ড কালার সেট করতে ব্যবহার করা যেতে পারে। স্পষ্টভাবে পাঠযোগ্য টেক্সটের জন্য দুটি রঙের মধ্যে বৈসাদৃশ্য যথেষ্ট হওয়া প্রয়োজন (কমপক্ষে ৩ এর বৈসাদৃশ্য অনুপাত)। আলফা চ্যানেলটি ১ হতে হবে।
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 অনুবাদ এবং আনুপাতিক আপ-স্কেলিং গ্রহণ করি।

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

দ্রষ্টব্য: অরিজিন ট্রায়ালের সময়, :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 : এই ইভেন্টটি তখনই কার্যকর হয় যখন উপাদানটির দ্বারা ট্রিগার করা অনুমতি প্রম্পট ব্যবহারকারী দ্বারা বাতিল করা হয় (উদাহরণস্বরূপ, বন্ধ বোতামে ক্লিক করে বা প্রম্পটের বাইরে ক্লিক করে)।

  দ্রষ্টব্য: অরিজিন ট্রায়ালের সময়, এটিকে ondismiss বলা হবে, তবে চূড়ান্ত নাম হবে onpromptdismiss । আপনি 'ondismiss' in HTMLPermissionElement.prototype ব্যবহার করে সমর্থিত ইভেন্টের নামটি বৈশিষ্ট্য-সনাক্ত করতে পারেন।

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

  দ্রষ্টব্য: অরিজিন ট্রায়ালের সময়, এটিকে onresolve বলা হবে, তবে চূড়ান্ত নাম হবে onpromptaction । আপনি 'onresolve' in HTMLPermissionElement.prototype ব্যবহার করে সমর্থিত ইভেন্টের নামটি বৈশিষ্ট্য-সনাক্ত করতে পারেন।

• 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> একটি অকার্যকর উপাদান হওয়া উচিত কিনা তা নিয়ে এখনও সক্রিয়ভাবে বিতর্ক চলছে। যদি আপনার কোন প্রতিক্রিয়া থাকে, তাহলে সমস্যাটি সম্পর্কে যোগাযোগ করুন।

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

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

স্বীকৃতি

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