Refactor MapML elements as custom elements

[prushforth]

Per #174, it seems like a best practice of Web platform speculative polyfills is to generate proposed new APIs in a separate namespace, so that the name of the polyfills doesn't collide with the eventual standard name.

For elements, that implies today that we should use custom elements, and if I understand correctly, probably also data- prefixed attributes. Customised built-in elements would be ideal for implementing proposed extensions of existing elements, while autonomous custom elements would better serve the use case of new elements. There is apparently a viable polyfill for customized built-in (is=), but unsure how it works. It may not be worth the trouble of using the polyfill, opting instead for a apec explanation of the intended name of the eventual element.

This issue is for discussion of how to approach this refactoring.

We'll also need to decide how to do this in the draft spec, so that it's clear whether a proposed.element is 'new', or an extension of an existing element.

Also see Maps4HTML/MapML-Specification#215 (comment)

[Malvoz]

probably also data- prefixed attributes

Just noting that IMO the situation regarding "custom" attributes vs data- prefixed attributes (related: #191) is much less important than converting the MapML elements to custom elements containing a hyphen. Especially so if the attributes are used only on custom elements, since that wont "pollute" standard HTML elements. So perhaps this issue can focus solely on the elements aspect?

[prushforth]

Yes, for now we'll focus on elements. What's your opinion on the <mapml> element?

[Malvoz]

All MapML elements must contain a hyphen, so it'd be <mapml->. In the spec and the explainer the elements should be referred to without hyphens.

Edit: well, assuming nobody serves .mapml files with content-type text/html (whether that'd work or not) it should be fine to use <mapml> I suppose, since that element can't be inline in HTML. But for consistency we may as well use <mapml->?

[prushforth]

Ok, I went with <mapml->, but everything else (except mapml-viewer and layer-) I put into the map- "namespace". ok?

We'll need to explain this somehow, perhaps in the MapML spec?

[Malvoz]

I don't think there's a need to use a map- prefix. The MapML spec should name elements as they're intended to be standardized. But the polyfill must follow the HTML custom components rules, so they're required to include a hyphen.

The intention is then that when the spec is mature and browsers are ready to implement it and the polyfill follows the spec exactly (the tipping point) we're safe to remove the hyphens because now the polyfill is guaranteed to match the behaviors of the standard.

[Malvoz]

Fixed in c67198b.

Thanks to everyone involved!

[prushforth]

Thanks to everyone involved!

Thanks to you, too, for motivating some change for the better. Hopefully any bugs are minor.