- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 2 Mar 2023 19:24:31 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Cascade 6
-------------
- RESOLVED: Close the issue as no-change (Issue #7943: change lower
boundary keyword for @scope to "until")
- RESOLVED: Accept clarifications for scoping selectors proposed by
miriam (Issue #8377: Scoped selectors shouldn't match
the scope root unless explicitly requested with :scope?)
- RESOLVED: The specificity of the scope root is not applied to
selectors from scoped rules (Issue #8500: The
specificity of a scope rule)
- The examples and developer feedback for issue #6790 (Strong vs
weak scoping proximity) were arguments for weak proximity. The
group members looking for strong proximity are asked to add use
cases into the spec over the next week so the working group can
further discuss and reach a resolution.
===== FULL MEETING MINUTES ======
Scoping breakout agenda:
https://lists.w3.org/Archives/Public/www-style/2023Mar/0001.html
Present:
Tab Atkins
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Brad Kemper
François Remy
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Chair: astearns
Scribe: fremy
CSS Cascade 6
=============
change lower boundary keyword for @scope to "until"
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7943
miriam: This is a bikeshedding issue open for a while
miriam: the concern is that "scoped to" usually means "it's inside
the scope"
miriam: so it might be confusing to also use "to" to say that the
scope goes "from...to"
miriam: I have no strong opinion on it
<fantasai> wfm
fremy: wfm too
bramus: No hard feelings, but "to" sounded better to me, because as
a non-native English speaker "until" is not very frequent
bramus: this might also be related to the next issue
bramus: if we choose to include the boundaries, "to" might be better
TabAtkins: There is no clear English word that indicates exclusivity
or inclusivity with clarity
TabAtkins: so I don't think the choice of term is not that important
TabAtkins: and therefore believe going with the shortest one makes
the most sense
<TabAtkins> "range from 0 to 3" can easily mean [0,1,2,3] or [0,1,2]
depending on context. Even sometimes [1,2].
fantasai: While I agree with TabAtkins that the inclusivity is not
clear in either wording
fantasai: that said, I can understand the other argument about how
"scoped to the X element" means using X as the scoping root
fantasai: but maybe we could use something else than a word, like
the > sign?
<TabAtkins> I think we should avoid `>` next to selectors, due its
context-specific meaning there.
fantasai: That would avoid the problems with the choice of an
English word
bramus: The > sign is also a combinator
miriam: But scoping extends in the same direction as the combinator
miriam: so not a problem for me, though I still like "to" a bit
better I guess
astearns: There doesn't seem to be passionate comments for any of
the comments
astearns: so maybe we should just leave things as they are, for lack
of a huge reason to change
<bramus> +1
astearns: "to" is easier to spell, and not any more precise
miriam: ok, let's propose to close no change
astearns: Yes, and if someone has a stronger argument or more data
etc we could revisit
<TabAtkins> The only clear range-based english keywords I've ever
really seen were in Lisp's LOOP macro - "0 to " was
inclusive, "0 below 3" was exclusive.
fantasai: Like a more compelling rationale or something
astearns: Any objection?
RESOLVED: close the issue as no-change
Scoped selectors shouldn't match the scope root unless explicitly
requested with :scope?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8377
miriam: The scope roots elements are currently part of the scope,
with no implied relationship
miriam: So, if you use the same selector for both ends, the end
matches the root
miriam: bramus and others found that confusing
miriam: So the proposal would be to imply that nesting scope
selectors include :scope
miriam: except if they explicitly reference :scope or use ampersand
miriam: There are a couple of differences between :scope and
ampersand
miriam: mainly you can use & multiple times
<TabAtkins> & references all the elements matched by the scope-start
selector (as normal for Nesting), :scope matches the
specific element that is functioning as the scope in a
given element's context.
miriam: so the proposal clarifies the difference
<fantasai> +1 to the proposal
<TabAtkins> +1 to the proposal
fantasai: What is the specificity of :scope and ampersand?
miriam: There is another issue on that
miriam: but my guess is that ampersand should work just as in nesting
miriam: (wrapping the starting scope selector in :is)
TabAtkins: That's also my preference
astearns: Does that work for you fantasai ?
fantasai: yes
<fantasai> proposal was to have & use the specificity of the
selector it's referencing, and for :scope to have its
normal specificity (1 pseudo-class)
bramus: Should we also introduce :end for the end boundary?
bramus: for sibling scopes, that might be useful
miriam: This sounds like a separate resolution
miriam: Could you provide some clear use cases for that?
<TabAtkins> have we discussed the meaning of relative selectors like
`> .foo`? Do those get captured by Nesting, implying an
&, or do they imply a :scope? I think the latter should
be the case.
astearns: The proposed resolution is in the last comment of the
thread
astearns: Looking at tab's question on irc
astearns: Tab, do you want to voice the question?
miriam: I think I agree with TabAtkins suggestion
miriam: Relative selectors (...missed)
miriam: Question was what happens if the selector starts with a
descendant combinator
miriam: so just adding a descendant combinator should be the same as
the default
fantasai: I think that it implies that every selector inside a scope
that doesn't start with an ampersand has an additional
pseudo-class specificity
TabAtkins: No, no difference
TabAtkins: The implied-ness is just for the meaning, but not the
specificity
TabAtkins: the implied one does not add specificity
fantasai: p and :scope p are the same, but with different
specificities
TabAtkins: Yes
fantasai: And if I add (...) I could match more
TabAtkins: Yes, not in that use case, but in others yes
fantasai: If you use descendants, you can match much more
fantasai: and both :scope and & can match the scoping element, but
no other selector can
miriam: No other selector make it remove the nested-within combinator
TabAtkins: By the magic of relative selectors, it will never happen
TabAtkins: You have to make it absolute to override
fantasai: Ok, this is probably fine, but the spec should be extra
clear about it
astearns: So, the proposed resolution is to accept miriam's proposal
+ add new clarifications
astearns: Any comment?
fantasai: I think this is a good change and I support it
astearns: Any objection?
RESOLVED: Accept clarifications for scoping selectors proposed by
miriam
The specificity of a scope rule
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8500
miriam: In the current spec, the specificity of scope works very
much like nesting
miriam: In that the scope selector gives its specificity to all
selectors inside
miriam: This seems split 50/50 between people
miriam: but this sounds like an accidental side effect that is not
necessary
miriam: so, we should probably not apply it
<TabAtkins> +1
<fantasai> +1
<ydaniv> +1
<fremy> +1
<TabAtkins> the thread definitely didn't seem 50/50, but it might be
more evenly split in general ^_^
bramus: In the thread, I added some doubts, but in the end I agree
fantasai: And if you want the other behavior, you can use ampersand
miriam: Yes, ampersand would work
astearns: Easier than designing an opt-out
astearns: Ok, can we get a short summary of the resolution?
miriam: The specificity of the scope root is not applied to
selectors from scoped rules
astearns: Any objection?
RESOLVED: The specificity of the scope root is not applied to
selectors from scoped rules
Strong vs weak scoping proximity
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6790
miriam: One of the main features of scoping is that it applies
proximity to the cascade
miriam: The closer from the scope root the element is, the higher
the "priority"
miriam: but does it beat specificity or not?
miriam: There are use cases for both
miriam: Authors have more control over the css
miriam: so specificity is more controllable
miriam: but proximity is sometimes more valuable
miriam: but I think in the end, weak is more useful
miriam: (specificity>proximity)
miriam: Strong proximity puts proximity between two things that
authors can control
miriam: which might be confusing
miriam: I think either one could work, so open to thoughts
fantasai: My first thought is that I don't want to resolve this
without leaverou and jensimmons on the call to think about
this
fantasai: Weak scoping might be very weak, though, even weaker than
nesting because we remove implied :scope specificity
fantasai: and I'm not sure this is useful that way
fantasai: Putting it between layers and specificity is actually nice
in my opinion, as authors can control things more
explicitly
fantasai: tweaking specificity is more constraining
fantasai: People should describe what they want to match
fantasai: not have to think about how the sum of things should be to
make things work
fantasai: which is why I would maybe prefer people use layers for
this
<lea> I have expressed preference for strong scoping before
<lea> weak proximity makes this far less useful
dbaron: As a disclaimer, I never liked specificity because it's
magical but not magical enough for what people want
dbaron: but if I understood correctly "weak proximity" is so weak
that it might almost never be a factor
<fantasai> +1 to dbaron, I have the same concern
dbaron: and in that case, weak proximity might be more confusing
than no proximity at all because it would make a difference
too rarely for people to think about it
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/6790#issuecomment-959733391
TabAtkins: interesting thoughts, I will think about it more
TabAtkins: I still strongly think weak proximity is important
TabAtkins: because if you just want to have selectors "leak further"
TabAtkins: and now, the added proximity would ruin that, you would
have to move everything to layers
TabAtkins: Second argument, strong proximity would overrule
everything
TabAtkins: like #id outside the scope would lose to * inside the
scope
TabAtkins: That sounds very bad to me. It might be reasonable when
specificities are close, but not when they are far apart
<dbaron> (I have sometimes thought that specificity should have been
processed in pieces, based on proximity.)
TabAtkins: Third argument, authors can use layers already
TabAtkins: so, if authors need proximity to win, they can weaken
their selectors and use layers
TabAtkins: so, adding another complex mechanism here is maybe too
much
TabAtkins: I would not mind no proximity or weak, but strong is a
different beast
fantasai: If the main use case is to put a floor on things, can we
incorporate this in the nesting syntax somehow?
fantasai: and not have proximity come into play at all?
fantasai: I'm concerned that selectors inside the scope have no
specificity boost at all
fantasai: so, it will not do much for authors when they want to
actually use scoping
fantasai: sometimes people want descendant selectors to deal with
proximity
fantasai: but I don't like that nesting would be stronger than
scoping here
miriam: I think I would not call lower boundaries the only use case
miriam: I still think weak proximity comes into play at the right
time, in my opinion
miriam: It comes into play when you are targeting multiple
overlapping scopes
miriam: and when they conflict, you want to closest one to win
miriam: so I disagree it is not relevant if it's weak
miriam: In my opinion, it becomes relevant exactly when you want it
TabAtkins: I was gonna say exactly this
TabAtkins: but there might be a few cases where proximity could
matter more
TabAtkins: but when you want to style a component in two themes,
weak proximity works perfectly
TabAtkins: Specificity would be identical, but you want proximity to
win
TabAtkins: In other cases, it's not clear that any mix of
specificity/proximity that might be right or wrong is
useful
TabAtkins: Adding wrong mechanisms means people have to fight
against it
TabAtkins: I would rather them use the mechanisms we already have
fantasai: Suppose that the descendant selector was originally
defined to use proximity (as many people expect until they
learn better), why is the system we have now better than
that?
TabAtkins: That would be a substantially different world
TabAtkins: I'm not sure this thought experiment informs us that much
fantasai: The reason it makes a difference is that the relationship
between scoping and nesting becomes quite different
fantasai: because nesting could have scoping effect
fantasai: and that would become the default way things relate to
each other
fantasai: We should think about whether the way it works now is
actually better
fantasai: maybe proximity could be made easier to use in a different
way
fantasai: nesting compounds
fantasai: and weak proximity + compounded specificity makes sense
fantasai: but weak proximity + ignored specificity seems odd to me
TabAtkins: I disagree, for the exact same example you just proposed
TabAtkins: because how you end up in a particular theme doesn't
matter
TabAtkins: There could be many ways to target the theme switch
TabAtkins: but that doesn't matter
TabAtkins: What matters is when was the last theme switch
TabAtkins: and any change to this would harm the use case
fantasai: I see that what you say here make sense
fantasai: but nested selectors will win because they are more
specific
fantasai: and I think that the interaction is not the way that you
would expect that to work
fantasai: I would expect it to have a weaker effect
TabAtkins: That argument applies to anything that affects specificity
TabAtkins: like, it would turn off .class or #id
TabAtkins: which we assume usually has a meaning
TabAtkins: and if they want to change that, they can use the
existing mechanisms
TabAtkins: Adding something that would work in all cases could be a
slam dunk
TabAtkins: but a mechanism that works sometimes and breaks other
times is not useful in my opinion
astearns: Let's go back to the issue for now, and try to come up
with examples
astearns: Layers could help you get closer
fantasai: Not really
TabAtkins: Yeah, almost
astearns: Ok, at least it's not clear to me how layers come into play
astearns: we should look into this more
fantasai: So we have three things, layers, specificity, flooring
effect of scope rules
fantasai: Right now we combine them different between nesting and
scope rules
fantasai: and I think we want all three
<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.
miriam: If we are taking this back to the issue
miriam: one issue is that developers who used it
miriam: they say that weak proximity has worked for them
miriam: even when they had initially said they would prefer strong
miriam: All examples I have seen where strong specificity were a bit
artificial
miriam: so I'm not sure how we will get to a resolution if we keep
accepting theoretical concerns
astearns: leaverou and fantasai both have opinions here, and we
should probably keep working on resolving this
TabAtkins: Every time we bring this up, this is the resolution
TabAtkins: What do we do if that doesn't happen
TabAtkins: That's like the third time we have this resolution
TabAtkins: Nesting cannot apply proximity because it does not
establish a containment relationship
TabAtkins: You could do siblings, you could reverse the order by
putting the ampersand in :has, etc...
fantasai: But the default is descendant
fantasai: What if the default would add proximity?
TabAtkins: That would surprise everyone
<bramus> Also wouldn’t change that. Seems like a huge can of worms
to open.
fremy: Nesting is supposed to work like preprocessors do, we're
using the same syntax
fremy: If we change behavior it will confuse everyone
miriam: Proximity also requires a specific element that you can
refer to
miriam: which isn't the case for nesting
TabAtkins: So, what do we do if we can't convince fantasai and
leaverou?
astearns: I don't think this is a block for the spec
TabAtkins: We are saying the exact same things we were saying in 2021
TabAtkins: we cannot come to a conclusion
TabAtkins: but we cannot ship this way
astearns: Yeah, sometimes consensus takes time
TabAtkins: I would like to point the lack of progress
TabAtkins: I would like this decided in the working group
TabAtkins: but eventually people will want to ship, and we can't
make progress
miriam: It would be nice if leaverou and fantasai could give the
counter examples
miriam: I am yet to see a good example, and I cannot produce them
myself
astearns: Ok, seems reasonable to ask
ACTION: fantasai and leaverou to come up with examples where strong
proximity is more useful
astearns: If we don't have examples in a month-ish of time, we can
see how to move forward in another way
+++After call IRC discussion+++
<astearns> lea: note the request for counterexamples, if you want to
advocate for strong proximity
<fantasai> I think what I'm uncomfortable with is that a) weak
@scope ends up weaker than nesting in almost all cases
and b) weak scoping is something that probably is more
useful that descendant selectors almost all the time, so
if we're introducing it it should be possible to easily
use it everywhere and c) we're tying the ability to floor
a selector with applying weak scoping
<fantasai> I don't have a problem with introducing weak scoping into
CSS. And I don't have a problem with introducing the
ability to floor nested selectors. But I'm not convinced
that this @scope rule is the way to do it.
<fantasai> And to be clear, I'm not proposing that nesting build in
proximity scoping by default. I just think it's something
worth thinking about as a thought experiment, to see what
that would look like and how it might influence what we
do with scoping.
<miriam> We have considered that thought experiment several times.
Most of it is in the current spec, and is slowly getting
removed because we haven't found a reliable way to make it
work.
<miriam> I've been pushing on this spec for several years now, and
every month someone suggests that we merge it with nesting
- but they don't actually combine well. The things in scope
rely on scoping as a concept. The things in nesting
intentionally avoid scoping as a concept. We haven't yet
been able to combine them in a ways that isn't just 'choose
one'
<miriam> It's not a new thought experiment, it's something we've
been exploring for several years now. So what annoys me is
just the fact that it can derail progress every time it
comes up - and it seems to not matter that we've already
tried.
<miriam> Yes, from a theoretical view, it would be very cool if we
didn't need both nesting and scope. Every time we dig into
it so far, we find that we need both nesting and scope
because they work in fundamentally different ways.
<fantasai> miriam: I know you've written a lot on these topics, do
you have an index so I can read them all and try to catch
up to where you're at? :)
<fantasai> other than the bug database I mean
<miriam> I think it's mostly in the individual issues. I'm working
on an update to the explainer as well. Or happy to sit down
with you sometime and try to work through it in person.
<fantasai> miriam: maybe I'll re-read the issues and then we can
chat? might also be good to get leaverou in the discussion
<miriam> sure, sounds good to me
<fantasai> miriam: in the meantime, the spec seems a bit out of date?
<fantasai> https://www.w3.org/TR/css-cascade-6/
<fantasai> December 2021 !
<miriam> yeah, it is for sure. There's a few edits in the ED that
just need published, and a few more edits that need to be
made based on resolutions.
Received on Friday, 3 March 2023 00:25:14 UTC