Re: [csswg-drafts] [css-scoping] explicit `inherit` values for non-inherited properties give unexpected results inside shadow DOM transformations such as <details> (#8184)

> We can change things to fix your case, but only by breaking other cases.

Of course I can understand, if this is the case for a particular suggestion, then it is no good.

But specifically, how do my suggestions break other use cases? @Loirooriol pointed out [one issue above](https://github.com/w3c/csswg-drafts/issues/8184#issuecomment-1338244423) and I [followed this up](https://github.com/w3c/csswg-drafts/issues/8184#issuecomment-1339426335) with a tweak of the suggestion to address it. That is how I imagined the discussion would proceed, by iterating on successive ideas.

Instead however, most of the rest of the previous comments have been to just deny there is a problem in the first place, which IMO is not constructive.

I can also understand if this issue is treated as low-priority if there are lots of other things to do by this team. But in this case the appropriate thing to do is to comment as such, say you have no time, mark the issue as low-priority, but leave it open, and not deny there is a problem.

> Another idea that might fix it is to make explicit inherit values on non-inherited properties behave differently from those on inherited properties (in terms of shadow DOM). This would make the presence or absence of a shadow dom for an element less visible.

Yes, this is similar to my (3) above except we allow the user to explicitly select which option they want.

We can split the thinking of the solution into two parts, the **mechanism** vs the **exposed interface**. As I see it there are 2 possible mechanisms:

1. support attaching properties to the shadow root so that it can inherit properties from the main tree, then its children can inherit these properties from it, fixing this issue. this is currently not possible.
2. allow the children to inherit from their original parent, instead of the new parent in the shadow root, this is currently not possible either.

Either of these two mechanisms will fix the issue. There is a third option i.e. redefine `<details>` not to use shadow DOM ( [(2) above](https://github.com/w3c/csswg-drafts/issues/8184#issuecomment-1339402598)) but I guess this will be too disruptive, and I imagine there's not many other alternatives.

For mechanism #1, the natural interface is to add a selector to allow the user/webdev to actually select the shadow root, currently there is no interface to do this. This was my original suggestion (the very first title of this bug report) as well as a tweaked suggestion in [(1) above](https://github.com/w3c/csswg-drafts/issues/8184#issuecomment-1339402598).

For mechanism #2, there are a few options for interfaces, either implicit (my [(3) above](https://github.com/w3c/csswg-drafts/issues/8184#issuecomment-1339426335), or @dbaron's idea), or even explicit, e.g.

a. via a `inherit-shadow` value, which IMO is clearest (users have to explicitly opt into it, solving the current problem where `<details>` forces unrequested encapsulation), but breaks backwards compatibility of the current behaviour, or
b. via a `inherit-declared` value, which retains the current behaviour, giving users the ability to opt-out (but the current problem is that most users are unaware that `<details>` needs to be opted-out-of in this way)

Again, I would appreciate if the discussion could focus on downsides of any of these suggestions, rather than just flat-out denying that the problem exists. (And re-open the issue, ofc.)


-- 
GitHub Notification of comment by infinity0
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8184#issuecomment-1341001965 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 7 December 2022 13:54:46 UTC