<location> — Location Privacy-aware Content Tag (HTML 6 proposal) - https://www.aamotsoftware.com/location.html

[aamotsoftware]

— Location Privacy-aware Content Tag (HTML 6 proposal) A privacy-first, semantic HTML element for declaring that content is associated with a place, while ensuring explicit user consent, permissions-policy respect, and accessible, indexable metadata.

Short summary (TL;DR) Introduce a semantic, privacy-first element 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 Declarative, not imperative. The element is metadata; it must not obtain device location silently. Least privilege. Default precision is coarse (city/region); authors may request higher precision but only with consent. Policy aware. Integrate with Permissions-Policy and per-origin browser controls. 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"

Oslo, Norway created 2025-09-27 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 provides a compact, consistent wrapper for semantics and privacy-aware behavior.

4. Runtime / permission model (browser behavior) 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. Permissions-Policy integration. If the origin is disallowed, the UA must not prompt and should behave as if denied. Privacy preferences override. Browser-level or user preferences (e.g., "never share precise location") override author requests. 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) Reykjavík, Iceland 5.2 Device-backed local content (user opt-in) My current place

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 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> 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 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 elements labeled source='device' and precision='exact' without explicit runtime permission following Geolocation API semantics and respecting Permissions-Policy settings."

11. Next steps Open a GitHub/WHATWG editor-discussion with the normative excerpt. Request feedback from privacy and accessibility groups (W3C TAG, WCAG, browser vendors). Prototype UA behavior behind an experimental flag and provide CMS adapters. This document is a draft proposal. Use it as a starting point for editor's drafts and implementation experiments.