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...
For further actions, you may consider blocking this person and/or reporting abuse
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)?
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.
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.
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.
Hmm, could you name a case? I'm trying to imagine but nothing comes.
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.
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.
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.
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.
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.
: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).
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:
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:
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.
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: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.Very well explained
dev.to/richharris/why-i-don-t-use-...
also explains other issues related to webcomponents.
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").