Microsoft Fast Design

Thanks that actually sounds like it could have value, but again it's a new paradigm to learn.

It's like a while back I trained myself up on GWT because in my mind it was the future of reusability.

Sure it was Java based and everyone hates Java these days I guess, or at least hating Java is a meme. But the entire concept and value was that you write everything as reusable components.

Then all you really needed to do was choose your compile targets and the compiler would do the rest, generating cross-browser / device versions of your application code as needed.

I can see now what the OP means and honestly from my point of view the post-XHTML / DTD / XSD diaspora is circling back around to trying to find standard ways to separate data from presentation.

I think I get it now, thank you.

> I find it hilarious that they put a dark mode toggle in the corner (why would I want this on a per-website basis?)

They detect your OS preference and display their light/dark style automatically based on that [1]. The toggle is just there if you wanna switch it manually. My Mac is in dark mode but I usually prefer reading docs in light mode, so that toggle is handy.

Agree that it should update the background of the examples tho. Probably just a bug or something they didn't think about.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

A lot of the components don't appear to work? Checkboxes, radios, sliders.

There are also weird extra spaces and alignment issues on things like basic links or the list numbers in the tab demo.

Bit of a shame

This is on Firefox on Android.

Okay I think I get it:

1. Define elements in script by extending htmlelement

2. Follow the allowed structure in the DOM so that the custom elements don't break / conflict with anything

3. Use CSS to make the custom element look nice.

Then, basically what we have is:

1. A class-based way to attach event listeners in a standard interface (which is nice)

2. what we always had to do anyway (unless framework forces using JS to inject HTML at runtime)

3. what we always had to do anyway

4. Can't use custom events anymore... Encapsulation fTW.

But now that brings us to a situation where, essentially, it comes down to which htmlelement classes take precedence in our dependency hierarchy. Some libraries are probably compatible but you can't guarantee it because there's no explicit package dependencies between different implementations, so if you choose two different component libraries you may end up with unexpected behaviours and bugs.

So if I were to build a component library that is "compatible" with all major component libraries, essentially what I'd have to build is a shit-ton of "mappings" and exceptions that define an order of precedence of which component variants my library should interact with or cede to? I don't really like the idea of "just magically working with incompatible libraries" right?

Does that seem about right?

I think I learned something new and fundamental today, and the overall approach makes sense if you pick a single library to build your application but I can't see it having any realistic value if you're to try and jimmy it into existing products, in fact I can see that being an extremely expensive exercise and potentially adding a load of overheads to maintain and configure.

Also I can see now why no one really answered the question about ARIA tab orders and accessibility, it's not the job of these libraries.

I'm not a very smart person, thanks again to you and everyone else jumping on my thread to take the time to explain :)

In theory you wouldn't worry about idiosyncrasies of specific component libraries if they are based on web components because they would provide only a single interface: properties go in (as in customElement.myCustomProp = ), events go out (as in customElement.attachEventListener(, (e) => )).

This is definitely true for "dumb" components aka leaf components such as labels, footers, links, basic inputs. However, since you need more (for example, data-binding and reactivity), this may become a question of interoperability, and I don't really know how that plays out in the real world.

> I'm not a very smart person, thanks again to you and everyone else jumping on my thread to take the time to explain :

No stupid questions, right? :) And the whole web components discussion is extremely muddied. Mostly because people expect you to already know what they are about, and talk about and use libraries on top of them: lit-html, stencil etc.