- From: Mario Hamann <notifications@github.com>
- Date: Wed, 20 Dec 2023 08:20:42 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/909/1864768342@github.com>
I really enjoy the discussion here, and really want to thank @justinfagnani for bringing this on the table. All the perspectives here are really insightful. I'd like to share some real-life problems I face in various projects: 1. `parts` are often used to make components more flexible while reducing maintenance effort. For design system teams, this is super critical, as it's just not possible to have every possible behavior and need in mind. **Still, parts are often not very intuitive to use**, as noted for example in [Shoelace discussions summarized in this comment](https://github.com/shoelace-style/shoelace/discussions/1743#discussioncomment-7684341) - this leads to developers having to provide more CSS variables, which isn't bad per se, but they really need to be thought through and it takes a lot of implementation effort. 2. `parts` start to cause real problems when the components using them are themselves in components that have a shadowDOM. There is `exportparts`, but this leads to even deeper overhead. In one design system project, we're using `parts` everywhere, but to make use of them, a team using our library had to add their **custom overrides in a stylesheet in LightDOM + inject the same stylesheet into each of their own components**. 3. Styling web components from the LightDOM **would be so great for projects that need to inject the styles via JS** when they use shared classes (Bootstrap etc.), utility classes (TailwindCSS etc., what we use in one WC project) or if they follow a white-label approach like [Lion Web Components](https://lion-web.netlify.app), which is just not usable without extending it [via JS](https://lion-web.netlify.app/guides/how-to/get-started/#extend-a-web-component). Me and my teams are convinced of web components, and especially of using them with named slots - but so many problems come just from styling and forced encapsulation. All before-mentioned cases would be a no-brainer if `open-stylable` would be available. Instead we're either dropping in more CSS (CSS variables, double injecting stylesheets), more HTML (`exportparts`, doubling styles in the DOM to prevent FOUC when using DSD) or even more JS (style injecting while extending). I would just love to enable more, by writing less. :) And I'm convinced, that the adoption of web components could be grown a lot, if `open-stylable` would be available. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/909#issuecomment-1864768342 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/909/1864768342@github.com>
Received on Wednesday, 20 December 2023 16:20:48 UTC