Web components are a native set of features that provides outstanding scoping of styles and functionalities. They can be used in a regular, framewo...
For further actions, you may consider blocking this person and/or reporting abuse
Émile, have you gotten a change to checkout web.dev/more-capable-form-controls/, it's a pretty well agreed to spec with in-progress (except maybe in Safari, as with too many things 😞) development or shipped implementation in various browsers. It's a great way to ensure that custom elements are properly associated with the forms in which they live. @calebwilliams12 also has a great write up on this for CSS Tricks where he introduces a polyfill for smoothing those browsers that have yet to fully catch up: npmjs.com/package/element-internal... I think it'll do great things for form processing, and the underlying Element Internals API is opening up a lot of other cool possibilities in accessibility as well, so it's worth a follow. Cheers!
Wow, thanks for your comment, I wasn't aware of this spec!
Although it's quite as "simple" as allowing the extension of built-in form elements, it looks like it's the next best thing! Plus, this allows for way more customization for components that do not extend/represent built-in form elements.
I'll definitely give this a shot and keep track of the browser adoption.
Thanks again! :)
Agreed about extensions of built-ins, it would be really nice if Safari would just get over that and ship it, but it's better to move on than to fume on it too much at our level, even if there's a relatively small polyfill for them: github.com/ungap/custom-elements-b.... We should look at trying to get it separated/removed from the web components spec so that it's easier to do so, IMO. Then, we can focus on more agreeable/likely to ship x-browser specs like Element Internals.
Once you've had some time with Form Associated Custom Elements, I hope you'll share updated thoughts on the path forward with web components so we all can check them out!
Agreed!
I will experiment with the Form Associated Custom Elements in the next few days/weeks, and I'll update this article or make a new one about my thoughts and experience if it's worthwhile!
Thanks again for all this great information 🙌
@westbrook , you really helped big time with these comments today.
I just toyed around for 10-15 mins while reading the CSS-Tricks article you mentioned, and that was enough time to successfully turn my globally-styled inputs into a working input web component.
I expect I have a ton more work ahead to ensure it's as accessible and fully-featured as a regular input, but it is great to have a working and supported(-ish) solution to this problem!
I'll definitely make another article about this once I get enough time in. 👍
While in theory the form-associated API is the right™ choice, its current support is limited (only Chrome). However it is not so hard, to support Submit, Reset interaction of CustomElements. You simply grab your
closest()<form>(and of course piercing any ShadowDOM you might encounter) and then simply listen for Submit or Reset events and act accordingly:One point to add.
Web Component technology is older and more used than most people know.
The
<video>, <audio>, <textarea>, <input>and many more complex HTML tagsare implemented in each Browser with Web Component (like) technology.
In Chromium you can tell by the user-agent (= tech term for Browser) label on the shadow-root:
Us mortal developers can not access the HTML elements inside user-agent shadow-root.
Also see: javascript.info/shadow-dom
But... that technology was not available to us 3rd party developers
What we now call "Web Components" (Custom Elements API, Templates, shadowDOM)
IS that very same technology available to us all
But we can't access user-agent managed shadowDOM! (or "closed") shadowRoots)
So everyone who claims Web Components is young, not yet fleshed out, bare metal, hardly used, technology... does not understand how the Browser works.
It's true that the underlying technology isn't new, and has been out there and in use by browsers for a rather long time.
However, usage by the masses in their own websites and applications is different than internal usage by browser developers, so it's not untrue that the technology, to the eyes of the public, is fairly young and hardly used. I think that'll change in the future though.
When does hardly used then gets to the next stage?
chromestatus.com/metrics/feature/t...
Says: "over 10% of Chrome browsed websites, use ``customElements.define"
And that is with (about) half of all Social Media "Web Components" posts,
partly focussing on the "bad" aspects.
And if your stats are based on what Web Components you detect in F12 Dev Tools...
You could be wrong, because active Web Components could have done their work and removed themselves: dev.to/dannyengelman/the-lt-site-h...
WebComponents are one of those things where we're getting toys before they're ready. In principle, they allow for excellent encapsulation and reusability. In practice, the overhead (including the amount of basic infrastructure needed to develop them) makes them tedious to work with, and the rules around them aren't really practical in many ways. Some bleed-through of CSS is often desired. Some better way of transporting state in and out of them and interacting with the current document/window natives is often desired. Some means of filling placeholders that well exceeds
<template>(e.g. DOM nesting restrictions) is often desired.It's a simple API on the surface, but to make it really applicable at scale it needs a lot more thought.
You seem to have not really used Web Components, they are offering all what you are mentioning today:
The work that has been put in these past few years, especially by the community, has made them quite usable in many scenarios. And from what I've seen from the articles mentioned by @westbrook just a few minutes ago, they will likely get much better in the not-so-distant future.
However, I have to agree that there is stil a lot of work to do to before they can really get widespread adoption. They will likely be much more developer-friendly, permissive and scalable in the future.
It’s worth mentioning that many framework users bind data directly to form controls (vanilla and in shadow roots). If you’re doing that you won’t run into the form data problem.
+1 regarding ElementInternals, though. I can’t wait for a proper form participation API so this becomes a non-issue.
You can avoid FOUC by using a shared css file that is first loaded by the page then linked inside the WC template.
The browser will have already cached the shared styles so it will Not reload the stylesheet, but instead use the cached version. Linking the stylesheet in the template adds the shared styles to the WC's scope.
There's something to be done with assets preloading to help with the FOUC, indeed.
However, it seems you can still run into FOUC issues when your components make use of the shadow DOM, as the structure of the element will likely change between the initial page load and the moment that the WC is rendered.
Nice article! I have used LitElement to develop a very complex Chrome extension and so far the performance and the development experience has been great for me.
Glad you liked it! I also use Lit, and the ease of development and performance is indeed quite impressive!
An interesting insight into web components. Wonderful article!
You should not use web components as well, if you need different styles of the components depending on where they are used (In other words, if you want your components to use global css)