הצגת אלמנט ה-HTML ‏ <geolocation>

Mari Viana

Minh Le

Thomas Steiner

פורסם: 13 בינואר 2026

החל מגרסה 144 של Chrome, אפשר להשתמש ברכיב ה-HTML החדש <geolocation>. האלמנט הזה מייצג שינוי משמעותי באופן שבו אתרים מבקשים נתוני מיקום של משתמשים – מעבר מהנחיות לבקשת הרשאה שמופעלות על ידי סקריפט לחוויה הצהרתית שמכוונת לפעולות של המשתמש. הוא מצמצם את קוד ה-boilerplate שנדרש לטיפול במצבי הרשאה ובשגיאות, ומספק אות חזק יותר של כוונת המשתמש, מה שעוזר להימנע מהתערבויות של הדפדפן (כמו חסימות שקטות).

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

מ-<permission> כללי ל-<geolocation> ספציפי

הרכיב <geolocation> הוא הגרסה האחרונה של היוזמה Page-Embedded Permission Control (בקרת הרשאות שמוטמעת בדף). בתחילה הוצע הרכיב הזה כרכיב <permission> כללי עם מאפיין type (ראו את ההסבר המקורי). הערך של מאפיין הסוג (לדוגמה, "geolocation") יקבע את סוג ההרשאה המבוקשת. לדוגמה, ההצעה הראשונית כוללת ערכים כמו מצלמה, מיקרופון ומיקום גיאוגרפי.

אימות הרעיון

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

התוצאות מגרסת המקור לניסיון הזו תמכו באימות של הרעיון המרכזי הזה:

• ב-Zoom דיווחו על ירידה של 46.9% בשגיאות בצילום מהמצלמה או מהמיקרופון (כמו חסימות ברמת המערכת) בעקבות השימוש ברכיב כדי להנחות את המשתמשים בתהליך השחזור.
• חברת Immobiliare.it נהנתה מעלייה של 20% במספר התהליכים המוצלחים של מיקום גיאוגרפי.
• ב-ZapImóveis נמדד שיעור הצלחה של 54.4% בקרב משתמשים שהצליחו לצאת ממצב של 'חסימה קודמת' אחרי שהוצג להם הרכיב.

הגדרה מחדש של העיצוב

הקונספט הוכיח את עצמו, אבל ההטמעה שלו דרשה שיפורים. משוב מספקי דפדפנים – כולל Apple (Safari/WebKit) ו-Mozilla (Firefox) – הצביע על כך שרכיב 'מתאים לכולם' יוצר מורכבות משמעותית בכל הנוגע להתנהגויות ייחודיות של יכולות.

לכן, עברנו משליטה כללית בהרשאות לרכיבים ממוקדים וספציפיים ליכולות (ראו דיון ב-WICG). <geolocation> האלמנט הוא הראשון מבין אמצעי הבקרה המיוחדים האלה שיושקו. בנוסף, אנחנו מפתחים רכיב ייעודי של <usermedia> (לגישה למצלמה ולמיקרופון), שיש לו ניסיון מקורי משלו.

בניגוד להצעה המקורית, שהתמקדה בניהול מצב ההרשאה (כלומר, אישור או דחייה), הרכיבים החדשים האלה פועלים כמתווכי נתונים, ובפועל מייתרים את הצורך לקרוא ישירות לממשקי ה-API של JavaScript ברוב תרחישי השימוש.

למה כדאי להשתמש ברכיב <geolocation>?

בשלב הזה, תהליכי העבודה של המיקום הגיאוגרפי מסתמכים על Geolocation API, שמפעיל הנחיות לבקשת הרשאה שיכולות להפריע למשתמשים אם הן מופעלות מחוץ להקשר או אפילו בזמן טעינת הדף. חשוב לדעת שההסתמכות על הנחיות חובה כאלה הופכת לפחות מעשית בגלל התערבויות של דפדפנים. לדוגמה, Chrome חוסם באופן פעיל בקשות להרשאות אם משתמש סגר את ההודעה שלוש פעמים, ומחיל חסימה זמנית שקטה שנמשכת שבוע בהתחלה. כלומר, קוד מדור קודם שמנסה להפעיל הנחיה עלול להיכשל בלי להציג הודעה, והמשתמש ייתקל בבעיה ולא יוכל להבין איך להפעיל את התכונה. בנוסף, בפרומפטים רגילים חסר לעיתים קרובות הקשר. אם מופיעה הנחיה באופן לא צפוי, יכול להיות שהמשתמשים יחסמו אותה באופן רפלקסיבי או בטעות, בלי להבין שההחלטה הזו יוצרת חסימה קבועה שקשה לבטל. פער ההקשר הזה – ולא התכונה עצמה – הוא הגורם העיקרי לשיעורי דחייה גבוהים.

רכיב <geolocation> פותר את הבעיה של פער בהקשר, כי הוא מוודא שהבקשות מופעלות על ידי המשתמש בלבד. למודל הזה יש שלושה יתרונות ברורים:

• כוונת שימוש ברורה ותזמון: בלחיצה על לחצן שימוש במיקום, המשתמש מציין באופן מפורש את הכוונה שלו להשתמש במיקום שלו באותו רגע ספציפי. האות הזה מצביע על כך שהמשתמשים מבינים את הערך של השיתוף ורוצים להשתמש במיקום באופן פעיל, וכך הופכים חסימה פוטנציאלית לאינטראקציה מוצלחת.
• שחזור פשוט: אם משתמש חסם בעבר את הגישה למיקום בזמן הגלישה באתר (אולי בטעות או בגלל חוסר הקשר), לחיצה על הרכיב תפעיל תהליך שחזור מיוחד. כך הם יכולים להפעיל מחדש את המיקום ברגע שהם באמת רוצים להשתמש במיקום, בלי הצורך לנווט להגדרות האתר בדפדפן.
• רענון אוטומטי: אם ההרשאה כבר ניתנה, לחיצה על הרכיב פועלת כמו לחצן רענון, ומביאה נתונים חדשים באופן מיידי בלי להציג שוב את הבקשה.

הטמעה

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

<geolocation
  onlocation="handleLocation(event)"
  autolocate
  accuracymode="precise">
</geolocation>

function handleLocation(event) {
  // Directly access the GeolocationPosition object on the element
  if (event.target.position) {
    const { latitude, longitude } = event.target.position.coords;
    console.log("Location retrieved:", latitude, longitude);
  } else if (event.target.error) {
    console.error("Error:", event.target.error.message);
  }
}

מאפיינים ותכונות מרכזיים

• ‫autolocate: המערכת תנסה לאחזר את המיקום באופן אוטומטי כשהרכיב ייטען, אבל רק אם סטטוס ההרשאה הנוכחי כבר מאפשר זאת (כדי למנוע הנחיות בלתי צפויות).
• ‫accuracymode: אפשר להזין בו את הערך "precise" או "approximate", שמתאים לאפשרות הרגילה enableHighAccuracy.
• ‫watch: ההתנהגות משתנה בהתאם לערך watchPosition(), והאירועים מופעלים ברציפות בזמן שהמשתמש נע.
• ‫position: מאפיין לקריאה בלבד ברכיב ה-DOM שמחזיר את אובייקט GeolocationPosition כשהוא זמין.
• ‫error: מאפיין לקריאה בלבד שמחזיר GeolocationPositionError אם הבקשה נכשלת.

הגבלות על סגנון

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

• קריאות: נבדקת הניגודיות בין צבע הטקסט לצבע הרקע (בדרך כלל יחס של 3:1 לפחות) כדי לוודא שבקשת ההרשאה תמיד קריאה. בנוסף, צריך להגדיר את ערוץ האלפא (אטימות) ל-1 כדי למנוע שקיפות מטעה של הרכיב.
• גודל ומרווח: האלמנט מגדיר גבולות מינימליים ומקסימליים לרוחב, לגובה ולגודל הגופן. השבתנו שוליים שליליים או היסטים של קווי מתאר כדי למנוע הסתרה ויזואלית של הרכיב או חפיפה מטעה עם תוכן אחר.
• שלמות ויזואלית: האפקטים של עיוות מוגבלים – לדוגמה, הפונקציה transform תומכת רק בתרגומים דו-ממדיים ובשינוי גודל יחסי.
• פסאודו-מחלקות CSS: הרכיב תומך בסגנון מבוסס-מצב, כמו ‎:granted (כשההרשאה פעילה).

אסטרטגיית שיפור הדרגתית

אנחנו מבינים שתהליך התקנון של רכיבי HTML חדשים הוא הדרגתי. עם זאת, מפתחים יכולים להשתמש ברכיב <geolocation> כבר היום בלי לפגוע בתאימות למשתמשים בדפדפנים אחרים.

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

תבנית חלופית בהתאמה אישית

אם אתם רוצים לשלוט באופן מלא בחוויית הגיבוי, אתם יכולים להשתמש ברכיבי צאצא כמו לחצן שאתם מקשרים ל-API הרגיל של JavaScript למיקום גיאוגרפי.

<geolocation onlocation="updateMap()">
  <!-- Fallback contents if the element is not supported -->
  <button onclick="navigator.geolocation.getCurrentPosition(updateMap)">
    Use my location
  </button>
</geolocation>

דוגמה בסיסית לאופן הפעולה של ההתנהגות

פוליפיל

אפשר גם להתקין polyfill מ-npm שמחליף באופן שקוף ואוטומטי את כל המופעים של <geolocation> ברכיב מותאם אישית <geo-location> (שימו לב למקף) שמגובה על ידי API רגיל של JavaScript למיקום גיאוגרפי. אם הדפדפן תומך ברכיב <geolocation>, ה-polyfill פשוט לא עושה כלום. כדאי לעיין בהדגמה של polyfill כדי לראות את ה-polyfill בפעולה. קוד המקור נמצא ב-GitHub.

if (!('HTMLGeolocationElement' in window)) {
  await import('https://unpkg.com/geolocation-element-polyfill/index.js');
}

<geolocation onlocation="updateMap()"></geolocation>

זיהוי תכונות

ללוגיקה מורכבת יותר, אפשר לזהות תמיכה באופן פרוגרמטי באמצעות הממשק:

if ('HTMLGeolocationElement' in window) {
  // Use modern <geolocation> element logic
} else {
  // Fallback to legacy navigator.geolocation API
}

סיכום

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

לתרחישי שימוש אחרים בהרשאות, החל מ-Chrome 144 אפשר להצטרף לגרסת המקור לניסיון של רכיב ה-HTML‏ <usermedia>, וליהנות מאותם יתרונות של נוחות השימוש במצלמה ובמיקרופון.

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

• האלמנט <geolocation> בסטטוס הפלטפורמה של Chrome
• הסבר על רכיב HTML של מיקום גיאוגרפי
• דף הדגמה
• העמדה של Mozilla בנוגע לתקנים
• WebKit Standards Position

תודות

המסמך הזה נבדק על ידי אנדי פאיקו, גילברטו קוקי ורייצ'ל אנדרו.