Re: [csswg-drafts] [css-conditional-5][css-nesting-1] Feature detection for nesting (#8399)

The CSS Working Group just discussed `[css-conditional-5][css-nesting-1] Feature detection for nesting`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> astearns: Something shipped in Chrome that's not quite what we want, but not clear on what we want<br>
&lt;fantasai> ... we should have had a good story before shipping anything<br>
&lt;fantasai> TabAtkins: I agree that this being parsable before shipping was ready was a mistake, but I don't think we can fix retroactively<br>
&lt;fantasai> ... don't think we should expose whether nesting is possible or not<br>
&lt;fantasai> astearns: we shouldn't have feature detection?<br>
&lt;fantasai> TabAtkins: we shouldn't add anything except selector detection, it'll just misfire on some versions of Chrome/Safari<br>
&lt;fantasai> plinss: wasn't there discussion of using &amp; in other places?<br>
&lt;matthieudubet> q+<br>
&lt;fantasai> TabAtkins: allowing it elsewhere, yes, but concurrent with Nesting being supported<br>
&lt;fantasai> plinss: is that guaranteed?<br>
&lt;fantasai> TabAtkins: In practice yes<br>
&lt;fantasai> plinss: but it's usable in another feature that's not dependent on Nesting<br>
&lt;fantasai> TabAtkins: only @scope, but it's also nesting rules ...<br>
&lt;emeyer> fantasai: That’s different from the nesting feature because @scope can only contain nesting rules<br>
&lt;fantasai> TabAtkins: don't think ti's a problem in practice<br>
&lt;astearns> ack matthieudubet<br>
&lt;fantasai> matthieudubet: for feature detection, should we try to give the proper result with a selector<br>
&lt;fantasai> s/selector/relative selector/<br>
&lt;fantasai> matthieudubet: should @supports be aware of the nesting stack?<br>
&lt;plinss> q+<br>
&lt;fantasai> matthieudubet: and always return true/false regardless of nesting stack?<br>
&lt;fantasai> TabAtkins: the latter. @supports shouldn't be aware of where it is in the stylesheet<br>
&lt;TabAtkins> .foo { @supports selector(&amp;) {...}}<br>
&lt;fantasai> TabAtkins: that should not give different results at the top level vs nested<br>
&lt;fremy> .foo { @supports selector(+a) {...}}<br>
&lt;fantasai> matthieudubet: &amp; is allowed both places, but relative selectors are allowed or not depending on whether nested<br>
&lt;fantasai> TabAtkins: I would prefer we don't make @supports context-sensitive<br>
&lt;fantasai> TabAtkins: right now we don't carry context into the querying APIs, and you can't express that in JS<br>
&lt;fantasai> ... so as much as possible I'd like to keep those consistent<br>
&lt;fantasai> matthieudubet: Right now for Safari, it does take context into account<br>
&lt;fantasai> ... so if the selector is not supported *there* it'll return false<br>
&lt;TabAtkins> CSS.supports()<br>
&lt;fantasai> TabAtkins: what about CSS.supports()?<br>
&lt;fantasai> TabAtkins: the JS API can't know the context<br>
&lt;fantasai> matthieudubet: That's what we do for the at-rules. For JS API, we do the same, so when you write a relative one will always say false<br>
&lt;fantasai> ... because not in a nested context<br>
&lt;fantasai> TabAtkins: that interpretation is novel, and not expressed in the spec right now<br>
&lt;fantasai> ... if we want to do that, can you raise an issue?<br>
&lt;fantasai> ... new issue, please; this is unrelated to the current issue<br>
&lt;fantasai> astearns: It's better to have specific issues on narrow problems<br>
&lt;astearns> ack plinss<br>
&lt;fantasai> ... so agree we should have a separate issue on whether relative selectors inside @supports are context-sensitive<br>
&lt;fantasai> plinss: Important that nesting be readily detectable at the top level<br>
&lt;fantasai> ... I have concerns about feature detection of one feature being dependent on another feature<br>
&lt;fantasai> ... just because we implemented &amp; and nesting together is cute, but not something to rely on<br>
&lt;emilio> But agreed nesting should def. be detectable in top-level and CSS.supports<br>
&lt;fantasai> fremy: If you want o feature-detect @scope, how do you do it?<br>
&lt;fantasai> plinss: how do I detect &amp; for @scope?<br>
&lt;fantasai> TabAtkins: at-supports API doesn't yet allow querying that sort of thing<br>
&lt;fantasai> plinss: we need reliable support detection for nesting, that works reliably for @import supports().<br>
&lt;fantasai> ... so &amp; detection is not good enough<br>
&lt;fantasai> TabAtkins: currently can only express as selector(&amp;), if you want something more specific need a new thing<br>
&lt;fantasai> plinss: that needs to ship with Nesting<br>
&lt;fantasai> astearns: any suggestion of what this might look like?<br>
&lt;fantasai> plinss: @nest?<br>
&lt;fantasai> fremy: how about we check whether &amp; is a valid property? That would be checking for nesting<br>
&lt;fantasai> ... e.g. @supports (&amp;) { ... }<br>
&lt;heycam> @supports rule(p { &amp; { } })<br>
&lt;fremy> @supports (&amp;{})<br>
&lt;bradk> @supports (nesting) { … }<br>
&lt;fantasai> TabAtkins: that's not valid property<br>
&lt;fantasai> TabAtkins: maybe not that bad given how messy the shipping has been with this feature, but in general want to avoid special casing<br>
&lt;fantasai> plinss: We might want a general feature() function for things that are hard to feature-detect<br>
&lt;emeyer> fantasai: I think Francois’s suggestion does fit the current syntax<br>
&lt;emeyer> …That said, if we do allow that, we’ll be allowing any kind of selector-based rule that can be nested to be in there<br>
&lt;emeyer> …Might be more parsing than we want, but not inconsistent<br>
&lt;fantasai> TabAtkins: Depends if you think of it as () parses a declaration or if () parses "stuff that could go in a declaration block"<br>
&lt;fantasai> plinss: Would be a problem if we allow selectors, since range of selectors is open-ended<br>
&lt;fantasai> ... what if we add a div property<br>
&lt;fantasai> fremy: same problem we have today already<br>
&lt;fantasai> fremy: To me, I think it's a nice extension, doesn't require a big change<br>
&lt;fantasai> ... not saying we have to do it, it's just an idea<br>
&lt;fantasai> TabAtkins: can we do the rest of the design work in the thread? we have 9 min on the most important isseu<br>
&lt;fantasai> astearns: Sounds to me that for this issue, we're going to retain the bare &amp; supports strategy in the spec, but might also add something that is a little more complex or specific?<br>
&lt;fantasai> TabAtkins: think so<br>
&lt;fantasai> astearns: so leave discussion here, don't need a resolution since selector(&amp;) aready works<br>
&lt;fantasai> ... but will leave this issue open for further discussion of supports functionality<br>
&lt;fantasai> plinss: I believe it's very important that we have a stable and reliable mechanism before we ship anything, can we agree on that<br>
&lt;fantasai> TabAtkins: I think it's a good idea, I'm not going to commit to it<br>
&lt;fantasai> plinss: I think shipping this whithout reliable feature detection is a huge mistake<br>
&lt;fantasai> +!<br>
&lt;fantasai> +1<br>
&lt;fantasai> astearns: agree with plinss<br>
&lt;emeyer> +1<br>
&lt;bradk> Me too<br>
&lt;fantasai> astearns: I think we should have another breakout on Nesting next week<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8399#issuecomment-1497825549 using your GitHub account


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

Received on Wednesday, 5 April 2023 16:55:33 UTC