Doug Gibson

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.

This was my first thought as well. Using a CSS API for customizing components has so many benefits. I've been planning to write an article on it but never got around to it.

Very rarely. Stencil does support required props, but in most cases I find setting a default value that can be overridden makes more sense.

Example: I am using display flex on a button to make text and icons align vertically centered. If I specify a gap, this also works as if the text node was a proper flex child. I thought the text would have to be in a span for that to work.

Did text nodes always inherit a flexbox or css grid item context or was that added later? I swear I thought they did not work properly when I first started using flex and grid several years ago.

In the css/scss file for the component.

Stencil uses jsdocs comment and @prop for css variables. Is that non standard and just their own convention?

I've always left validation as an application concern. My components generally accept an error prop (Boolean) doubling as a css hook and error message.

Scoped*

Never. I feel like this is such an overblown concern. If you're making a design system, this is far less likely than when making generic components. I don't even use scooped components, just nest the css inside the custom element selector for specificity.

I've always worked in the light dom for accessibility reasons. Previous design system rendered the input/form control. Current one (still all light dom), I decided to slot the input and I like it better for many reasons. No need to recreate the entire API for a native form control.