The manifest is designed to be a standard interface for tools to learn about your components APIs regardless of how you author your components. JSDoc is often just a mechanism to add data to the manifest.

It is a bit more verbose, but it would be awesome to have editor validation for them so you can't assign a color to a size property.

I've been toying with the idea of setting up a CEM analyzer plugin to detect the CSS `@property` definitions so you wouldn't have to do this.

developer.mozilla.org/en-US/docs/W...

Are you using global styles or utility classes to style those?

Are you saying that tools like the Custom Elements Manifest fail to capture CSS-only primitives like CSS utility classes and design tokens? If so, I agree.

The CEM does a great job documenting the components, but I think there are opportunities to better capture the entire design system ecosystem.

Thank you!

If you use @webstorm.jetbrains.com, @intellijidea.com, @jetbrains-rider.bsky.social, @pycharm.dev, or any other JetBrains IDE and are using web components, check it out!

wc-toolkit.com/integrations...

I'm always down to talk about web components dev tooling!

wc-toolkit.com

SWTL?

I'm excited to try these out!

Great minds, I guess... 😂

wc-toolkit.com

You will likely still end up with layout shifts, right?

The autocomplete issue has been patched. 🤘

Check it out here:
wc-toolkit.com/integrations...

3. Again, these are global, so adding `--width: 50% !important;` on a parent element will cascade and can really mess up the styles in the child elements - espically since custom css properties traverse the shadow DOM.

2. These APIs are global in that they can be set anywhere, so developer tooling and types declare these globally (and usually only once per name), so there's either a million `--with` properties in your editor's autocomplete or one with an inaccurate description and expected type.