Planned customization
This page exists so that the boundary of the current version is visible. It is easier to design an integration when you know which gaps are permanent and which are simply not built yet.
What is configurable today
| Area | Surface |
|---|---|
| Initial place, floor, and room | URL path and parameters |
| Which interface elements appear | Chrome flags |
| Selection | map.selection |
| Viewport, animation, and scripted motion | map.camera |
| Basemap between standard and satellite | map.camera.setBasemap |
| Gesture locks | map.camera.setInteractions |
| Routes | map.directions |
Under consideration
These are not available, and no timeline is attached to any of them. They are listed because they are the requests that come up most often, and because knowing they are anticipated may change how you structure an integration now.
| Capability | What it would allow |
|---|---|
| Host-supplied theming | Accent colours and typography within brand limits |
| Marker placement | Pins and labels supplied by the host |
| Highlighting | Emphasising rooms without selecting them |
| Search control | Driving the map's search, or filtering its results |
| Kiosk mode | Idle timeout, camera reset, on-screen keyboard |
| Camera insets | Framing that accounts for host interface overlapping the map |
| Camera constraints | Host-set zoom limits and bounding boxes |
| Position injection | Feeding the map a position from your own positioning system |
| Height reporting | An event allowing a host to size the frame to its content |
| Language selection | Once the map itself is localised |
| Multi-destination routing | More than one stop on a route |
Not planned
Two things are deliberately excluded rather than pending.
Injecting CSS or JavaScript into the map. The isolation between the map and your page is what makes it safe for both sides to change independently. A host styling the map's internals would turn every internal change into a breaking change for that host.
Direct access to the map's DOM. The same reasoning. What crosses the boundary is a named, versioned message, and that is what makes the compatibility guarantees on the next page possible.
Neither of these is a limitation to work around. Where a host needs interface that the map does not provide, the intended approach is to hide the map's version with a chrome flag and render your own in your own application, driven by events.
How additions will arrive
The protocol only grows. New capabilities arrive as new commands, new events, or new optional fields on existing payloads, and existing names never change meaning.
The practical consequence is that an integration written today will keep working
when these arrive, and that adopting a new capability means checking
map.supports() and upgrading the package rather than rewriting anything. The
mechanics are in compatibility.