search

Maps4HTML / MapML.js

A custom <mapml-viewer> and <layer-> element suite
https://maps4html.org/MapML.js/
Other
58 stars 16 forks source link

type extension elements discouraged #65

Closed elf-pavlik closed 3 years ago

elf-pavlik commented 7 years ago

https://www.polymer-project.org/2.0/docs/about_20#type-extension

Polymer 2.0 doesn't support type-extension elements (for example, ). Type-extension support is still included in the custom elements v1 spec (as "customized build-in elements"), and scheduled for implementation in Chrome. However, since Apple has said it will not implement is, we will not be encouraging its use to avoid indefinite reliance on the custom elements polyfill. Instead, a wrapper custom element can surround a native element.

Maybe README and demo should simply use

<web-map ...>

instead of

<map is="web-map" ...>
prushforth commented 7 years ago

I'm still holding out hope that Polymer 2.x will support type extensions. I wrote a blog post about why I think its important to go with <map is="web-map"> All that said I understand that Safari is unlikely to come around. I put an issue in with the Polymer project to support the is attribute in v 2.x, I'm hoping they will add support 'soon' after release of 2.0. I know Chromium is working on support for is, so its not quite dead yet. When/if it does become evident that is is dead, I will re-write the element as web-map. Thanks for your input. Will leave this open until a decision can be reached.

prushforth commented 6 years ago

After much anxiety over this, I've decided to re-write the web-map custom element as an autonomous element. I believe there are good reasons for wanting to extend the <map> element, but custom built-in elements which allow attachShadow() would seem to compromise the future of the native elements that should / could be enhanced in the future Web platform.

In the interest of enhancing the functionality of the web-map custom element as a "proxy" for a polyfill, or a "proxyfill", I accept the premise of this issue and will re-write the element as autonomous. The element needs a lot of new features to better support MapML and it has been kind of stuck on Polymer 1.0 for > 1 year because of the dropped support for custom built-ins in that library. Even with the pending support for custom built-ins in Firefox and presumably Chrome, the fact that the (map) element definitely needs a shadow root to protect styles but that adding a shadow root to <map> would compromise any future ability of the platform to use that shadow root for anything is the reason we should avoid tampering with the <map> element at this stage.

Instead of trying to convince by providing working examples, I will opt to ask the reader to discuss the practicalities of introducing a new element into the platform, given that new elements typically take years to be supported across all browsers. The discussion should centre on how HTML authors will provide fallback behaviour for the new mapping element(s).

In the mean time, I will leave this open, and will close it when the new autonomous implementation of the web-map element is ready. I think I'll leave the proposed spec for the <map> element as it stands since nothing in the custom element's design so far compromises that proposal.

prushforth commented 3 years ago

Although we still maintain the web-map.js custom built in as a way of demonstrating progressive enhancement of existing HTML elements, since Safari has no plans to support custom built in elements, we are currently relying on the autonomous mapml-viewer map element as a way to provide the functionality of a standard web map across the custom-elements-supporting platform. So closing this; if there's more to say, feel free to add to the conversation anyway.