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

Thomas Steiner

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

الطرق الفعّالة لطلب الإذن

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

السؤال الضمني عند الاستخدام الأول بدلاً من الطلب الصريح

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

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

تحديات طلب الإذن بالأساليب الضرورية

الأذونات غير المرغوب فيها

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

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

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

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

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

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

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

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

عرض توضيحي

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

ملاحظات

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

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

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

روابط ذات صلة

• الشرح
• موضع معايير WebKit
• موضع معايير Mozilla

شكر وتقدير

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