Sentiment poll and small feedback thread

[bkardell]

Please leave an emoji reaction to this comment to let me know how you feel about this repo's solution as a shape of solving some use cases for "open-stylable" Shadow Roots

Feel free to just drop comments small comments here as well if you need just a little bit more but don't feel like it's worth an issue of its own.

[sorvell]

It feels like an elegant solution, but I have a few concerns:

• legacy stylesheets can't be applied without modification
• tool produced stylesheets (e.g. tailwind) have to opt-in to it
• for those struggling with css, adds to cognitive load of using shadow DOM

[ox-harris]

I think that people end up with the Shadow DOM (and thus the current problem case) because there's no way to write basic modular markup and style those modular structures.

In my case, I often simply want a form of "namespacing" for plain, light DOM structures and selectors. (For which people invented class naming conventions like BEM, I guess.) I wrote about it here: How do you make components?

<div>

  <h2 id="foo">will be green</h2>

  <div namespace>
    <h3 id="foo">will be red</h3>
  </div>

  <style>
    /* to all #foo */
    #foo { color: red; }
    /* to #foo in current (global) namespace */
    #~foo { color: green; }
  </style>

</div>

It's part of a bigger story I developed as OOHTML and it goes with a JavaScript implementation that lets us play with the idea.

[matthewp]

My feedback:

1. I like the general shape of the API. Using media queries is an interesting way to do this. I've also seen other ideas like using @layer. I'm not sure which one is better than the other, I don't have any opinions on that.
2. I can't use a polyfill that requires JavaScript because that will lead to FOUC (flash of unstyled content) with DSD (declarative shadow DOM). I consider this a hard-requirement for me, so I simply don't use shadow DOM for non-enhancement use-cases until this is fixed at the platform level. So I can't give feedback on the JS library for this reason.
3. Some concern that Apple will not like this proposal for 2 reasons: a. They have said that they cannot have selectors that are cross-root. Does this proposal introduce this problem? b. In the past Apple has objected to any proposal that breaks hard encapsulation. I think this proposal does so, as the component author does not opt-in to styles coming into the SD. Have you spoken to Apple representatives and gotten their thumbs up on this idea?

[bkardell]

Just want to reply to a few things in case there's confusion

1. I like the general shape of the API. Using media queries is an interesting way to do this. I've also seen other ideas like using @layer. I'm not sure which one is better than the other, I don't have any opinions on that.

A real proposal (probably) wouldn't use @media, I mentioned this in my blog post and again in this episode of our podcast (jump to about 42minutes in or search for "How would you describe this, Mia?" if you prefer the transcript). The idea is simply that it would be an at rule, and you probably need to be able to express in that rule which things it applies to (ie, the page, the roots, certain roots, etc)

2. I can't use a polyfill that requires JavaScript because that will lead to FOUC (flash of unstyled content) with DSD (declarative shadow DOM). I consider this a hard-requirement for me, so I simply don't use shadow DOM for non-enhancement use-cases until this is fixed at the platform level. So I can't give feedback on the JS library for this reason.

This kind of feedback is why i created this sentiment poll. I understand that not everyone can actually use it. An emjoi isn't accurate, but feedback, but they're easy enough.

3. Some concern that Apple will not like this proposal for 2 reasons: a. They have said that they cannot have selectors that are cross-root. Does this proposal introduce this problem? b. In the past Apple has objected to any proposal that breaks hard encapsulation. I think this proposal does so, as the component author does not opt-in to styles coming into the SD. Have you spoken to Apple representatives and gotten their thumbs up on this idea?

I haven't talked to anyone no, but it's not a proposal. The last thing wasn't a proposal either. They are us trying to figure out what we want, and what is going to work for developers. It might be one of these, or something else. If people have this problem, and they can use this, then it should help them and there is nothing to object to because it is literally how things already work. I can say that if we approach the problem with some data showing that this is actually a useful and necessary kind of thing to a lot of people, this is just an easier discussion than if we are speculating.

[Westbrook]

In this thread: https://mastodon.social/@westbrook/111745107269022735 and this accidentally detached thread: https://mastodon.social/@westbrook/111745113717336060 I attempted to gather a handful of user stories that I think apply to this space. Is the lack of response a judgment of the problem space? Likely not. Is it a judgment of my "brand reach"? Likely so. There are a million things that could be done in this space, but I feel you'd have a hard time finding one that serves enough use cases for it to get traction here.

As far as the user stories, I think that this takes a run at:

As a custom element consumer, I want to be able to take full control of the visual delivery of the elements that I consume so that I can have them delivered exactly as I’d like.

and

As a custom element consumer, I want to style the contents of a shadow root with “natural selectors” instead of CSS Custom Properties and CSS Parts so that I don’t need to learn additional CSS syntax to style the content therein.

and

As a custom element consumer, I want my styles (without directly addressing specific content) to apply to the contents of the elements I consume so that CSS that I’ve already written can apply to the shadow root content.

However, the more I think about them the more I'm struck by their being a theoretical extension of

As an application author, I want to structure my content with <slot>s without being bound to the encapsulation realities of shadow DOM so I can reduce the HTML that I repeat but still have all of the styles I have already written apply to it.

Wherein in all likelihood the developer doesn't actually want a "component" with Shadow DOM.

By the time you get to this space, it feels much more like the developer is grasping at the closest things to "templating" in the platform and then angry about the platform not actually having templating and then venting about that in the form of saying that Shadow DOM should have an expanded feature set. Simply stated:

Do "component" consumers want "open-stylable shadow roots" or do they simply want packageable templating?

Maybe there is a world wherein one is the other and both, but it seems like we're stretching for APIs because "this is all we have" rather than driving for the actual APIs we want here. I love Shadow DOM, love writing elements with Shadow DOM, and benefit greatly from the way it separates the concerns of my applications, and most of the reasons begin to fall apart when allowing a consumer to address styles and functionality against those DOM trees beyond my blessing. Would my work have more consumers were this sort of approach possible? Maybe. Would the added costs of maintaining a larger API surface balance that out? Likely not.

---

I do not think it directly serves any of the above use cases, but as I hear the conversations and possible paths to addressing the space go back and forth, I am quite interested in the ability to share/transport @layers. In that way, I wonder if in a non-Shadow DOM-centric manner the @layer spec has room to grow to a place wherein we could opt-in to applying an @layer in place of the user agent stylesheet, not just after the user agent. Possibly something that was sanitized to only element and platform attribute selectors. In that way, you could do something like:

@layer USER-AGENT-REPLACEMENT {
    input[type="button"] {
        background: blue;
    }
}

And, FINALLY have control over not just the same in third-party shadow roots, but also the ever-elusive:

<input type="file" />

Then app authors would have a path to cajoling the contents of shadow root to look a specific way, but the component author would still win when they apply DOM-tree local styles and no specific API (CSS Custom Properties or ::part()s) for consumers to explicitly customize that content.

[nolanlawson]

I tend to agree with @Westbrook's take. In general, I think that there are 2 use cases at odds here:

1. As a component author working on an enterprise-y B2B platform experience, I want to completely lock down my API surface so that my customers don't shoot themselves in the foot and complain when I break them by changing my internals (aka <video controls> use case)
2. As a component consumer working on a fast-paced B2C experience where I own the whole frontend, I want to add a shadow-using component and have it "just work" with my existing global styles (e.g. Bootstrap) with zero changes required from the stylesheet author

This proposal actively harms the first use case (by allowing consumers to override e.g. closed roots) and it doesn't help the second (since the stylesheet author needs to make changes). Maybe there is some other middle-ground use case that is served by it, but as Westbrook said, you probably just want templating or compile-time framework "slots" at that point. (At least then you would also get "scoped slots" [i.e. lists/virtual lists] to boot.)

BTW I really appreciate you taking the time to gather all these use cases and solutions together and to provoke the conversation! This is a devilish problem, and I don't think the solutions are obvious.

[bkardell]

@nolanlawson your 2nd bullet was, I agree, a potential issue. You can do that with half-light now

[bkardell]

@Westbrook I can't make you able to replace UA sheets, but I did introduce layering!