feature request: shadow root stylesheets

[dakom]

this was discussed on Discord and @Pauan suggested something like the following syntax:

static STYLE1: Lazy<Stylesheet> = Lazy::new(|| stylesheet!("div.bar", {
    .style(...)
}));

html!("div", {
    .shadow_root!(ShadowRootMode::Open, {
        .stylesheet(&*STYLE1)
        .children(&mut [ ... ])
    })
})

The Stylesheet here should somehow use Constructable Stylesheet Objects - such that if the above html! were called 100 times to add instances of this component to a page, they should all share the same static stylesheet.

Even though the stylesheet is static, its inner contents can be changed and so the above will support .style_signal()

It's likely that these stylesheets, scoped to a shadow root, will often define many rules at once - so it would be more efficient and convenient to have a wrapper that collects them all.

This wrapper could be called stylesheets!, or perhaps, stylesheet! becomes the wrapper and each rule uses a rule! macro. If going with the latter, the above could look like:

static STYLE1: Lazy<Stylesheet> = Lazy::new(|| stylesheet!(&[
    rule!("div.bar", {
      .style(...)
    }),
    rule!("ul > li + li", {
      .style_signal(...)
    })
]));

html!("div", {
    .shadow_root!(ShadowRootMode::Open, {
        .stylesheet(&*STYLE1)
        .children(&mut [ ... ])
    })
})

[dakom]

A couple more scattered thoughts for consideration:

1. .stylesheet_signal_vec() / .stylesheet_signal() - could be useful, for example to implement responsive design on a per-stylesheet basis rather than per-class. This might be even more powerful than media queries in some cases, e.g. the signal could be driven from a ResizeObserver. (implementation note: it seems that adding/removing stylesheets requires re-assigning the array, see discussion here: Instead of assignable FrozenArray, use add / remove WICG/construct-stylesheets#45)

2. include_stylesheet!() - to just include a static .css file. not as powerful as being able to use signals (or real Rust variables, etc.), but I think it's worthwhile to let people choose this approach and would then allow dominator shadow-root components to use PostCSS/SASS/etc.

3. There's this polyfill for constructable stylesheets... I haven't tried it yet, but if it works as advertised I think it's fair for dominator to just use the native API and say users must use the polyfill if they want cross-browser support today: https://github.com/calebdwilliams/construct-style-sheets