Re: [WICG/webcomponents] [open-stylable] Collection of user stories (Issue #1052)

All,

I've spent some time going through the use cases and trying to organize and categorize them in a way that might be useful in discussions with browser implementors. I tried to analyze and combine similar use cases into representative use cases and categories. I've also disregarded any use cases that I thought were pointing too directly at a solution like "I want to use css layers to do ...." or "I want to use @sheet to push styles into a component". Personally, I don't think use cases should pre-dispose solutions, only describe problems that are currently difficult to implement in today's world. The solutions discussions come after the use cases, imo.

Here's what I have come up with.



### Global CSS Approach/Framework / Reset

- As a web page author I want my page reset stylesheets to work in my shadow tree so that buttons in the shadow tree match buttons outside the shadow tree.
- As a website author, I want to structure my CSS however works best for my project and make as little changes as possible to achieve compatibility with the web components I want to or may in the future want to use. When changes have to be made, they should be generic and semantic and not specific to the components.
- As a component library author, I want to distribute a single shared .css file that styles all my components. I want my consumers to be able to include this stylesheet once on the page and have it be available across all shadow-roots (and nested shadow-roots) in all components from my library without needing JS or adoptedStylesheets
- As a "UserCSS" user I want to be able to affect all elements in displayed pages including shadow DOM with my recipes.


### Building apps completely from web components

- "As a website author, I want to use shadow DOM for my own components (that I author and consume myself). I want to use my existing CSS system, including any global resets, utility classes, and hand-rolled scoped classes. Crucially, I want these styles to be usable in DSD without causing FOUC."
- “I’m building a web app. I’ve already written the styles for various user interface elements (e.g. buttons, form controls). Now I have a larger composition that I need to repeat throughout the app which includes a number of these elements (e.g. a modal dialog that includes a few buttons) and I would like to use the shadow DOM for this. Slots are the wrong tool for the job since the component doesn’t need the composition they provide. Parts are equally awkward since they require me to rewrite my CSS. I would love to write the styles for these elements once, then allow the web components in my app use them (ideally without requiring my entire stylesheet also be applied to the shadow root).”
- As a website author / component user, I want components to follow the surrounding theme and not end up with, e.g., a dark-mode contact form in a light-mode website or vice versa.
- As a component (or library) author, I have some nested components. I would like to share some common resets and styles at the native element level (buttons, inputs, etc) across all of my sub-components (some of which perhaps are not mine, but are also 'open' to styling, while more generally working with abstractions - shadows/parts.


### Web components in “hostile” environments

- As a part of our WordPress plugin, we have a public facing widget that can be embedded into any page or post. We’re using the shadow DOM since to be frank WordPress is quite hostile: it’s impossible to predict the concoction of different themes and plugins or even custom CSS from the site owner. Our widget is fairly complex — it’s almost an entire app. WordPress being Wordpress, we have users who want the level of customization that they’re used to. Shadow parts are our only option, however, it’s a lot of work to not only add generic parts (e.g. button, etc.) to everything, but also to add context to those parts (e.g. confirm-button; primary-nav-current-nav-link?). It would be great to allow the site owner allow some of their styles in, perhaps their theme’s stylesheet, perhaps maybe just some specific styles for the widget. In any case, allowing all of the document styles in likely won’t serve the user and defeats our purpose in using the shadow DOM.

### Headless Components

- "As a component author, I want to build unstyled components that only manage behavior. I want to give my consumers full control and achieve maximum compatibility with their existing styling solutions. I am ok with the tradeoff that DOM changes can break consumer's styles."
- As a component author, I want to build components that default to inheriting all the outside styles, but allow users to narrow down what styles get inherited. I want to define my own API for this to have proper control over how much flexibility I want to give to my users.
- As a web component author, I want to write a web component that transforms markdown into HTML and brings in page styles, so that transformed markdown is styled from page styles without the web component user having to do anything.


### DSD - Out of order streaming
- As an application author, I want to use DSD to achieve out of order streaming without the need for JS to replace content when it arrives without also eliminating the use of global styling since DSD out of order streaming requires a shadowRoot on the <body> element.

### DSD - reduce repetitive styles
- As a dev using DSD for my application (either a page author writing DSD, or a component author providing/compiling to DSD), I want to reduce the repetition of styles for each instance of a DSD component on a page by using a single global stylesheet that can be imported/declared once and apply to all DSD instances of components without FOUC.


Open Questions / Use Cases / Features of a solution?
- Priority? If external styles are applied to shadow roots, is there just a single cascade pass for all styles on a page, in which shadow roots are included? If there are multiple cascade passes, what is the order of cascading? Is there a mechanism for ordering the cascade passes so that either the component’s internal shadow root styles “win” or the external styles “win”?
- Filtering parts of the shadow DOM that external styles apply to?
  - As a component author, I want to inherit the outside styles not into the entire shadow-dom, but into a scope to make sure outside styles cannot mess with certain parts of my component like a top level grid wrapper. For example when populating the shadow-dom with my own HTML, then inserting generated HTML into that structure.
- Polyfillable
    - There has been a request that any potential solutions for open-stylable components be polysyllable for testing and gradual adoption
- External page styles that ONLY affect shadow trees and DO NOT affect the Light DOM?
    * As a shadow tree or web component user, I want to provide some page styles outside a shadow tree that won't affect the page at all but can be inherited into the shadow tree, so that I can write page styles that only affect shadow trees.
- Component Crowbar - my own personal terminology :)
  - As a page author/WC user, I would like to have a way to say, as Chris Coyier put it, "I know what I'm doing" and go wild overwriting anything I want (and not be at the mercy of the WC author).
  - As a web page author I want to pass some page styles into a web component from another entity whose internal styles I do not control, so that the web component will use those styles.
  
  
  
If I've missed (or disregarded) your use case, and you feel it important to include and appreciably different from the ones captured above, I'm happy to amend the list. If you can phrase your use case in the "As a __, I want ___ so that ___ " format without pre-supposing a solution/approach, I'll add.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1052#issuecomment-2087900638
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1052/2087900638@github.com>