DEV Community

Beyond the polyfills: how Web Components affect us today?

Serhii Kulykov on April 09, 2019

After the recent public announcement of Chromium-based Edge canary builds, there has been a lot of excitement on Twitter because of the Web Compone...

Read full post

Vlad Rindevich • Apr 9 '19 • Edited

Regarding the customized built-in elements: I know that there's a way more promising solution supported by WebKit team. The Custom Attributes. However, there isn't a lot of hype on it for some reason even if it looks as exciting as Custom Elements. Do you know something about this proposal and why it doesn't go forward (or maybe it does but very silently)?

Serhii Kulykov • Apr 10 '19 • Edited

Thanks for the feedback. Regarding the Custom Attributes, the only discussion I remember is this issue and also this shim by Matthew Phillips.

I don't have a strong opinion on this yet, but probably such a spec could take meta programming over DOM to the next level (if done right).

Also, I'm not sure how much performant would it be.

Vlad Rindevich • Apr 10 '19

I have seen one more discussion which is still opened now. However, the latest message is posted over the year ago. Don't want to believe, but it could be an abandoned proposal. Even if it looks as a great replacement for customized built-in elements. More powerful, IMO, because mixins are usually have more opportunities than inheritance.

Junk • Apr 10 '19

That's a cool idea and I agree it'll be very useful. But it won't cover all the cases or purposes of extending native built-ins.

Vlad Rindevich • Apr 10 '19

Hmm, could you name a case? I'm trying to imagine but nothing comes.

Goffert van Gool • Apr 9 '19

I think is a lot of unnecessary shade thrown towards Safari in this post. They are indeed slow to adopt new features, but in general I find their implementation quality to be better than that of Chrome in several areas.

If I had the choice between having everything implemented tomorrow, or a more sane and well refined standard, I'd choose the better standard every time. Nobody wants a Web Components v2.

Junk • Apr 10 '19 • Edited

No, but we do want 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13... Which won't happen soon enough if they lag too much.

Safari hasn't been keeping up in general for a while now. Wanna talk shade, did you miss people starting to call it the new IE? Ouch.

There could be good reasons, like you said. I'm assuming there are--there's no reason to think otherwise. For example, a couple of those missing features are actually brand spanking new and need more vetting.

Also, I don't think there's any risk of Web Components v2. The whole point of v1 was Safari agreed. Apple had lots of good feedback on Web Components. And they're just as capable of proposing specs as Google. I definitely hope they do if they're not happy with what Google's bringing to the table! They've contributed a lot of good over the years.

Serhii Kulykov • Apr 9 '19 • Edited

First of all, thanks for your opinion. I didn't mean to be provocative here (at least, not that much as the impression makes it clear now).

Due to the objective reasons, it sometimes takes a while for Google Chrome team to convince Apple WebKit team on why they think the users need a certain low-level API. If I remember correctly, this has previously happened to Service Workers, and few smaller web APIs too.

I'm not blaming Safari here, and to be honest Firefox has had a lot of smaller issues, and missing features in particular, once they rolled 63. And I have also described the reasons for them being opposite to at least two of the mentioned issues.

In fact, the point here is both about how much the consensus means and why I'm not that excited about "Chrome-only" features shipped recently. I will consider updating the post accordingly.

Junk • Apr 10 '19 • Edited

Don't forget about form participation and ARIA stopping at Shadow DOM boundaries.

Or that the inability to extend native built-ins sabotages accessibility and progressive enhancement.

Or that the ability to implement components with more complex semantics like lists or tables is neutered.

Or that we really need declarative Shadow DOM.

Also template instantiation or something similar.

Agreed, CSS Named Parts are critical.

Makes me feel greedy, because Web Components are really exciting. But they need a lot more standardized to support them.

Serhii Kulykov • Apr 10 '19

I agree that I have left certain topics out of scope of this blog post (both intentionally and not). I'm going to continue writing on this topic further, from a slightly different angle.

In the next blog post, I'm going to cover form participation API and password managers support among other things. ARIA is quite a good topic as well, thanks for pointing out.

David Simmons • Oct 21 '20 • Edited

:host-context
Is uniquely valuable in allowing a web-component design to remain encapsulated. This begins to show up more visibly as one really builds an application model and framework using components; as one might classically have done in MVC etc APP frameworks that pre-date the web. (And I worked on many, including, ironically, those that Apple became famous for in the late 80's and 1990's).

Today, Apple/Safari seem to adhere to a notion that you should not or cannot build native equivalent or better apps using web technologies. Or, perhaps, it is just not in their financial interests with the risk it poses to retaining the App Store iOS market share foundation [making them behave like Microsoft of yesteryear].

Whatever the technical or non-technical reasons, lacking it, one has to effectively mine the transitive closure of all web-components being utilized and pull out an equivalent ":host-context" and write it into a global-style sheet. Which defeats the purpose of having #shadow-root support styles for encapsulation; and further pushes the compiler-linker style work-effort demands of webpack transpiling of monolithic web-properties.

As in:

<body sa="/main/">
<sh-main>
  #shadow-root
  <style>
  :host {display:none;}
  :host-context(body[sa*="/main/"]) {display:flex;}
  </style>
</sh-main>
</body>

Allows the entirety of <sh-main> to be defined in a self contained mjs package, etc.

Without it, one (or a compile-link webpack toolset) has to add a global style for every web-component using this technique:

<style>
  /* -- ANTI-ENCAPSULATION POOH REQUIRED -- */
  sh-main {display:none;}
  body[sa*="/main/"] sh-main {display:flex;}
</style>

Pushing all the heavy lifting into the transpilers webpack compiler-linker side of things is retro web behavior and not forward looking to a just-in-time dynamic compositional componentized architecture.

I.e., a class-like path selector model is unable scale without :host-context once one uses this encapsulation approach to build things like class AppModels for cmd-buttons on menu-bars etc to simplify enable/disable/visibility designs. A classic approach from MVC frameworks starting in the late 1980's and after.

What may not be obvious, is that with the above type of technique of using that "sa" attribute as a path list (similar to using "class"), one can completely manage SPA view layering, modal-overlays, and cmd-btns trivially by merely listing them in three distinct body attributes. One for view-paths, one for modal-overlays, and one for enabled/disabled but visible icon/cmds.

If it is "technically challenging" for Safari et. al., to implement; that is fair. But the evolution of browsers and related technology has always been a road of technical challenges. What is not "ok" is not being "transparent" about the reasons for not doing it and instead "deflecting" because of turf-competition attitudes or worse, lack of technical awareness as to the bad web-design issues it promulgates.

If it is because Apple et. al., have the opinion that #shadow-root styles have some deep-flaws due to the lack of sharing model between instances of a given class of web-component, then that is what should both be said, focused on, and addressed. See Constructable StyleSheets.

James Browning • Apr 17 '19 • Edited

As spec-ed :host-context isn't super useful anyway as you can only select "some ancestor" rather than "some parent" or even more complex relations. Maybe once :has lands in browsers we'll be able to do :host-context(some-parent-element-type:has(> :host)) in which case I'd be more likely to care about the feature again.

For leaking styles in, in a lot of cases ::part is still too cumbersome if you want to expose many elements (although it's still great as custom-pseudo-elements). In a lot of cases I'd just like to defer styling of elements to whatever the outer tree is styling them as. Perhaps with something like:

<style>
  button {
    color: red;
  }
</style>

<my-element>
  <!--shadowroot-->
    <style>
      button {
        /* Not to be mistaken for all: inherit, this just allows this element to
            match element name selectors that are outside of the shadow
            tree, I haven't thought through the details of this idea 
            thoroughly though like how it might interact with nested trees
        */
        inherit-from-outer-tree: element-name pseudo-classes;
      }
    </style>
    <!-- is red because it matches the outer stylesheet's selector -->
    <button>Hello world</button>
  <!--/shadowroot-->
</my-element>

Serhii Kulykov • Apr 17 '19 • Edited

My gut feeling is that overusing ::part could be a smell of incorrect API design of the component (so that it could be split further into a number smaller components, etc).

At Vaadin, we have the workaround for writing CSS using [part] attribute, and then injecting those <style> tags into shadow trees. That's convenient in most of cases, but still not ideal, and developers need some time to learn that model.

codelitically_incorrect • Apr 17 '19

Very well explained

Abdul Rauf • Jul 10 '19

dev.to/richharris/why-i-don-t-use-...
also explains other issues related to webcomponents.

Serhii Kulykov • Jul 10 '19 • Edited

Thanks, I have seen that post. Personally, I focus on different kind of issues.

@richharris has his own vision about how the specifications are designed and what things are missing according to him as a framework author.

On the other hand, as a component library developer, I mostly care about the issues and nitty-gritty details with the actual implementation (some of those, like Selection API, focus etc, I have faced myself or learned from my team's experience).

I respect the input by Rich, but personally I don't see any "action point" for the community in his blog post (except for "beware of using Web Components").