The major downside of :focus-visible is that it doesn't show up if you programmatically set focus to that element, which is one of the most important times you need a visible focus indicator.

Looks like they've pulled the pages down already too.

Is the code to this "design system" public somewhere like uswds?

I actually like the other one since it's more backward compatible without @property.

Amazing! I tried this on a coldfusion test page for my components that was showing a terrible fouc and it's much improved. I don't generally see it so bad on production sites but this is a nice snippet to have in my back pocket just in case.

And web components work pretty well with Angular out of the box last I checked.

And I completely agree with this. One of the best places I'd use the Shadow DOM is for the calendar/popover part of a date input/picker. The real issue is using Shadow DOM as the default without understanding all the limitations and issues it may cause.

Because we can't extend native elements, a custom element's host tag is usually an inert wrapper and the interactive element is rendered within, in the shadow DOM. ElementInternals patches its form participation, but still doesn't allow it to be labelled by a label outside it's shadow DOM.

One cannot easily create interactive elements that exist in the light DOM and only have parts in the Shadow DOM like you see for native form field implementations in the browser.

I think this is misleading. It's important to look at how they use shadow DOM as well. The fact that a select uses it is completely different than creating your own select component that is entirely in the Shadow DOM. I use shadow DOM very sparingly.

Devs should be included in it though. I see a lot of issues that come from design centric decisions that don't consider the native platform, including naming of things.

How long ago? I wrote one with aria-activedescendant and tested it (just recently) across all screen readers and browsers and platforms and it seemed to work fine in Safari.

Been there. I learned 2 things from this experience:

I really needed to up my attention to detail to reduce this because designers will notice all those things.

But also I needed a detailed spec sheet that spelled things out visually as well as proper requirements. A picture != requirements.

Me and my son at the concert

Volbeat in concert

Volbeat in concert

Volbeat in concert

Saw Volbeat for the first time in over a decade with my son last night at Jiffy Lube Live. Seats were great - front and center in the orchestra section behind the pit. They do an amazing job of creating headbanging riffs with catchy hooks and vocal melodies and the singing was spot-on.

I don't use shadow dom so my components set their public variables in :root. The part about not overriding them with selectors deeper than the host (wc selector) still applies because of how I write my css though. It took a while to fully work through and understand that part.

I think I may have it handled already with a @watch (this is stencil) on the value prop that sets the child selected states.

Honestly I haven't dealt with a form reset in quite a while. I'll have to consider the impacts on some of my components. Good point. I tend to slot the native controls so most just work. But there's always some like dropdowns...

I would use the attribute selector because unlike the native element, you would likely manage this prop like a state based on user interaction. Web components should be reactive to work with modern frameworks, so this behavior fits the paradigm better.

Maybe you're saying the same thing but I've seen some storybooks that have dozens of stories for a component, most of which are just a control toggle away.

In some cases I think the control is enough vs separate stories. If my button has 3 fills and 3 colors (conservatively), I don't really need 9 stories to represent them. I use individual stories when there's complexity or different implementation necessities (e.g., complex slotted content).

I have been using stencil for 7 years on 2 design systems/ 3 major releases. I've never written a component from scratch but it sounds horrible 😀.

I use stencil and it uses jsx, which I like. That and the polyfilled slots makes it hard to move to something else.

I didn't know you could use jsx with lit. Is that out of the box?

Sounds like you should check out stencil to build your components - it's the best of both worlds.

Has it? I don't think it did.

That solid foundation is a big investment, but hopefully worth it in the end.

I'll try to start up a new project and see what's up. I'm stuck on a previous version on my work project for reasons... You are doing a web components project, not stencil app, correct?

I've been in stencil-land for too long to notice. I have my own gripes there, but was just reading the FAST docs the other day and feel you there.

Identifying what's a web component from a pattern made up of web components isn't trivial. In my first design system, we made components that did too much or were overly complex. Only after supporting those did we realize how and why to focus on building blocks and reuse more.

Well played.