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

Thomas Steiner

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

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

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

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

Geolocation API הוא ממשק API חזק שמבוסס על הגישה של בקשה משתמעת בשימוש הראשון. לדוגמה, כשאפליקציה קוראת ל-method‏ navigator.geolocation.getCurrentPosition(), תיפתח בקשה להרשאות באופן אוטומטי בקריאה הראשונה. דוגמה נוספת היא navigator.mediaDevices.getUserMedia().

בממשקי API אחרים, כמו 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 אחר.

אפשר לרשום פונקציות event listener לאירועים האלה ישירות בתוך קוד ה-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
• עמדת Mozilla בנושא תקנים

תודות

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