tmcw/maps4html.md Secret

## maps4html.md

      
    Raw
  

              maps4html.md
            
          
    Maps4HTML

So I read the Maps4HTML report, explainer, and usecases and played with some of the demos. Here are some thoughts. Before I dive in, some caveats:

The people involved with this project seem extremely friendly and well-intentioned and my guess is that regardless of whether this spec takes off, the process will have a positive long-term impact.
I have lots and lots of historical grudges and biases and priors
And, as Murray Kempton put it,


A critic enters the battlefield after the war and shoots the wounded

So, anyway:

Is there any advantage to having a simple web map tag in #HTML?

Thoughts.
There are intertwined goals and beliefs involved in this effort. Some I can pick out:

Making maps more like HTML: user-side styling, document authoring.
Making a specification, to encourage multiple implementations targeting the same thing. It would be cool if maps were easier to scrape or compose.
Accessibility
Performance
Making it easier to make maps

Then there's approach-driven stuff:

This being a W3C/OGC joint effort in which the result is a browser implementation

I'll review these, then address some other qualms
Making maps like HTML

Think about an HTML5 "range" input. You can style the sub-parts of it, target those little bits and pieces.
input[type='range'] {
    -webkit-appearance: none !important;
    background:red;
    height:7px;
}
input[type='range']::-webkit-slider-thumb {
    -webkit-appearance: none !important;
    background:blue;
    height:10px;
    width:10px;
}
Very cool. When I look at the Maps4HTML… HTML, the first question I have is "is it real". Like this this markup, can I address the ID on the page, in HTML, girl12, and style it with CSS?
      <mapml-viewer projection="WGS84" zoom="2" lon="-111.062839" lat="-8.059046" controls>
        <layer- label="Painting" checked>
          <map-meta name="zoom" content="min=0,max=7"></map-meta>
          <map-extent units="WGS84">
              <map-input  name="zoomLevel" type="zoom" value="1" min="0" max="4"></map-input>
              <map-input  name="row" type="location" axis="row" units="tilematrix" min="0" max="2"></map-input>
              <map-input  name="col" type="location" axis="column" units="tilematrix" min="0" max="2"></map-input>
              <map-link tms rel="tile" tref="https://maps4html.org/TiledArt-Rousseau/TheBanksOfTheBièvreNearBicêtre/{zoomLevel}/{col}/{row}.png" />
          </map-extent>
          </layer->
          <layer- label="People" checked>
            <map-meta name="projection" content="WGS84"></map-meta>
            <map-feature id="girl2" class="child" zoom="2">
              <map-featurecaption>Girl - zoom=2</map-featurecaption>
              <map-geometry>
                <map-a href="#5,-158.518400,-74.697610">
                  <map-polygon>
                    <map-coordinates>-158.561948 -69.558455 -159.440739 -70.832538 -162.384689 -75.709198 -160.890744 -78.916371 -159.371228 -80.304936 -154.563449 -79.751115 -157.683157 -69.646323 -158.561948 -69.558455</map-coordinates>
                  </map-polygon>
                </map-a>
              </map-geometry>
              <map-properties></map-properties>
            </map-feature>

In the current Maps4HTML implementation, the answer is no - the map-feature element is parsed and thrown on a Leaflet map as a usual element. In the future, I'd guess the answer is still a very flat no - if you use modern Google Maps, Maplibre, or Mapbox GL, most features are not elements. They're not nodes in HTML. They're just in memory, and written as pixels with WebGL.
Which just makes me wonder how much like HTML is this - is HTML a useful metaphor for map data? Can users reasonably expect to style their map features like HTML, or manipulate this sub-DOM and get interesting things out of it?
Making a specification

It's hard to make a specification. Ethically, it's dangerous to specify something without casting a wide net and getting lots of opinions. Practically, it's almost impossible to make a spec if you cast a wide net and get lots of opinions. The sheer number of usecases and parties involved scares me.
Simplicity is really, really hard, and the difficulty lies on a power and human level, not a technical level. You have to say no, a lot, to deal with pissing people off, and so on. You have lots of people who want their feature, and not enough people afraid of too many features.
Accessibility

This is a weird one. Why not create a test rig and ARIA standards for how maps should be accessible, make a big webpage like "aremapsaccessibleyet.com", score the map frameworks, try to make them improve?
I fear that part of this confusion is about elements - that putting map features or map details in an initial HTML document structure on the first load looks accessible. This really isn't how accessibility works in 2022: highly dynamic JavaScript applications can be thoroughly accessible by changing the DOM in real-time and following both ARIA specs and real-world screenreader behavior religiously. Screenreaders all work with dynamic webpages. There's no point in putting map features in the initial DOM when you could add them as a hidden accessible element that knows to announce to screenreaders.
Performance

Kind of, I guess - this sort of makes sense. It does remind me of the idea of just "putting React in the browser", which is still appealing to me. Browser performance is good, but taking existing client-side libraries in userland and moving them into the browser platform, in order to avoid their javascript payload, is not that appealing a notion. You trade the fast release cycle and high level of control and debuggability of userland code for the relatively slower release cycle and black-box debuggability of a browser API.
Making it easier to make maps

This one seems fishy - the experience with a Web Component polyfilling the Maps4HTML spec should be roughly the same as the experience once the browser implements it. If "maps as HTML elements" are a good idea, you can push hard on a Web Component, make it super popular, and then have an easy sell to browser vendors.

Other stuff:
The elephant in the room: vendors

A lot of Maps4HTML examples use OpenStreetMap tiles. If Google Chrome started pointing every user to OSM's servers, you would have a lot of angry people - even angrier than they are today, and trust me, OSM users are angry.
In the general, average case, maps require basemaps. Basemaps require servers and upkeep and systems of trust and licenses. This is a big deal, and if you don't engage directly with this challenge, there is no chance of success.
The endgame I'd guess is that this standard goes live, Apple embeds Apple Maps (like they do for iOS apps) and Google embeds Google Maps (like they do for Android apps) and Linux embeds… not sure. Anyway, this is a really hard problem.
This is where the maps-as-images-or-videos metaphor does not work. Embedding a basemap isn't like embedding an image. You aren't pointing to a "source" that you control. You're asking the provider for a background image. So either this challenge gets pushed in a weird direction (HTML maps include… API token support), or?

Complexity

It's complex. I'm seeing multiple projection support. Lots of references to heatmaps. Animation. So on. This is a complex standard.
Ideally, a lot of that stuff would be pushed into the userspace - if you want heatmaps, you have some custom JavaScript. Why are map controls in the spec, and not in userland?

Anyway, the goals are noble and if I were the king of Maps4HTML I'd probably just focus on:

Going deep on accessibility, create some rigorous testcases, and improve the state of the industry.
If we believe in maps-as-elements, focus 100% on making a web component so good that people will want to use it, standard or not, and marketing that web component as just a way to make maps, not part of a larger effort.
Punt on standardization indefinitely: old-school standards bodies and brainstorming do not produce good things.