<location> — Location Privacy-aware Content Tag (HTML 6 proposal)

Short summary (TL;DR)

Introduce a semantic, privacy-first element <location> that lets authors declare that content is about or tied to a place or to the authoring device’s location. The element is strictly declarative: it does not trigger background sensor access. Any device-derived coordinates require explicit runtime permission and must respect Permissions-Policy and user privacy settings.

1. Motivation & goals

• Semantic clarity. Make it explicit when content is about a place so UAs, accessibility tools and indexers can act accordingly.
• Privacy by default. Precise coordinates are only exposed with explicit user consent; defaults are coarse-grained.
• Interoperability. Provide a machine-readable wrapper that maps cleanly to Geolocation API, Permissions-Policy, and microdata/RDFa.

2. Design principles

1. Declarative, not imperative. The element is metadata; it must not obtain device location silently.
2. Least privilege. Default precision is coarse (city/region); authors may request higher precision but only with consent.
3. Policy aware. Integrate with Permissions-Policy and per-origin browser controls.
4. Accessible & indexable. Screen readers and crawlers should be able to expose or respect the element according to privacy signals.

3. Proposed element: syntax & semantics

Basic form:

<location
  method="explicit|inferred|declared"
  source="author|device|third-party"
  precision="city|region|country|exact"
  privacy="public|masked|private"
  lang="en"
>
  <place data-lat="59.9139" data-lon="10.7522">Oslo, Norway</place>
  <meta name="confidence" value="0.85">
  <time when="2025-09-27T12:00:00Z">created 2025-09-27</time>
</location>

Attribute semantics

method

How the location was obtained: explicit (user-entered/author-declared), inferred (IP/Wi‑Fi heuristics), or declared (author claim without machine coords).

source

author | device | third-party. device implies coordinates could be requested from the Geolocation API (subject to permissions).

precision

city | region | country | exact. Default: city.

privacy

Publisher signal: public (indexable), masked (obfuscate to centroid), or private (do not index). Browsers must honor user preferences over author signals.

Authors may still use microdata/RDFa, but <location> provides a compact, consistent wrapper for semantics and privacy-aware behavior.

4. Runtime / permission model (browser behavior)

1. No silent access. If source="device" or precision="exact" is requested, the UA must not automatically obtain coordinates. It must prompt for explicit permission and explain why.
2. Permissions-Policy integration. If the origin is disallowed, the UA must not prompt and should behave as if denied.
3. Privacy preferences override. Browser-level or user preferences (e.g., "never share precise location") override author requests.
4. Event hooks. When permission is granted, the UA may dispatch a cancellable locationready event on the element that scripts can listen to.

5. Use cases & examples

5.1 Author-specified place (no device access)

<location method="explicit" source="author" precision="city">
  <place>Reykjavík, Iceland</place>
</location>

5.2 Device-backed local content (user opt-in)

<location method="inferred" source="device" precision="exact" privacy="masked">
  <place>My current place</place>
</location>

<script>
document.querySelector('location[precision="exact"]').addEventListener('locationready', e => {
  // e.detail may contain coordinates or an obfuscated location
});
</script>

5.3 Privacy-first indexing

Search engines and crawlers may treat privacy="private" as a signal not to index location metadata, or may index only obfuscated, lower-precision values.

6. Privacy, security & accessibility considerations

• Explicit consent & transparent prompts; audit logs of consent where appropriate.
• Granular defaults: coarse precision unless user elevates permission.
• Respect existing privacy controls: Permissions-Policy, site settings, and browser toggles.
• Accessibility: ensure readable children and ARIA-friendly content and fallback text when location is masked.
• Security: treat location metadata as sensitive in cross-origin contexts; block third-party frames unless allowed.

7. Implementation notes for browsers

Browser duties include prompting UI, permission persistence, mapping precision to obfuscation strategies (e.g., regional centroids or randomized offsets), and enforcing policies. Consider exposing a small helper API mirroring Geolocation semantics (e.g., element.requestLocation()) that remains subject to the same checks.

8. Migration & compatibility

Sites using microformats, RDFa or ad-hoc attributes can progressively emit <location> as a semantic wrapper. Crawlers can map existing geotags to the new element without breaking behavior.

9. Potential objections & responses

“This leaks location.”

The element is privacy-oriented and does not relax consent requirements; instead it makes intent explicit and ensures the UA enforces permission and precision defaults.

“We already have geotags.”dt>

<location> is a first-class semantic element that unifies metadata and integrates with permissions and privacy controls, improving accessibility and indexing.

10. Draft spec excerpt (normative)

"The <location> element represents metadata about the place associated with the content of its host element. Authors must not use the element to circumvent user consent for location. Browsers must not obtain precise coordinates for <location> elements labeled source='device' and precision='exact' without explicit runtime permission following Geolocation API semantics and respecting Permissions-Policy settings."

11. Next steps

1. Open a GitHub/WHATWG editor-discussion with the normative excerpt.
2. Request feedback from privacy and accessibility groups (W3C TAG, WCAG, browser vendors).
3. Prototype UA behavior behind an experimental flag and provide CMS adapters.