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

Thomas Steiner

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

השיטות החיוניות לבקשת הרשאה

מתי אפליקציות אינטרנט צריכות גישה אל תכונות עוצמתיות, צריך לבקש הרשאה. לדוגמה, כאשר השימוש במפות Google מחייב את מיקום המשתמש באמצעות 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> צריך להיות בטל או לא. רכיב ריק הוא רכיב הסגירה העצמי ב-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, הוא לא יוצג. המשמעות היא אם יש בקוד ה-HTML את הרכיב <permission>, לא יקרה כלום הדפדפן לא יודע על זה. יכול להיות שעדיין תרצו לזהות תמיכה באמצעות JavaScript, לדוגמה, כדי ליצור בקשת הרשאה שמופעלת אחרי לחיצה <button> רגיל.

if ('HTMLPermissionElement' in window) {
  // The `<permission>` element is supported.
}

גרסת מקור לניסיון

כדי לנסות את הרכיב <permission> באתר עם משתמשים אמיתיים, נרשמים לגרסת המקור לניסיון. כדאי לקרוא את המאמר איך מתחילים לעבוד עם גרסאות מקור לניסיון עבור הוראות להכנת האתר לשימוש בגרסאות מקור לניסיון. גרסת המקור לניסיון יפעל מ-Chrome בגרסה 126 עד 131 (19 בפברואר 2025).

הדגמה (דמו)

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

משוב

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

שאלות נפוצות

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

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

• הסברים
• המיקום של WebKit Standards
• מיקום הסטנדרטים של Mozilla

אישורים

המסמך נבדק על ידי Balázs Engedy, תומס נגויין, פנלופ מקלכלן, מריאן הארבך, דייוויד וורן, וגם רייצ'ל אנדרו.