Refactor, and extend native <img>

[madeleineostoja]

Simpla-img needs to be rebuilt from the ground up to be polished, maintainable, and stable. Biggest (breaking) change will be extending a native img element, rather than just exposing a custom simpla-img element.

Extending native elements is a very contentious part of the Web Components spec (track the discussion here: https://github.com/w3c/webcomponents/issues/509), and it may never be implemented across the board, at least not under its current guise (the is="" syntax).

It's essentially impossible to properly replicate the native sizing behaviour of images with CSS, and the Javascript required to do so would be prohibitively expensive. Extending native will also allow us to pre-render images, since a native img element can properly display an image without being upgraded, a <simpla-img> cannot.

The only alternative is to nest an img inside simpla-img in the light DOM, ie output:

<simpla-img sid="img">
   <img src="img.png" />
</simpla-img>

But that means that we're forcing an extra level of DOM around every individual image on a user's page, which breaks the core tenet of Simpla being interoperable with static content and all frameworks/libs. Not to mention the confusion and poor DX (now devs have to target simpla-img img rather than simpla-img, and worry about a not-quite-transparent dummy layer).

---

Major tasks

• [x] Extend native img element (will require new UI)
• [x] Remove unnecessary sub-components (hurts perf)
• [x] Separate editing logic from viewing
• [x] Move to Simpla SDK (replace all utility components)
• [ ] Migrate to Polymer 2.0

[madeleineostoja]

Note did achieve native-like sizing behaviour in the past using new intrinsic CSS sizing props, see this pen (on Chrome, Firefox, or Opera). But support is patchy, and there's no way to polyfill it, so it's a no-go for legacy (or even recent) browser support unfortunately.

[bedeoverend]

Plus, even if intrinsic could somehow be polyfilled, the accessibility / pre-render benefits of extending native img unfortunately can't be replicated.

Also FWIW I believe there's still hope for is="", whilst unlikely for Safari to implement in its current form, it seems the general consensus is that its usage in the wild by devs will be what causes browsers to adopt. It is also able to be polyfilled, most likely into the future, as shown by the current webcomponents polyfills.

[madeleineostoja]

Yep can definitely polyfill is="", it's more just what becomes accepted in future. The last thing we want is for Simpla's interface to be composed of (what becomes known as) hacks and DSLs.

That said, the beauty of an ecosystem is you can swap bits out if need be. So either way there's not much to lose, it's just what we want to set as the standard (as our in-house elements, like img and text, will likely be used as best practices).

And, not to be pedantic, but can replicate pre-render benefits by nesting an image. Though I really don't like that solution.

[madeleineostoja]

Worth holding off on this until Polymer 2.0 is released mainline, and upgrade to that at the same time. Will update tasklist to reflect.

On that point, we need to once again seriously think about relying on type extension. Polymer 2.0 is deprecating all helpers that extended, moving to the inner-element hack instead, and they're discouraging others from extending elements as well. We don't want to be building to what is quickly becoming an anti-pattern.

[madeleineostoja]

Quick update re: type extension - it sounds like Mozilla may be shipping support for extending built-ins in their custom elements v1 release, no word on Edge. And the DRE polyfill only uses the polyfill on webkit for extended elements, falling back to native for autonomous web components. There's also a few rumblings of using custom-element style attributes to shim is="".

So depending on how things play out it could still make sense to extend a native img - the tradeoffs for not doing it could outweigh the slight cross-browser hackiness of doing it.

[bedeoverend]

From a recent Blink post, Blink is definitely shipping + Microsoft looks like it will. Plus digging into the Firefox source code as mentioned in the same post, it looks like they'll be shipping with is= support.

The recent TPAC also looks like Domenic Denicola has proposed the idea of custom global attributes, which could provide a platform for element mixins. The interface he described was very similar to this custom attributes POC interface. It looked like the Apple folk might be a bit more on board with that idea, as their objection to is was that it felt like it was a half baked singular 'mixin', rather than a proper mixin solution. Search for is= in the TPAC minutes for more info.

[madeleineostoja]

Excellent news!

Custom attributes are very interesting. From reading the minutes sounds like they could well replace type extensions. It seems if they did get adopted then extending built-ins with is="" would become functionally redundant, because the niceties of having a constructor vs. attrs with callbacks would be outweighed by the limitations of a single extension vs. mixins.

And, much more importantly for us, it seems (chime in @bedeoverend) that custom attributes could serve Simpla's users better than custom elements. They would finally give us assured interop with static HTML (and all the accessibility and prog enhancement goodness that goes with it), a better dev experience for authors, while retaining the important parts of the power/flexibility we currently have with custom elements. And unlike type extension you could then mix the same Simpla behavior into multiple elements, eg: simpla-text in headings, p, etc, or one simpla-list for ul and ol.

It would be a pretty radical departure, but if it's a vastly better solution for our users then that's all that matters.

Maybe we should spin up our own POC with matthewp/custom-attributes?

In any case, far off topic for this issue - let's move discussion elsewhere. Shall I open an issue on simplaio/simpla?

P.S. While we're off topic, the HTML Module discussions were super promising too, glad we wont be stuck with vanilla ES6 modules for wc.

[bedeoverend]

@seaneking yup move the general custom attribute discussion over to simplaio/simpla.

As for refactoring simpla-img into extending native - obviously the attribute discussion will affect that, but it's looking like is="" might be still viable. For solely our purposes, if we need to, we may also be able to use matthewp/custom-attributes to create an is="" ponyfill or something just to handle simpla-img.

[madeleineostoja]

Shipped in https://github.com/SimplaElements/simpla-img/releases/tag/v1.0.0