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

Thomas Steiner

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

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

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

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

إنّ Geolocation API هي واجهة برمجة تطبيقات فعّالة وتعتمد على أسلوب الطلب الضمني عند الاستخدام الأول. على سبيل المثال، عندما يستدعي تطبيق الطريقة navigator.geolocation.getCurrentPosition()، يظهر طلب الأذونات تلقائيًا عند الاستدعاء الأول. مثال آخر هو navigator.mediaDevices.getUserMedia().

تتضمّن واجهات برمجة التطبيقات الأخرى، مثل واجهة برمجة التطبيقات للإشعارات أو واجهة برمجة التطبيقات لاتجاه الجهاز وحركته، عادةً طريقة واضحة لطلب الإذن من خلال طريقة ثابتة مثل Notification.requestPermission() أو DeviceMotionEvent.requestPermission().

التحديات المرتبطة بالطرق الإلزامية لطلب الحصول على إذن

إساءة استخدام الأذونات

في السابق، كان بإمكان المواقع الإلكترونية استدعاء طرق مثل navigator.mediaDevices.getUserMedia() أو Notification.requestPermission()، بالإضافة إلى navigator.geolocation.getCurrentPosition() مباشرةً عند تحميل موقع إلكتروني. ستظهر رسالة طلب الإذن قبل أن يتفاعل المستخدم مع الموقع الإلكتروني. ويُشار إلى ذلك أحيانًا باسم "إساءة استخدام الأذونات"، ويؤثّر في كلتا الطريقتين، أي طلب الإذن ضمنيًا عند الاستخدام الأول وطلبه صراحةً مسبقًا.

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

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

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

تحديد سياق الأذونات

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

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

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

إذا كان الإذن أساسيًا لتجربة الاستخدام، مثل إذن الوصول إلى الميكروفون في تطبيق لعقد مؤتمرات الفيديو، فإنّ تطبيقات مثل 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" عندما يثق المتصفّح في سلامة الإشارة إذا نقر المستخدم عليها، و"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> على موقعك الإلكتروني مع مستخدمين حقيقيين، اشترِك في التجربة الأصلية. اطّلِع على بدء استخدام التجارب الأصلية للحصول على تعليمات حول كيفية إعداد موقعك الإلكتروني لاستخدام التجارب الأصلية. ستستمرّ التجربة الأصلية من الإصدار 126 إلى 131 من Chrome (19 فبراير 2025).

عرض توضيحي

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

الملاحظات

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

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

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

روابط ذات صلة

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

الإقرارات

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