مرحلة التجربة والتقييم لعنصر <permission> HTML جديد

Thomas Steiner

هناك عدد من الطرق الحاسمة لطلب الحصول على إذن لاستخدام ميزات فعّالة، مثل الوصول إلى الموقع الجغرافي في تطبيقات الويب. تواجه هذه الطرق عددًا من التحديات، ولهذا السبب، يجرّب فريق أذونات Chrome طريقة بيانية جديدة: عنصر <permission> مخصّص لـ HTML. يتوفّر هذا العنصر في مرحلة التجربة من الإصدار 126 من Chrome، ونأمل أن يتم استخدامه بشكل موحّد في النهاية.

الطرق الإلزامية لطلب الإذن

عندما تحتاج تطبيقات الويب إلى الوصول إلى ميزات فعّالة، يجب أن تسأل عن الإذن. على سبيل المثال، عندما تتطلّب خرائط Google الوصول إلى الموقع الجغرافي للمستخدم من خلال واجهة برمجة التطبيقات Geolocation API، ستطلب المتصفحات ذلك غالبًا، وسيتوفّر لها غالبًا خيار تخزين هذا القرار. وهذا هو مفهوم محدّد جيدًا في مواصفات الأذونات.

طلب الإذن بشكل ضمني عند أول استخدام مقابل طلب الإذن بشكل صريح مسبقًا

واجهة برمجة التطبيقات 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() مباشرةً عند loading الموقع الإلكتروني. ستظهر رسالة طلب الإذن قبل أن يتفاعل المستخدم مع الموقع الإلكتروني. ويُشار أحيانًا إلى ذلك باسم "الرسائل غير المرغوب فيها بشأن الأذونات"، ويؤثر في كلا النهجين، إذ يطلب التطبيق الإذن بشكل ضمني عند الاستخدام الأول، كما يطلب الإذن صراحةً في البداية.

إجراءات التخفيف في المتصفّح ومتطلبات إيماءات المستخدم

أدّى المحتوى غير المرغوب فيه من طلبات الأذونات إلى أن يطلب مورّدو المتصفّحات من المستخدمين إجراء إيماءة، مثل النقر على زر أو حدث keydown، قبل عرض طلب الحصول على الإذن. تكمن المشكلة في هذا النهج في أنّه من الصعب جدًا، إن لم يكن مستحيلاً، على المتصفّح معرفة ما إذا كانت إيماءة معيّنة للمستخدم تؤدي إلى عرض طلب إذن أم لا. ربما كان المستخدم ينقر على الصفحة في أي مكان بسبب انزعاجه من بطء تحميل الصفحة، أو ربما كان يقصد النقر على الزر تحديد موقعي. أصبحت بعض المواقع الإلكترونية أيضًا جيدة جدًا في خداع المستخدمين من خلال جعلهم ينقرون على المحتوى لعرض الطلب.

ومن الإجراءات الوقائية الأخرى إضافة إجراءات وقائية لمنع إساءة استخدام طلبات الأذونات، مثل حظر الميزات بالكامل في البداية أو عرض طلب الأذونات بطريقة غير مشروطة وأقل انزعاجًا.

توفير سياق الأذونات

يتمثل التحدي الآخر، خاصةً على الشاشات الكبيرة، في الطريقة التي يتم بها عرض طلب الإذن بشكل شائع: فوق خط الموت، أي خارج منطقة نافذة المتصفح التي يمكن للتطبيق الرسم عليها. لم يسمع عن ذلك أن المستخدمين سيفوتهم المطالبة في أعلى نافذة المتصفح عندما ينقرون فقط على زر في الجزء السفلي من النافذة. وغالبًا ما تتفاقم هذه المشكلة عند تطبيق إجراءات الحد من المحتوى غير المرغوب فيه في المتصفّح.

لا يمكن التراجع بسهولة

أخيرًا، من السهل جدًا على المستخدمين الوصول إلى طريق مسدود. على سبيل المثال، بعد أن يحظر المستخدم الوصول إلى ميزة معيّنة، يجب أن يكون على دراية بالنافذة المنسدلة لمعلومات الموقع الإلكتروني التي يمكنه من خلالها إعادة ضبط الأذونات أو إعادة تفعيل الأذونات المحظورة. في أسوأ حالتَين، يتطلّب كلا الخيارَين إعادة تحميل الصفحة بالكامل إلى أن يتم تطبيق الإعداد المعدَّل. لا يمكن للمواقع الإلكترونية توفير اختصار سهل للمستخدمين لتغيير حالة الإذن الحالي، ويجب أن تشرح للمستخدمين بجدية كيفية تغيير إعداداتهم كما هو موضّح في أسفل لقطة الشاشة التالية في "خرائط Google".

إذا كان الإذن أساسيًا للتجربة، على سبيل المثال، إذن الوصول إلى الميكروفون لتطبيق اجتماعات الفيديو، تعرض تطبيقات مثل Google Meet مربّعات حوار مزعجة ترشد المستخدم إلى كيفية إزالة حظر الإذن.

عنصر <permission> تعريفي

لحلّ التحديات الموضّحة في هذه المشاركة، بدأ فريق أذونات Chrome تجربة عنصر HTML جديد، وهو <permission>. يتيح هذا العنصر للمطوّرين أن يطلبوا بشكل صريح الإذن لاستخدام مجموعة فرعية من الميزات الفعّالة المتاحة للمواقع الإلكترونية في الوقت الحالي. في أبسط صوره، يمكنك استخدامه كما في المثال التالي:

<permission type="camera" />

لا يزال الجدل قائمًا حول ما إذا كان يجب أن يكون <permission> عنصرًا فارغًا أم لا. العنصر اللاغي هو عنصر يغلق ذاتيًا في HTML ولا يمكن أن يحتوي على أي عُقد فرعية، ما يعني أنّه قد لا يحتوي في HTML على علامة نهاية.

السمة type

تحتوي السمة type على قائمة بالأذونات التي تطلبها مفصولة بمسافات. في وقت كتابة هذا التقرير، القيم المسموح بها هي 'camera' و'microphone' وcamera microphone (مفصولة بمسافة). يتم عرض هذا العنصر تلقائيًا بطريقة مشابهة للأزرار مع تصميم وكيل المستخدم الأساسي.

سمة type-ext

في بعض الأذونات التي تسمح بإدخال مَعلمات إضافية، تقبل السمة type-ext أزواج المفتاح/القيمة المفصولة بمسافات، مثل precise:true لإذن رصد الموقع الجغرافي.

سمة lang

يقدّم المتصفّح نص الزر الذي من المفترض أن يكون متسقًا، لذلك لا يمكن تخصيصه مباشرةً. يغيّر المتصفّح لغة النص استنادًا إلى اللغة المُكتسَبة للمستند أو سلسلة العناصر الرئيسية، أو سمة اختيارية lang. وهذا يعني أنّ المطوّرين لا يحتاجون إلى ترجمة عنصر <permission> بأنفسهم. إذا تجاوز عنصر <permission> مرحلة الإصدار التمهيدي ، قد يكون من الممكن استخدام عدة سلاسل أو رموز لكل نوع من أنواع الأذونات لزيادة المرونة. إذا كنت مهتمًا باستخدام العنصر <permission> وكنت بحاجة إلى سلسلة أو رمز معيّن، يُرجى التواصل معنا.

السلوك

عندما يتفاعل المستخدم مع العنصر <permission>، يمكنه التبديل بين مراحل مختلفة:

• وإذا لم يسمحوا بإحدى الميزات من قبل، يمكنهم السماح بها في كل زيارة أو السماح بها للزيارة الحالية.

  

• وإذا سمحوا بهذه الميزة من قبل، يمكنهم مواصلة السماح بها أو التوقّف عن السماح بها.

  

• إذا سبق أن حظروا ميزة، يمكنهم مواصلة حظرها أو السماح بها هذه المرة.

  

يتم تعديل نص العنصر <permission> تلقائيًا استنادًا إلى الحالة. على سبيل المثال، إذا تم منح الإذن لاستخدام ميزة، سيتغير النص للإشارة إلى أنّ الميزة مسموح بها. إذا كان من الضروري منح الإذن أولاً، يتغيّر النص لدعوة المستخدم إلى استخدام الميزة. قارن لقطة الشاشة السابقة بلقطة الشاشة التالية لمعرفة الحالتين.

تصميم CSS

لضمان قدرة المستخدمين على التعرّف بسهولة على الزرّ كسطح للحصول على الإمكانات الفعالة، يتم فرض قيود على نمط عنصر <permission>. إذا لم تكن قيود التصميم مناسبة لحالة الاستخدام الخاصة بك، يسرّنا معرفة السبب. على الرغم من أنّه لا يمكن تلبية جميع احتياجات التصميم، نأمل أن تتمكّن من اكتشاف طرق آمنة للسماح بمزيد من التصميمات لعنصر <permission> بعد انتهاء فترة التجربة. يوضّح الجدول التالي تفاصيل بعض المواقع التي تم فرض قيود عليها أو قواعد خاصة. في حال انتهاك أيّ من القواعد، سيتم إيقاف عنصر <permission> ولن يكون بالإمكان التفاعل معه. وستؤدي أي محاولات للتفاعل معه إلى حدوث استثناءات يمكن رصدها باستخدام لغة JavaScript. ستتضمّن رسالة الخطأ المزيد من التفاصيل حول الانتهاك الذي تم رصده.

يمكن استخدام خصائص 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 بتطبيق تصميم خاص عندما يكون العنصر في حالة غير صالحة، على سبيل المثال، عند عرضه في إطار 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" عندما يثق ال browser في سلامة الإشارة إذا نقر عليها المستخدم، و"invalid" في الحالات الأخرى، على سبيل المثال، عندما يكون العنصر مُحجبًا جزئيًا بمحتوى HTML آخر.

يمكنك تسجيل مستمعي الأحداث لهذه الأحداث مباشرةً في رمز HTML (<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />)، أو باستخدام addEventListener() في العنصر <permission>، كما هو موضّح في المثال التالي.

<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، لن يتم عرضه. وهذا يعني أنّه إذا كان لديك عنصر <permission> في رمز HTML، لن يحدث شيء إذا كان المتصفّح لا يعرفه. قد تحتاج أيضًا إلى رصد التوافق مع JavaScript، مثل إنشاء طلب للحصول على إذن يتم تشغيله من خلال النقر على <button> عادي.

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

مرحلة التجربة والتقييم

لتجربة عنصر <permission> على موقعك الإلكتروني مع مستخدمين حقيقيين، يمكنك الاشتراك في مرحلة التجربة والتقييم. اطّلِع على مقالة البدء باستخدام تجارب المصدر للحصول على تعليمات حول كيفية إعداد موقعك الإلكتروني لاستخدام تجارب المصدر. ستتم مرحلة تجربة وتقييم Topics من الإصدار 126 من Chrome إلى الإصدار 131 (19 شباط/فبراير 2025).

عرض توضيحي

يمكنك الاطّلاع على العرض التوضيحي ومراجعة رمز المصدر على GitHub. إليك لقطة شاشة للتجربة على متصفّح داعم.

ملاحظات

يسرّنا معرفة رأيك في مدى ملاءمة <permission> لحالة الاستخدام. يمكنك الردّ على أحد المشاكل في المستودع، أو تقديم شكوى جديدة. ستسمح لنا الإشارات العلنية في المستودع للعنصر <permission> بإعلامنا والمتصفّحات الأخرى بأنّك مهتم به.

الأسئلة الشائعة

• كيف يكون ذلك أفضل من جهاز <button> عادي مقترن مع Permissions API؟ النقر على <button> هو إيماءة مستخدِم، ولكن لا يمكن للمتصفّحات التحقّق من أنّ الاتصال بطلب الحصول على إذن. إذا نقر العميل على <permission>، يمكن للمتصفّح التأكّد من أنّ النقرة مرتبطة بطلب إذن. ويسمح ذلك للمتصفّح بتسهيل عمليات المعالجة التي قد تكون محفوفة بالمخاطر في حال عدم توفّر هذه الميزة. على سبيل المثال، السماح للمستخدم بالتراجع بسهولة عن حظر أحد الأذونات
• ماذا لو كانت المتصفّحات الأخرى لا تتيح استخدام العنصر <permission>؟ يمكن استخدام العنصر <permission> كتحسين تدريجي. في المتصفّحات التي لا تتيح استخدام هذه الميزة، يمكن استخدام مسار الإذن الكلاسيكي. على سبيل المثال، استنادًا إلى النقرة على <button> عادي. يعمل فريق الأذونات أيضًا على تطوير polyfill. أضِف علامة "تمييز كأحد المفضّلين" إلى مستودع GitHub لتلقّي إشعار عندما يصبح جاهزًا.
• هل تمت مناقشة هذا الأمر مع مورّدي المتصفّحات الآخرين؟ تم مناقشة عنصر <permission> بنشاط في W3C TPAC في عام 2023 في جلسة مصغّرة. يمكنك قراءة ملاحظات الجلسة العامة. طلب فريق Chrome أيضًا مواضع معايير رسمية من كلا المورِّدين، راجع قسم الروابط ذات الصلة. يُعدّ العنصر <permission> موضوعًا مستمرًا للمناقشات مع المتصفّحات الأخرى، ونأمل أن نجعله موحّدًا.
• هل يجب أن يكون هذا العنصر لاغيًا؟ لا يزال هناك مناقشة نشطة بشأن ما إذا كان يجب أن يكون <permission> عنصرًا فارغًا أم لا. إذا كانت لديك ملاحظات، يمكنك مشاركتها في قسم "المشكلة".

روابط ذات صلة

• الشرح
• موضع معايير WebKit
• موقف Mozilla بشأن المعايير

الشكر والتقدير

تمت مراجعة هذا المستند من قِبل بالازس إنجيدي، توماس نجوين، بينيلوبي ماكلاشان، ماريان هارباخ، ديفيد وارين، راشيل أندرو.