Background

On the current Web, extremely diverse "map-like" resources exist, ranging from traditional GIS maps to hand-drawn illustrations. These resources vary greatly in structure, coordinate systems, representation methods, and interaction models; as a result, no unified "map" concept exists for the Web as a whole.

Representative examples include:

• Static images with geographical context (e.g., scanned maps, tourist information maps).
• Alignable raster images (e.g., aerial photographs, old maps).
• SVGs or drawings with unique coordinate spaces.
• Various Web map frameworks (Leaflet, MapLibre GL JS, Google Maps API, CesiumJS—where even 3D maps are projected to 2D at the rendering stage on the screen).
• MapML (a proposal within the Maps for HTML CG). [[MapML]]
• HLA (Hyper-Layering Architecture) and its implementation (svgmap.js). [[HLA]] [[HLA-SVGT]]
• Any map-like representation on the Web, including "hand-drawn maps".

It is clear that all of these share a commonality: they are "graphics" that provide the author and user with "some kind of understanding regarding positions in the real world".

Current Problems

However, there is no "minimal common model" on the Web for handling these different types of map-like resources in an interoperable manner. As a result:

• There is no standard way to link arbitrary HTML elements to geographic coordinates.
• Each map framework implements its own coordinate transformation and projection model, leading to a lack of compatibility.
• Hand-drawn or non-GIS maps are often not treated as "maps" at all.
• External Web content cannot be consistently placed within the coordinate space internal to a map framework.
• It may be impossible to coordinate with existing Web APIs, such as the Geolocation API.

This "fragmentation of the map across the Web" is caused by the very diversity of map technology itself and is not a defect of any specific technology. However, as the Web becomes a critical infrastructure for distributing geographic information, this fragmentation has become a major challenge.

Considering a Minimal "Web Map" Concept

This proposal does not attempt to strictly define "what a map is". Rather, it clarifies the minimal commonality required to establish compatibility.

From observation, any map-like resource shares the following common point: For content or parts of content recognized as a map, there is "some kind of relationship" between its internal coordinates (image coordinates, SVG coordinates, canvas coordinates, etc.) and real-world coordinates (latitude, longitude, etc.).

This relationship can be diverse:

• A mathematical projection function.
• An officially registered projection.
• A simple linear transformation.
• A projection that changes dynamically through user operations of zoom or viewport.
• Or a rough alignment without a numerical model.

The important point is that this relationship does not need to be defined in a unique way, and whether it is high-precision also depends on the case of the map.

In other words, the "minimal semantics" handled by this document is simply: Expressing the correspondence of "Internal Coordinates (coordinates of elements or regions corresponding to a map on Web content) ⇔ Real-world Coordinates" in a form that can be shared on the Web.

Basic Policy for Standardization

Considering the diversity of map usage on today's Web, standardizing a comprehensive map model or layer model is neither realistic nor desirable. The purpose of this document draft is narrowed down strictly to the following single point:

Define a minimal mechanism as a Web standard that allows any map-like resource to declare the relationship of "Internal Coordinates ↔ Real-world Coordinates".

This will allow:

• Web content to place arbitrary elements using latitude and longitude.
• The internal space of existing frameworks to be integrated with external HTML content.
• "Non-GIS content," such as hand-drawn maps or old maps, to function as maps.
• Coordination with existing Web APIs like the Geolocation API.
• Loose coordination, integration, and compatibility between existing map frameworks and services without replacing them.

This approach aligns with the fundamental Web principles of "decentralization," "progressive enhancement," "backward compatibility," and "loose coupling".

Summary

This chapter reorganized the concept of a "map" on the Web and clarified the "minimal commonality" that can be extracted from its diversity.

Additionally, the following policies were clarified:

• Maps in Web browsers can remain diverse.
• There is no need to unify projection methods.

Only one thing is needed:

A minimal mechanism that browsers can understand, showing "how an arbitrary Web resource corresponds to the real world".

Once this foundation is in place, it will be possible to build a "Web-native geographic infrastructure" where existing map frameworks, MapML, HLA, and even hand-drawn maps can interoperate.

Definition of a "Map" in Web User Agents

In this model, a Map is defined as a two-dimensional graphic representation visually displayed as a map on a Web User Agent.

A Map must satisfy the following conditions:

• Visual Graphic Content: It must be rendered content such as images, SVG, Canvas, or a combination of these two-dimensional representations. Pure data sequences like GeoJSON [[GEOJSON]] [[rfc7946]] or table data are not considered a "Map".
• User Recognition: The content must be in a state where it is actually rendered on the browser and can be recognized by the user as a map.
• Geographic Positioning: Earthly positions must be specified as coordinates based on a geodetic datum.
• WGS84 Compliance: The datum is defined using WGS84 [[WGS84]] . This aligns with the WGS84-fixity adopted by the Geolocation API [[geolocation]] and GeoJSON [[GEOJSON]] [[rfc7946]] to ensure consistency and interoperability. (Note: Locations other than Earth are currently out of scope.)
• Coordinate Mapping: Each display element maintains a relationship between the CSS coordinate system and the geographic coordinate system. This relationship can be expressed through transformation parameters or functions.
• Minimal Semantics: The definition is strictly limited to the correspondence between the 2D representation and geographic information. It does not include details of rendering methods, pan/zoom interactions, or specific projections.

Supplementary Note: This definition includes hand-drawn maps, sketch maps, SVG-based graphics, and Canvas drawings, provided they are visualized as graphics in a browsing context. "Data-only geographic information" is outside the scope of a Map. While 3D maps may require separate consideration, the same logic applies to 3D models projected onto a 2D canvas.

Components of a Map

Map Container

The 2D area rendered on the browser (e.g., <div>, <canvas>, <img>, <svg>, <iframe>). It holds a Coordinate Transformation Strategy to map internal units between WGS84 [[WGS84]] and CSS coordinates.

Rendering Unit

Individual elements placed within the Map (e.g., icons, markers, SVG paths, images, WebGL instances). They are placed in CSS coordinates and correspond to WGS84 [[WGS84]] positions according to the strategy. They maintain compatibility with the Geolocation API and GeoJSON [[GEOJSON]].

Geo-reference (Geographic Coordinates)

Represents the position on Earth (Datum) indicated by each unit. It uses WGS84 [[WGS84]] to align with Web standards.

Coordinate Transformation Strategy

Transformation parameters (e.g., LUT, matrix) or functions (e.g., JS Worklet) associated with the Map Container. It expresses the relationship between CSS and WGS84 [[WGS84]] coordinates. This approach is GPU-friendly, secure, and applicable to complex projections or sketch maps.

Interoperability: Units following this model are compatible with various map representations and standard coordinate information like the Geolocation API.

Principles of Minimal Extension

This document follows these principles to design a minimal common foundation:

• Minimization of Dynamic Functions: Dynamic features such as pan, zoom, tiling, and animations are not included in the core. These are subjects for independent, progressive consideration or can be extended via JavaScript Worklets.
• Abstraction of Projections and Coordinate Systems: Mathematical projections and CRS specifications are not internal UA functions in the minimal model. Instead, the relationship is expressed through parametric transformations (including LUTs) or functions, applicable to any projection or sketch map.
• Ensuring Safety: Coordinate transformations are executed safely via GPU-friendly LUTs or worklet processing, relying on standard Web security measures like CORS.
• Emphasis on Interoperability: Components are designed to be usable across MapML, Leaflet, MapLibre, Google Maps, CesiumJS, HLA, and hand-drawn maps based on the same conceptual foundation.
• Limitation to Minimal Semantics: This model defines only the correspondence between internal coordinates and geographic coordinates (WGS84 [[WGS84]] ). By excluding rendering details and interaction behaviors, it provides a consistent foundation for diverse map expressions.

Deep Dive into Coordinate Transformation Strategies (with Samples)

In this document, CSS properties such as geo-conversion-worklet, geo-conversion-parameter, and geo-location, as well as their associated syntax (e.g., matrix(...), lut(...), [longitude, latitude, CSS-X, CSS-Y]), are currently presented as conceptual placeholders to explain the technical approach.

While these notations take into account future compatibility with modules like CSS Values and Units or CSS Houdini, they have not been detailed as a formal specification. The primary focus of this model lies in the minimal semantics behind these notations and the strategies for secure, high-performance implementation. The determination of specific syntax should occur during the work phase of the CSS Working Group after an agreement is reached on the foundational standardizing policy of this Minimal Model.

These strategies are presented as alternatives rather than a hierarchy.

.dynamic-map-container {
  position: relative;
  /* Referencing a coordinate transformation function defined as an external Worklet */
  geo-conversion-worklet: url('my-complex-projection-v2.js');
}

.marker-poi {
  position: absolute;
  geo-location: 35.6586deg 139.7454deg;
}
    

<div class="map-container dynamic-map-container">
  <div class="marker-poi">📍</div>
</div>
    

class transform {
  constructor(){}
  transform(longitude, latitude) {
    // ... complex projection logic ...
    return {x, y};
  }
  inverse(x, y) {
    // ... inverse projection logic ...
    return {longitude, latitude};
  }
}
export {transform};
    

.affine-map-container {
  position: relative;
  /* Coordinate transformation using existing CSS matrix(a,b,c,d,e,f) syntax */
  geo-conversion-parameter: matrix(
    0.0001,   /* a */
    -0.00005, /* b */
    0.00003,  /* c */
    0.00012,  /* d */
    -1000,    /* e (Translate X) */
    25000     /* f (Translate Y) */
  );
}
  

<div class="map-container affine-map-container">
  <div class="marker-poi" style="geo-location: 35.682 139.764">📍</div>
</div>
  

.inline-sketch-map {
  position: relative;
  geo-conversion-parameter: lut(
    [139.764, 35.682,  50, 100],
    [139.767, 35.680,  350, 450],
    /* ... additional points ... */
    [lngN, latN, XcssN, YcssN]
  );
}
  

<div class="map-container inline-sketch-map">
  <div class="marker-poi" style="geo-location: 35.681 139.765">📍</div>
</div>
  

.large-gis-map {
  position: relative;
  geo-conversion-parameter: url('city-center-64x64-lut.json');
}
  

<div class="map-container large-gis-map">
  <div class="marker-poi" style="geo-location: 35.6895 139.6917">📍</div>
</div>
  

Viewport and Clipping Model (clipBox)

This document clearly separates the map's "display area" from its "content (world)". This redefines the relationship between the SVG viewport and viewBox within the context of the HTML/CSS box model.

• clipBox (Viewport): Acts as the "window" for observing the map. Its role is to clip the vast map content behind it using overflow: hidden.
• map-container (World): The element that holds the actual map content and graphics. The association with geographic coordinates (geo-conversion-*) is applied to this element.

Through this separation, map panning (movement) and zooming (scaling) are performed via the left/top or transform properties of the map-container element, while the clipBox remains a static window. This model translates the SVG viewBox concept into HTML/CSS by keeping the "window" fixed and moving the "world" behind it.

<div class="clipBox">
  <div class="map-container">
    <!-- Map content and markers go here -->
  </div>
</div>
  

/* The clipBox serves strictly as a static "window" */
.clipBox {
  width: 500px;
  height: 400px;
  overflow: hidden;  /* This defines the clipping */
  position: relative;
  border: 1px solid #ccc;
}

/* The map-container represents the "world" and handles movement/scaling */
.map-container {
  position: absolute;
  width: 3000px;    /* A vast map plane */
  height: 2000px;

  /* Panning is expressed via left/top or transform */
  left: -600px;
  top: -400px;

  /* Geographic binding */
  geo-conversion-parameter: url('tokyo-lut.json');
}
  

Definition of Element-local Coordinate Space

The "CSS coordinates" referenced by the geo-conversion-* properties point to the element-local coordinate space, defined by the following rules:

• Origin: The top-left corner of the map-container element's padding box is defined as (0, 0).
• Range: The plane is determined by the used width and used height.
• Invariance: This coordinate space is entirely unaffected by the element’s own left/top positioning, visual deformation via transform, or clipping by the clipBox.

Design Intent: This definition ensures that geo-conversion does not need to concern itself with the specific content the element is rendering (such as image pixels or internal SVG coordinates). Instead, it focuses solely on the conversion between the CSS plane occupied by the element and the geographic space.

This allows for a completely consistent common standard across different element types, such as <div>, <img>, <canvas>, and <svg>.

Native Geolocation Layout (CSS Integration)

The most significant practical benefit is high-precision display synchronization achieved by the browser's layout engine directly interpreting geographic coordinates.

• geo-location Property: By specifying Geographic Coordinates for a Rendering Unit (child element), the browser automatically calculates the appropriate coordinates within the container's local coordinate space to place the element.
• Synchronization via Compositor Thread: For user interactions like panning and zooming, the browser updates placement without involving the JavaScript main thread. This physically eliminates the "jitter" or "shaking" between the map and markers often seen in traditional libraries, providing an extremely smooth visual experience.

<div class="map-container">
  <div class="pin-marker">📍</div>
</div>
    

.pin-marker {
  position: absolute;

  /* 1. Geographic Coordinate Specification */
  /* The browser automatically converts this to CSS coordinates using the container's strategy */
  geo-location: 35.6586deg 139.7454deg;

  /* 2. Fine-tuning Anchor Position using existing properties */
  /* Aligns the tip of the pin (bottom center) with the latitude/longitude */
  translate: -50% -100%;

  /* 3. Smooth behavior during zoom */
  /* Movements "stick" to the map because they are synchronized on the compositor thread */
  transition: transform 0.1s linear;
}
    

Coordinate Transformation Interface (API Extensions)

To allow developers to easily perform dynamic interactions and spatial calculations, the following standard methods are added to the Map Container element. This removes the need for content-side heavy projection libraries.

MapContainer.getGeoLocation(x, y)

Takes coordinates in the container's local coordinate space (in CSS pixels) and returns the corresponding geographic coordinates (WGS84 [[WGS84]] ).

MapContainer.getCSSLocation(longitude, latitude)

Takes geographic coordinates and returns the latest CSS coordinates within the container based on the current zoom level and strategy.

These methods ensure consistent results by internally calling the Coordinate Transformation Strategies (Worklet/LUT) defined in the model.

Maintaining Orthogonality with Existing CSS Properties

This model does not introduce new properties for map-specific anchoring. Instead, it achieves flexible placement by combining geographic positioning with the existing CSS box model and transform properties.

• Self-Offset Utilization: By applying the existing translate property to an element placed via geo-location, accurate anchoring can be achieved regardless of the icon's size.
• Inheritance of Transforms: Standard CSS properties like rotate and scale apply normally to elements placed via geographic coordinates.

Semantic Accessibility (A11y)

When the browser understands the "real-world position" of each Rendering Unit, the accessibility tree can be constructed spatially. This allows the browser to move beyond treating map content as a simple image and instead recognize it as an organized geographic space.

Automatic Spatial Navigation Support: Because the browser natively understands the geographic location of elements, assistive technologies can automatically present spatial context to the user, such as:

• "Tokyo Tower (landmark) is displayed near the center of the screen."
• "There are 3 restaurant markers within 500m of your current location."
• "The map has been scrolled north. Mount Fuji has entered the new area."

This elevates map content, previously recognized only as an image, into an "explorable, meaningful space" for users with visual impairments, providing them with the necessary context to navigate and understand the relationship between different geographic points.

Limitations in Level 1 (Simplification of Implementation)

To ensure robustness and security, and to minimize the initial burden on browser implementers, Level 1 includes the following restriction:

• Prohibition of Nesting: A Map Container cannot be placed inside another Map Container.

This restriction avoids high-load, complex processing involving "inverse projection and re-projection from already projected figures," thereby maintaining a simple and predictable rendering pipeline for the User Agent. By keeping the model to a single layer in Level 1, we ensure that the performance benefits of GPU-friendly transformations can be realized without the overhead of nested coordinate system calculations.

Case A: Hand-drawn Tourist Illustration Map

This scenario involves publishing a "hand-drawn map" on the Web—which may not be geodetically accurate but is visually engaging—and displaying the user's current location.

• Challenge: Hand-drawn maps do not have a constant scale, making it impossible to define them using mathematical projection formulas (projection functions).
• Solution: Adopt the geo-conversion-parameter: lut() (Look-Up Table) strategy.
• Implementation Image: A correspondence table is created by mapping several points on the map (e.g., major intersections or buildings) to their "CSS coordinates on the image" and their "actual latitude and longitude." The browser then interpolates between these points.
• Benefits: Even for non-GIS content, it becomes possible to place markers with geo-location or coordinate with the Geolocation API to show where the user is currently located on the illustration.

Case B: Real-time GIS Weather Layer

This scenario involves displaying dynamic observation posts over weather data that uses an advanced projection method (e.g., Lambert Conformal Conic projection).

• Challenge: Advanced projection calculations with significant distortion are required, necessitating both high performance and security.
• Solution: Use the geo-conversion-worklet.
• Implementation Image: Complex coordinate transformation logic is defined as a JavaScript Worklet and executed separately from the main thread. Numerous observation points (Rendering Units) are assigned a geo-location.
• Benefits: Because the placement updates are synchronized on the browser's compositor thread, observation posts will "stick" to the background without any jitter or lag, even during intense panning or zooming. By internally converting results to a LUT, the system benefits from high-speed GPU rendering.