[WIP] Optimize Styles

[jonathantneal]

This PR reduces the styles needed for spicy sections, as well as removes the need for an additional LightDOM stylesheet.

However, this is a WIP because one style is not working in Safari (v15.3 at the time of testing):

Proposed style rule within a ShadowDOM stylesheet:

::slotted([affordance="collapse"])::before {}

Current style rule within a LightDOM stylesheet:

:where(spicy-sections > [affordance*="collapse"])::before {}

Related (I think) bug report from 2017:

• Bug 178237: Support ::before and ::after pseudo elements after ::slotted.

[bkardell]

So, this is sort of dealing with 2 things - one, changing the internals use use divs rather than non-standard internal elements and the other trying to get rid of the idea of injecting a light dom stylesheet.

I'd like to treat these a little separately.

After discussing with @jonathantneal a little, I think he has a point that maybe divs are better here and would be really happy to merge a PR that changed just that if it passed all the tests and keeps the demos and known uses working.

On the trying to avoid the light dom stylesheet, I'm less sure. As jon noted, it doesn't work in Safari atm so we can't merge as is - but it would be interesting to discuss a bit the implications of the two choices if were addressed in the next release, and which is more desirable. To be honest, I'm not entirely sure. I suppose the one good thing is that because we use good PE, no one should be left with information loss or a completely unusable or misleading interface.

[bkardell]

Following up after chasing down the safari discrepancy, the relevant wpt is https://wpt.fyi/results/css/css-scoping/slotted-with-pseudo-element.html?label=master&label=experimental&aligned and that reports all 4 subtests pass in TP, so I expect we'll get it working in the next release of safari which at least adds some clarity to the discussion. My questions are:

• This would create a hole for users who can't upgrade (it's hard to say we have none now, I'd love to check). They will, of course, still get content, but I guess that's a thing we should consider
• Is it 'wrong' or somehow bad to have a light dom stylesheet add like we currently do? I think almost every component I've ever made had one - The way I've always thought of this is that there is a default UA stylesheet and we'd really like to potentially have some entries in there for where it is not managing internals. In other words, I expect those rules (or their equivalents) would go in the UA stylesheet. Part of the reason for asking about this is that it makes me wonder if we have a kind of a gap in needs at the platform level here.

[jonathantneal]

Thanks for the review. Tho it’s a 'work in progress', here’s the background:

This PR came out of a code review. I was curious about some shadow CSS. There is a :root rule that does not seem to apply. There is a :host([hidden]) rule that seems redundant and will not overrule a light rule (even earlier in the cascade) for [hidden]. Out of that came this PR.

Removing the lightdom CSS was initially a side-effect. I removed it because the styles all felt better organized together. It wasn't until I saw the missing accordion UI in Safari that I began to think about why or why not I should have a lightdom stylesheet.

This is also why the PR changes <tab-list> to <div>. I wasn’t even thinking about side-effects. I just thought "oh there’s an element selector that might do better as a [part] selector, so I should use that", which got me thinking "well, why is there a <tab-list> element to begin with? Maybe there’s more to understand." In the end, I concluded it was not necessary, and the side-effect of someone defining their own behavior for <tab-list> felt more fragile than a <div>.

Now that I’ve found a way to mostly remove the lightdom stylesheet, I do like the styles being self-contained, not tied to any tag name, and I’d love to find a way to allow it to keep working. I like components that are self-contained, at least in the HTML/DOM sense, because I think relying on external factors of the DOM increases the surface area for incompatibility. I plan to make more time for this 'work in progress'. :)

[jonathantneal]

Closing this in favor of smaller PRs