Could *not* using custom elements for all MapML elements be problematic?

[Malvoz]

Consider the following markup from mapMLFeatures.html:

<feature zoom="2">
  <properties>
    <h1>Test</h1>
  </properties>
  <geometry cs="tilematrix">
    <polygon>
      <coordinates>11 11 12 11 12 12 11 12</coordinates>
    </polygon>
  </geometry>
</feature>

for the same reason (future web compat considerations?) we're using <layer-> as opposed to <layer>, could this be problematic?

I keep stirring the pot.

[prushforth]

Currently, there is no live DOM for <feature>; everything is rendered as SVG paths, or even Leaflet objects which themselves are eventually rendered via either SVG or <canvas>. To be frank, I have not (deeply) considered how a custom element <feature-> would behave, exactly. Is it something we should actually do? I am asking.

[Malvoz]

there is no live DOM for <feature>

Whether live DOM matters or not in this context I don't know. Anyhow that's not always the case, for other MapML elements, e.g. <tile> etc. in mapMLStaticTileLayer.html.

Is it something we should actually do?

I can only speculate, I'm concerned about the implications regarding future web compatibility considerations in the case of running BigQuery/HTTP Archive queries where it may be found that element X is already in use in Y amount of web pages, and so the question may then be: is it safe to implement those elements in browsers?

Maybe @bkardell or @zcorpan can help inform us whether we should use custom elements for every MapML element, or if it's safe to use <feature> for example, in this prototype implementation?

[bkardell]

Wow, very sorry for the incredibly slow reply here - I missed this tag entirely and just accidentally came across it looking for something else.

In my opinion (I dont think controversial, and I think in alignment with lots of other advice): You shouldn't be adding to the mess that exists already of using non-standard, undasherized elements in the light dom, or similarly, using elements in a way that is not currently compatible.

[Malvoz]

Thanks @bkardell, I think your opinion is in alignment with Simon's advice in Maps4HTML/MapML-Proposal#17 (comment) as well:

Moreover, I think creating a legacy of web content before a proposal is implemented can hurt the proposal more than it helps. Bugs in the polyfill can get relied on by web content, resulting in the final API needing to use different names from what is used in the polyfill. (Examples: Array.prototype.contains; Node.prototype.rootNode)

For the situation of no browser implementation and only a polyfill, I suggest not using the names that you want to reserve for the final API until it is shipped by at least one browser. (This was practiced by PictureFill, which used spans until picture was implemented in browsers.)

I suppose they used spans because custom elements wasn't a thing (or widely supported) at the time. We should be able to use the desired names, only dasherized.

[Malvoz]

Closing in favor of #511.