- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Mar 2023 17:59:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-cascade-6] Strong vs weak scoping proximity`. <details><summary>The full IRC log of that discussion</summary> <fremy> miriam: one of the main features of scoping is that it applies proximity to the cascade<br> <fremy> miriam: the closer from the scope root the element is, the higher the "priority"<br> <fremy> miriam: but does it beat specificity or not?<br> <fremy> miriam: there are use cases for both<br> <fremy> miriam: authors have more control over the css<br> <fremy> miriam: so specificity is more controllable<br> <fremy> miriam: but proximity is sometimes more valuable<br> <fremy> miriam: but I think in the end, weak is more useful<br> <fremy> miriam: (specificity>proximity)<br> <fremy> miriam: strong proximity puts proximity between two things that authors can control<br> <fremy> miriam: which might be confusing<br> <fremy> miriam: I think either one could work, so open to thoughts<br> <astearns> ack fantasai<br> <fremy> fantasai: my first thought is that I don't want to resolve this without leaverou and jen simmons on the call to think about this<br> <lea> I can join just for this, if it would help<br> <fremy> fantasai: weak scoping might be very weak though, because we remove implied :scope specificity<br> <fremy> fantasai: and I'm not sure this is useful that way<br> <fremy> fantasai: putting it between layers and specificity is actually nice in my opinion, as they can control things more<br> <fremy> fantasai: tweaking specifity is more constraining<br> <TabAtkins> q+<br> <fremy> fantasai: people should describe what they want to match<br> <fremy> fantasai: not have to think about how the sum of things should be to make things work<br> <fremy> fantasai: which is why I would maybe prefer people use layers for this<br> <astearns> ack dbaron<br> <fremy> dbaron: as a disclaimer, I never liked specificity because it's magical but not magical enough for what people want<br> <fantasai> s/they can control things more/authors can control things more explicitly/<br> <lea> I have expressed preference for strong scoping before<br> <fremy> dbaron: but if I understood correctly "weak proximity" is so weak that it might almost never be a factor<br> <astearns> ack TabAtkins<br> <fantasai> +1 to dbaron, I have the same concern<br> <fremy> dbaron: and in that case, it might be extra confusing because people would not think about ita at all<br> <lea> weak proximity makes this far less useful<br> <fantasai> s/very weak though/very weak, though, even weaker than nesting/<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/6790#issuecomment-959733391<br> <fremy> TabAtkins: interesting thoughts, I will think about it more<br> <fremy> TabAtkins: I still strongly think weak proximity is important<br> <dbaron> s/people would not think about ita at all/it would make a difference too rarely for people to think about it/<br> <fremy> TabAtkins: because if you just want to have selectors "leak further"<br> <fantasai> s/it might be extra confusing/weak proximity might be more confusing than no proximity at all/<br> <fremy> TabAtkins: and now, the added proximity would ruin that, you would have to move everything to layers<br> <fremy> TabAtkins: second argument, strong proximity would overrule everthing<br> <fremy> TabAtkins: like #id outside the scope would lose to * inside the scope<br> <fremy> TabAtkins: that sounds very bad to me<br> <dbaron> (I have sometimes thought that specificity should have been processed in pieces, based on proximity.)<br> <fremy> TabAtkins: third argument, authors can use layers already<br> <fantasai> s/that sounds very bad to me/that sounds very bad to me. It might be reasonable when specificities are close, but not when they are far apart/<br> <fremy> TabAtkins: so, if authors need proximity to win, they can weaken their selectors and use layers<br> <fremy> TabAtkins: so, adding another complex mechanism here is maybe too much<br> <astearns> ack fantasai<br> <fremy> TabAtkins: I would not mind no proximity or weak, but strong is a different beast<br> <fremy> fantasai: if the main use case is to put a floor on things, can we incorporate this in the nesting syntax somehow?<br> <fremy> fantasai: and not have proximity come into play at all?<br> <fremy> fantasai: I'm concerned that selectors inside the scope have no specificity boost at all<br> <miriam> q+<br> <fremy> fantasai: so, it will not do much for authors when they want to actually use scoping<br> <TabAtkins> q+ to argue for weak prox vs no prox<br> <fremy> fantasai: sometimes people want descendant selectors to deal with proximity<br> <astearns> ack miriam<br> <fremy> fantasai: but I don't like that nesting would be stronger than scoping here<br> <fremy> miriam: I think I would not call lower boundaries the only use case<br> <fremy> miriam: I still think weak proximity comes into play at the right time, in my opinion<br> <fremy> miriam: it comes into play when you are targeting multiple overlapping scopes<br> <fremy> miriam: and when they conflict, you want to closest one to win<br> <fremy> miriam: so I disagree it is not relevant if it's weak<br> <astearns> ack TabAtkins<br> <Zakim> TabAtkins, you wanted to argue for weak prox vs no prox<br> <fremy> miriam: in my opinion, it becomes relevant exactly when you want it<br> <fremy> TabAtkins: I was gonna say exactly this<br> <fremy> TabAtkins: but there might be a few cases where proximity could matter more<br> <fremy> TabAtkins: but when you want to style a component in two themes, weak proximity works perfectly<br> <fremy> TabAtkins: specificity would be identical, but you want proximity to win<br> <fremy> TabAtkins: in other cases, it's not clear that any mix of specificity/proximity that might be right or wrong is useful<br> <astearns> ack fantasai<br> <fremy> TabAtkins: adding wrong mechanisms means people have to fight against it<br> <fremy> TabAtkins: I would rather them use the mechanisms we already have<br> <fremy> fantasai: in the example of oriol , why is the system we have now better than that?<br> <fremy> TabAtkins: that would be a substentially different world<br> <fremy> TabAtkins: I'm not sure this thought experiment informs us that much<br> <fantasai> s/in the example of oriol/suppose that the descendant selector was originally defined to use proximity (as many people expect until they learn better)/<br> <fremy> fantasai: the reason it makes a difference is that the relationship between scoping and nesting becomes quite different<br> <fremy> fantasai: because nesting could have scoping effect<br> <fremy> fantasai: and that would become the default way things relate to each other<br> <fremy> fantasai: we should think about whether the way it works now is actually better<br> <fremy> fantasai: maybe proximity could be made easier to use in a different way<br> <fremy> fantasai: nesting compounds<br> <fremy> fantasai: and weak proximity + compounded specificity makes sense<br> <fremy> fantasai: but weak proximity + ignored specificity seems odd to me<br> <fremy> TabAtkins: I disagree, for the exact same example you just proposed<br> <fremy> TabAtkins: because how you end up in a particular theme doesn't matter<br> <fremy> TabAtkins: there could be many ways to target the theme switch<br> <fremy> TabAtkins: but that doesn't matter<br> <fremy> TabAtkins: what matters is when was the last theme switch<br> <fremy> TabAtkins: and any change to this would harm the use case<br> <fremy> fantasai: I see that what you say here make sense<br> <fremy> fantasai: but nested selectors will win because they are more specific<br> <fremy> fantasai: and I think that the interation is not the way that you would expect that to work<br> <fremy> fantasai: I would expect it to have a weaker effect<br> <fremy> TabAtkins: that argument applies to anything that affects specificity<br> <fremy> TabAtkins: like, it would turn off .class or #id<br> <fremy> TabAtkins: which we assume usually has a meaning<br> <fremy> TabAtkins: and if they want to change that, they can use the existing mechanisms<br> <fremy> TabAtkins: adding something that would work in all cases could be a slam dunk<br> <fremy> TabAtkins: but a mechanism that works sometimes and breaks other times is not useful in my opinion<br> <fremy> astearns: let's go back to the issue for now, and try to come up with examples<br> <fremy> astearns: layers could help you get closer<br> <fremy> fantasai: not really<br> <fremy> TabAtkins: yeah, almost<br> <fremy> astearns: ok, at least it's not clear to me how layers come into play<br> <fremy> astearns: we should look into this more<br> <fremy> fantasai: so we have three things, layers, specificity, flooring effect of scope rules<br> <fremy> fantasai: right now we combine them different between nesting and scope rules<br> <TabAtkins> issue here is that this has been a strong blocker on the feature for like, a year or more I think? and the only person maintaining the block with any feeling has been fantasai. this *must* be resolved before the spec can mature, and i'm not sure at this point we can fix this with more conversation.<br> <fremy> fantasai: and I think we want all three<br> <fremy> miriam: if we are taking this back to the issue<br> <fremy> miriam: one issue is that developers who used it<br> <fremy> miriam: they say that weak proximity has worked for them<br> <fremy> miriam: even when they had initially said they would prefer strong<br> <fremy> miriam: all examples I have seen where strong specificity were a bit artificial<br> <fremy> miriam: so I'm not sure how we will get to a resolution if we keep accepting theoretical concerns<br> <fremy> astearns: leaverou and fantasai both have opinions here, and we should probably keep working on resolving this<br> <fremy> TabAtkins: every time we bring this up, this is the resolution<br> <fremy> TabAtkins: what do we do if that doesn't happen<br> <fremy> TabAtkins: that's like the third time we have this resolution<br> <fremy> TabAtkins: nesting cannot apply proximity because it does not establish a containment relationship<br> <fremy> TabAtkins: you could do siblings, you could reverse the order by putting the ampersand in :has, etc...<br> <fremy> fantasai: but the default is descendant<br> <fremy> fantasai: what if the default would add proximity?<br> <fremy> TabAtkins: that would surprise everyone<br> <bramus> Also wouldn’t change that. Seems like a huge can of worms to open.<br> <fantasai> fremy: Nesting is supposed to work like preprocessors do, we're using the same syntax<br> <fantasai> fremy: If we change behavior it will confuse everyone<br> <fremy> miriam: proximity also requires a specific element that you can refer to<br> <fremy> miriam: which isn't the case for nesting<br> <fremy> TabAtkins: so, what do we do if we can't convince fantasai and leaverou ?<br> <fremy> astearns: I don't think this will block the spec<br> <fremy> TabAtkins: we are saying the exact same things we were saying in 2021<br> <astearns> s/will/is a/<br> <fremy> TabAtkins: we cannot come to a conclusion<br> <fremy> TabAtkins: but we cannot ship this way<br> <fremy> astearns: yeah, sometimes concensus takes time<br> <fremy> TabAtkins: I would like to point the lack of progress<br> <fremy> TabAtkins: I would like this decided in the working group<br> <fremy> TabAtkins: but eventually people will want to ship, and we can't make progress<br> <fremy> miriam: it would be nice if leaverou and fantasai could give the counter examples<br> <fremy> miriam: I am yet to see a good example, and I cannot produce them myself<br> <fremy> astearns: ok, seems reasonable to ask<br> <fremy> ACTION: fantasai and leaverou to come up with examples where strong proximity is more useful<br> <fremy> astearns: if we don't have examples in a month-ish of time, we can see how to move forward in another way<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-1450610228 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 March 2023 17:59:54 UTC