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

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

• מסביר/מסבירה
• WebKit Standards Position
• Mozilla Standards Position

תודות

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