webcomponents / custom-elements-manifest

A file format for describing custom elements
BSD 3-Clause "New" or "Revised" License
370 stars 27 forks source link

Needed styles for elements #116

Open jogibear9988 opened 1 year ago

jogibear9988 commented 1 year ago

For example, shoelace elements need a stylesheet, so they display something. Could we create a way to link to the needed styles wich should be loaded for a component?

jogibear9988 commented 1 year ago

see here with the integrated style they work: https://node-projects.github.io/web-component-designer-demo/index.html?loadAllImports&npm=@shoelace-style/shoelace&html=%3Clink%20rel=%22stylesheet%22%20href=%22https://cdn.jsdelivr.net/npm/@shoelace-style/shoelace@2.0.0/dist/themes/light.css%22%20/%3E

justinfagnani commented 6 months ago

I'm a bit unsure of this one personally. Can we specify this in a meaningful way?

I see you proposed adding stylsheets to CustomElementDeclaration in #117, but what would the contents be? An absolute URL? A path within the package?

And what exactly would the field mean? That the stylesheet has to be included in the main page, or in a shadow root? The answer depends on if the stylesheet only defines inheritable properties on :root or if it has important selectors.

I feel like this is information that's best for unstructured documentation for the moment. I realize you have a tool and probably want to add the stylesheet automatically, but we'd need to specify this in a way that isn't too specific to how Shoelace does things at the moment. Other libraries may do something differently, and Shoelace/Web Awesome might do something different in the future.

cc @claviska and @KonnorRogers because this automated use is an interesting case.

KonnorRogers commented 6 months ago

I'm a bit unsure of this one personally. Can we specify this in a meaningful way?

I see you proposed adding stylsheets to CustomElementDeclaration in #117, but what would the contents be? An absolute URL? A path within the package?

And what exactly would the field mean? That the stylesheet has to be included in the main page, or in a shadow root? The answer depends on if the stylesheet only defines inheritable properties on :root or if it has important selectors.

I feel like this is information that's best for unstructured documentation for the moment. I realize you have a tool and probably want to add the stylesheet automatically, but we'd need to specify this in a way that isn't too specific to how Shoelace does things at the moment. Other libraries may do something differently, and Shoelace/Web Awesome might do something different in the future.

cc @claviska and @KonnorRogers because this automated use is an interesting case.

Yea it doesn't seem to fit in with the overall format of custom-elements.json

We use an external stylesheet for a couple of utilities and mainly for CSS vars / themeing. Stylesheets are kind of optional tbh, as the components should still function without them, they just wont have proper tokens / styling. I don't have a good answer here, but maybe optionalStylesheets makes sense?

As for contents, it could be a number of things which is tricky, it could be a package like Open Props , it could be a URL, or a local path.

I think unstructured makes sense to me, since it seems "external" to the elements themselves, but 🤷‍♂️

EDIT:

I guess the trouble here is if you look at something like Enhance.dev or WebC , the external stylesheet can actually be really important because IIRC they "scoop" all of the <style> tags in their templates and create stylesheets from them (not 100% on that , but im pretty sure its how they work)

claviska commented 6 months ago

In a perfect world, theme stylesheets would be optional and we'd use custom property fallbacks in every component for a basic, functional appearance. Alas, that's cumbersome in the code and it creates competition with the default theme. Not to mention I don't think many people would want a barebones component library they have to restyle completely themselves — that's why we provide a simple, clean look with the default theme, which is technically optional.

But even if we used fallbacks, the library would have to use primitive color values (kinda tough to maintain across dozens of components) or it would need to include a base set of design tokens for consistency (at which point we're competing with our own theme's tokens).

For this to be useful, we'd have to identify the many ways stylesheets are and can be used in custom elements and account for them. I suspect a "recommended" property would be useful for Shoelace in its current form, if only for tooling to help users install it.