Re: [csswg-drafts] [css-cascade-6] Strong vs weak scoping proximity (#6790)

The CSS Working Group just discussed `[css-cascade-6] Strong vs weak scoping proximity`, and agreed to the following:

* `RESOLVED: WG leans towards weak proximity at this time, and recommends this direction for prototyping to get more feedback`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: [css-cascade-6] Strong vs weak scoping proximity<br>
&lt;fantasai> TabAtkins: Right now, scoping spec cascade-6 is intentionally ambiguous on exactly where scoping sits in cascade<br>
&lt;fantasai> TabAtkins: offers two options: less strong that specificity (just stronger than order of appearance) and another that's stronger that specificity<br>
&lt;fantasai> TabAtkins: Given it's currently ambiguous, makes difficult to do test implementation<br>
&lt;fantasai> TabAtkins: Would like to do a test implementation, and prefer weak scoping<br>
&lt;fantasai> TabAtkins: I've argued in the thread about why the weaker scoping is the better way to go, going for strong would be a mistake imho and make things less usable for authors<br>
&lt;fantasai> TabAtkins: but for the moment, I think we should at least currently resolve to go with weak scoping<br>
&lt;fantasai> TabAtkins: and revisit later<br>
&lt;fantasai> TabAtkins: fantasai said in issue, she believes that related features have been released to make a decision<br>
&lt;Rossen_> q<br>
&lt;fantasai> TabAtkins: that would delay scoping feature by a year or two<br>
&lt;fantasai> TabAtkins: and I don't think the input we'd get would be worth that level of delay<br>
&lt;Rossen_> ack fantasai<br>
&lt;drott> fantasai: no problem if chrome wants to go ahead and do prototyping of weak scoping<br>
&lt;drott> fantasi: exactly how it works will be fundamental to how css is used<br>
&lt;drott> fantasai: need to be diligent and figuring it out<br>
&lt;drott> fantasai: 6 months timeframe is reasonable for that<br>
&lt;TabAtkins> (I really, *strongly* think that going with "strong" scoping would be making a serious mess, but I argued that in volume in the thread already.)<br>
&lt;drott> fantasai: scoping feature is desired and useful<br>
&lt;Rossen_> +1 to fantasai point ^<br>
&lt;fremy> Is this discussed in any GitHub issue?<br>
&lt;drott> fantasai: more important to get it right, first time around - waiting 6months to a year is reasonable for the proprotion of this feature<br>
&lt;TabAtkins> fremy: Yes, in the github issue linked in the agenda and right here, a few lines up<br>
&lt;drott> fantasai: i suggest to resolve with sth like: "the WG is leaning towards weak proximity and thinks it's the right way for prototyping"<br>
&lt;fantasai> fantasai: but keep the issue open for discussion<br>
&lt;TabAtkins> (oh, it *hasn't* been linked)<br>
&lt;miriam> +1<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/6790<br>
&lt;fantasai> RESOLVED: WG leans towards weak proximity at this time, and recommends this direction for prototyping to get more feedback<br>
&lt;fremy> It hadn't been linked indeed; this is why I was confused about it ^_^<br>
</details>


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


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

Received on Wednesday, 10 November 2021 18:01:48 UTC