גרסת מקור לניסיון של רכיב HTML חדש <permission>

Thomas Steiner

יש מספר שיטות חיוניות לבקשת הרשאה לשימוש בתכונות מתקדמות כמו גישה למיקום באפליקציות אינטרנט. השיטות האלה מגיעות עם מספר אתגרים, ולכן צוות ההרשאות של Chrome עורך ניסויים בשיטה חדשה הצהרתית: רכיב HTML ייעודי <permission>. האלמנט הזה נמצא בגרסת מקור לניסיון מגרסה Chrome 126, ובסופו של דבר אנחנו מקווים לתקנן אותו.

שיטות אימפרטיביות לבקשת הרשאה

כשאפליקציות אינטרנט צריכות גישה לתכונות מתקדמות, הן צריכות לבקש הרשאה. לדוגמה, כש-Google Maps דורש את מיקום המשתמש באמצעות Geolocation API, הדפדפנים יציגו למשתמש בקשה, ולרוב גם אפשרות לשמור את ההחלטה. זהו קונספט מוגדר היטב במפרט ההרשאות.

בקשה משתמעת בשימוש הראשון לעומת בקשה מפורשת מראש

‫Geolocation API הוא ממשק API עוצמתי שמסתמך על הגישה של בקשת הסכמה משתמעת בשימוש הראשון. לדוגמה, כשמפעילים את השיטה 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.

אם ההרשאה חיונית לחוויית המשתמש, למשל גישה למיקרופון באפליקציה לשיחות ועידה בווידאו, אפליקציות כמו Google Meet מציגות תיבות דו-שיח פולשניות עם הוראות למשתמש איך לבטל את החסימה של ההרשאה.

רכיב הצהרתי <permission>

כדי להתמודד עם האתגרים שמתוארים בפוסט הזה, צוות ההרשאות של Chrome השיק ניסוי מקור לרכיב HTML חדש, <permission>. האלמנט הזה מאפשר למפתחים לבקש באופן הצהרתי הרשאה להשתמש, בשלב הזה, בחלק מתכונות המתקדמות שזמינות לאתרים. בצורה הפשוטה ביותר, משתמשים בו כמו בדוגמה הבאה:

<permission type="camera" />

עדיין מתנהל דיון פעיל בשאלה אם <permission> צריך להיות רכיב ריק או לא. רכיב void הוא רכיב שנסגר בעצמו ב-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 עד 131 (19 בפברואר 2025).

הדגמה (דמו)

אפשר לעיין בהדמו ובקוד המקור ב-GitHub. הנה צילום מסך של החוויה בדפדפן נתמך.

משוב

נשמח לשמוע ממך איך <permission> עובד במקרה הספציפי שלך. אתם מוזמנים להגיב לאחת מהבעיות במאגר או לפתוח בעיה חדשה. אותות ציבוריים במאגר של רכיב <permission> מאפשרים לנו ולדפדפנים אחרים לדעת שאתם מתעניינים בו.

שאלות נפוצות

• איך זה טוב יותר מ<button> רגיל שמשולב עם Permissions API? לחיצה על <button> היא תנועת משתמש, אבל לדפדפנים אין דרך לוודא שהיא קשורה לבקשה להרשאה. אם המשתמש לחץ על <permission>, הדפדפן יכול להיות בטוח שהקליק קשור לבקשת הרשאה. כך הדפדפן יכול להקל על תהליכים שהיו מסוכנים הרבה יותר בלעדיו. לדוגמה, לאפשר למשתמש לבטל בקלות את החסימה של הרשאה.
• מה קורה אם דפדפנים אחרים לא תומכים ברכיב <permission>? אפשר להשתמש ברכיב <permission> כשיפור הדרגתי. בדפדפנים שלא תומכים ב-WebGPU, אפשר להשתמש בתהליך הרשאה קלאסי. לדוגמה, על סמך קליק על <button> רגיל. צוות ההרשאות עובד גם על polyfill. כדי לקבל התראה כשהוא יהיה מוכן, אפשר לסמן בכוכב את מאגר GitHub.
• האם הנושא הזה נדון עם ספקי דפדפנים אחרים? היה דיון פעיל על רכיב <permission> ב-W3C TPAC בשנת 2023 בסשן משני. אפשר לקרוא את הערות הפגישה שגלויות לכולם. צוות Chrome גם ביקש משני הספקים הצהרות רשמיות בנוגע לתקנים. אפשר לעיין בהן בקטע קישורים קשורים. האלמנט <permission> הוא נושא מתמשך לדיונים עם דפדפנים אחרים, ואנחנו מקווים ליצור לו תקן.
• האם זה באמת צריך להיות רכיב ריק? עדיין מתנהל דיון פעיל בשאלה אם <permission> צריך להיות רכיב ריק או לא. אם יש לכם משוב, אתם יכולים להוסיף אותו לבעיה.

קישורים רלוונטיים

• הסבר
• WebKit Standards Position
• העמדה של Mozilla בנוגע לתקנים

תודות

המסמך הזה נבדק על ידי Balázs Engedy, Thomas Nguyen, Penelope McLachlan, Marian Harbach, David Warren ועל ידי Rachel Andrew.