Ditch Shadow DOM and HTML Imports in the name of compat?

[potch]

One of the big problems with Brick in its current form is that its use of Shadow DOM and HTML Imports polyfills severely limits the environments in which Brick will work correctly. The polyfills are slow, incomplete, and break CSP. I know a large amount of effort was spent moving to use the polyfills, but I'm asking for a re-evaluation. My proposal is to double down on Custom Elements, but back away from other WC specs until they are in deployment:

• Change individual components to use only Custom Elements
• Use specific CSS classes to namespace styles in an extendable/overwritable way that is unlikely to conflict with other classes on the page.
• Use browserify to perform build on individual components as well as a bundle. browserify knows how to inline styles or markup needed for a component, and lets us use 'require'-style imports for better code structure.

Thoughts? /cc @mozbrick/owners

[tofumatt]

I am REALLY in favour of this, as someone who wants to use brick in recroom/high-fidelity but can't because of CSP and the weirdness of html imports. Honestly I find it confusing and slightly too clever.

Matthew Riley MacPherson (Sent from mobile)

On 1 October 2014 19:13:52 GMT-04:00, Potch [email protected] wrote:

One of the big problems with Brick in its current form is that its use
of Shadow DOM and HTML Imports polyfills severely limits the
environments in which Brick will work correctly. The polyfills are
slow, incomplete, and break CSP. I know a large amount of effort was
spent moving to use the polyfills, but I'm asking for a re-evaluation.
My proposal is to double down on Custom Elements, but back away from
other WC specs until they are in deployment:

• Change individual components to use only Custom Elements
• Use specific CSS classes to namespace styles in an
  extendable/overwritable way that is unlikely to conflict with other
  classes on the page.
• Use browserify to perform build on individual components as well as
  a bundle. browserify knows how to inline styles or markup needed for
  a component, and lets us use 'require'-style imports for better code
  structure.

Thoughts? /cc @mozbrick/owners

---

Reply to this email directly or view it on GitHub:
#268

[sole]

There are two options here:

a) betting on HTML imports but adding the "introvert" step so they end up being a distributable .js
Issue: contributors might find this awkward
b) Getting rid of HTML imports altogether, add the browserify step or something. There's still an extra step prior to a build (browserify) but it's a bit of an standard by now and not so unfamiliar to contributors
How are we including templates and css in this? This is something I've been wondering/wanting to investigate for a while too, some people mentioned "browserify transforms" but I am not familiar with these.

By the way, I was experimenting with a dual "automatic" HTML style and browserify component registration style in an attempt to produce some components for mortar:
https://github.com/mozilla/mortar-tabs-component/blob/master/src/component.js#L121-L127

[sole]

Oh also HTML Imports just were implemented in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=877072

[mstriemer]

I recently added our first custom element to Marketplace in a similar fashion. The shadow DOM and HTML import polyfills are just too big to justify.

I unfortunately copy/pasted the JS/CSS into our (two) projects since I didn't have time to figure out how to share them. So we've got a distribution problem with this setup.

I think it would be nice to use HTML imports in development and run something that extracts the vanilla JS/CSS and hand it off to your app's regular concatenation/minification build process. Not sure if something like that exists. Is this the "introvert" step?

[fwenzel]

Is this the "introvert" step?

Yes that's what it does. We might be able to bet on HTML imports like sole says, but we have to carry the overhead until that falls into place. Implementation in Firefox is promising but FxOS devices won't gain that capability for a long time. Any sort of cross-platform usage suffers from this.

How hard is it to write code without HTML Imports for now and convert it at a later date? Just slightly obnoxiously gruntworky, or "this will require a rewrite"? I'd probably err on the side of using neither in development until there's a large amount of platform support for our target audiences.

[csuwildcat]

@fwenzel it's not hard to convert things to Imports later - in reality, creation of these elements is more efficient in script anyway, and there is no standard declarative API. What Imports gives you is Template and resource delivery in a cleaner way.

The guts of a component don't change too much going from purely imperative JS to an implementation that leverages Imports. The biggest change when doing things purely in JS is you don't need to create a Template element, you just assemble and stamp custom element guts using the imperative equivalent: a DocumentFragment. Going to an Import later would mostly be about switching to use Template elements you include inside your Import, which should be a trivial change.

The following part of this response is not out of spite, it's a purely empirical observation:

X-Tag set out to do almost exactly what this thread describes: create awesome custom elements with maximum code reuse, a reduced per-component footprint, just the right amount of features to serve the 80% of component cases, and no reliance on specs that were infeasible to polyfill or put in a production app.

To be candid: do I agree with ripping out X-Tag? No, I believe it's a bad idea and you'll end up with just as many dependencies/code bits (or even more) to achieve similar ends.

Whatever direction you choose to go, this project is something Potch, Sole, Matt, etc., are more than capable of handling if they put sufficient effort into it. I do wish the project well regardless of outcome because it could help developers and Mozilla (especially if FFOS used it) - which is more important than any one of us, or our opposing views.

[lmorchard]

Coming into this thread late... From what I've seen so far, the custom element API is the main event.

We can cope just fine without HTML imports at runtime. We can structure CSS so that the lack of Shadow DOM isn't a showstopper. Templates are kind of neutral - doesn't hurt to use, especially not if we're shimming HTML Imports at build time.

FWIW the "Introvert step" refers to lmorchard/introvert. In a nutshell, it does this:

• Take the HTML source of a component
• Chase down all the dependencies linked via HTML Imports
• Inline CSS into each HTML doc
• Inline each HTML doc as an string used with a function wrapping the associated JS
• Bundle everything into a single JS library

In a nutshell, it's a build-time HTML Imports shim. You can author as if HTML Imports were available. Introvert probably still needs work, patches welcome etc etc...

[lmorchard]

Oh, and I've been recently playing with browserify... if it can handle inlining styles & markup better, along with what it already does for JS, I'm more than happy to mothball introvert 😄