- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 4 Jul 2024 10:03:28 -0400
- 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
-----------
- RESOLVED: Bare declarations in a scoped rule apply to the scoped
root and add no specificity (Issue #10431: @scope as a
nested grouping rule and CSSNestedDeclarations)
- RESOLVED: Reverse the previous resolution and not serialize
implicit :scope pseudos (Issue #9621: Always serialize
the implicit `:scope`?)
- RESOLVED: Allow bare declarations in a top level scope rule (Issue
#10389: Allow declarations directly in @scope?)
Anchor Positioning
------------------
- RESOLVED: "Like most operations in CSS besides selector matching,
features in this specification operate over the flattened
element tree." goes to anchor positioning spec` (Issue
#10325: Flat tree vs. anchor-scope)
CSS Scrollbars
--------------
- RESOLVED: Transparent colors in the thumb are transparent towards
the track, and transparent colors in the track are
transparent towards the background; transparency in those
colors is not generalized to the entirety of the
scrollbar (Issue #9853: What do (semi) transparent colors
mean for scrollbar-color)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jul/0000.html
Present:
Stephen Chenney
Matthieu Dubet
Elika Etemad
Anders Hartvoll Ruud
Ian Kilpatrick
Alison Maher
Florian Rivoal
Khushal Sagar
Alan Stearns
Brandon Stewart
Miriam Suzanne
Regrets:
Rachel Andrew
Kevin Babbitt
David Baron
Oriol Brufau
Chris Harrelson
Daniel Holbert
Jonathan Kew
David Leininger
Noam Rosenthal
Bramus Van Damme
Lea Verou
Sebastian Zartner
Chair: astearns
Scribe: khush
CSS Cascade
===========
@scope as a nested grouping rule and CSSNestedDeclarations
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10431
andruud: When a @scope rule is a nested grouping rule we allow bare
declarations within its body. Now such declarations should
be wrapped in a nested CSS rule.
andruud: The CSS nested declarations rule is generally defined to
match whatever the parent selector matches
andruud: with same specificity behaviour
andruud: But this may not make sense for at-scope since it's not how
implicit selector stuff works for scope in general
andruud: so we should have nested CSS declaration rule inside scope
matches the scoping root with no specificity
astearns: This matches Miriam's proposal?
miriam: Yes. Scopes don't add specificity which matches this. Bare
declarations in the scope matches the scope root.
andruud: When it's not nested, it's not allowed. Separate open issue
miriam: This matches previous statements. +1
astearns: From glancing at your last comment, there are other things
to resolve on this?
miriam: They'll fall out so let's be clear.
miriam: One resolution was to serialize the implicit scope but that
adds specificity. So we need to change that to work the same
way, implicit scope is wrapped in a ware pseudo class which
hides the specificity of selectors inside it
miriam: also allow declarations directly inside scope
astearns: So nested related issues
miriam: Doing all will get consistent behaviour
astearns: Sounds like if we're serializing the bare decls in a scope
such that they are wrapped in a :where pseudo?
andruud: If the :where pseudo is implicitly added it should not be
serialized
astearns: No problem then
<miriam> :where(:scope)
astearns: Any other comments?
matthieud: It's not directly related to this issue but in general
what's the meaning of something nested in a rule. It's
just gonna have specificity of pseudo-class of 1. We need
to add specificity of each layer or cascading won't work
miriam: It puts the implicit & in the scoped rule. So the scoped root
is a nested selector of the parent
andruud: This is an existing issue?
matthieud: Resolution won't change the behaviour but wanted to bring
this up.
astearns: So should we resolve on what we were first discussing and
then go through each implication in turn?
miriam: Not sure how well the resolution is on the issue
miriam: For this one, where declarations in scope should be treated
as a CSS nested declaration?
andruud: The :where declarations apply to the scoping root with no
extra specificity
astearns: It's not where and bare declarations in the above
matthieud: Do we want specificity of the start or the complete
selector which could be more complex
miriam: Scoped root doesn't add specificity, only when you use & or
:scope. If you're adding a bare declaration then no
specificity added
astearns: Proposed resolution, bare declarations in a scoped rule
apply to the scoped root and add no specificity.
astearns: Objections?
RESOLVED: Bare declarations in a scoped rule apply to the scoped root
and add no specificity.
astearns: Other related issues?
miriam: Clarify serialization. We can't serialize it with :scope.
Won't do what we just resolved.
Always serialize the implicit `:scope`?
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9621
andruud: If a :scope is implicitly added it's not serialized back
out. Because there is a diff between implicit and explicit
:scope in terms of specificity
andruud: so they are not equivalent.
astearns: Doesn't change anything about serialization of explicit
:scope
astearns: Proposal is to reverse the previous resolution and not
serialize implicit :scope
matthieud: We agreed to do that for nested rules not inside ... the
idea to always serialize nested rule is to take the
selector from a nested rule and apply elsewhere.
matthieud: You can't move everything around and expect it to work
automatically
astearns: Any other comments?
astearns: Objections to not serializing implicit scope
RESOLVED: reverse the previous resolution and not serialize implicit
:scope pseudos
<matthieud> we can't move a relative selector like "> div" from a
context where it's valid to a context where it's not
valid (top level rule)
Allow declarations directly in @scope?
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10389
miriam: We just said that when scope is nested, we can put bare decls
inside of it. Scope is a bit different from other at-rules in
that it changes the selector somewhat and has own selector
built-in.
miriam: So we could allow bar declarations at any level it doesn't
need to nested
miriam: So we could say this is also allowed when its not nested
matthieud: Allowing declarations inside of scoped rule which are top
level?
miriam: Yup
miriam: I don't feel strongly about it but feels consistent if we
allow in nested situations. So why not root?
andruud: Agreed would be weird
andruud: Also part of the reason to not do initially was we didn't
have relaxed nesting. So couldn't distinguish between
selectors starting with tag names
astearns: +1
astearns: Anyone needs time before resolving?
astearns: Proposed resolution: allow bare declarations in a top level
scope rule.
matthieud: In the cssom the declarations will be represented by a
rule in a CSSNestedRule object?
andruud: Yes
astearns: Objections?
RESOLVED: Allow bare declarations in a top level scope rule
miriam: If someone screams, we can revisit
matthieud: Happy to discuss the other issue you mentioned
Anchor Positioning
==================
Flat tree vs. anchor-scope
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/10325
andruud: The anchor-scope in the spec says it's scoped to this
"subtree". flat tree or something else. Matters for slotted.
And I propose flat tree otherwise you can't style an element
with ::slotted pseudo-element as an anchor.
andruud: If we don't use flat tree it's going to look for its anchor
scope outside the shadow tree
andruud: Elika had an opinion on the exact wording
fantasai: idk if I understand the basic issue. I was concerned that
we don't imply which tree here and other parts of the spec
are ambiguous
fantasai: Just clarify that unless other specified the whole spec is
operating on the flat tree
fantasai: If we don't state this somewhere then its implied
astearns: Agreed
astearns: Somebody might skip that part and make assumptions about
which tree rest of the spec is on
fantasai: In general CSS works on the flat tree. so this is more of a
reminder
andruud: So already interpret it as a flat tree
astearns: Is it extra work required at all?
<miriam> extra-normative? super-normative?
astearns: Proposed resolution is to add a normative statement to the
anchor spec. Features in this spec operate over the
flattened tree.
fantasai: There's wording I was suggesting to copy over from timeline
lookups
<fantasai> "
<fantasai> Like most operations in CSS besides selector matching,
features in this specification operate over the flattened
element tree.
<fantasai> "
astearns: Any concerns?
astearns: Objections?
RESOLVED: "Like most operations in CSS besides selector matching,
features in this specification operate over the flattened
element tree." goes to anchor positioning spec.
astearns: good clarification to add
fantasai: most in case there are other exceptions
CSS Scrollbars
==============
What do (semi) transparent colors mean for scrollbar-color
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9853
florian: This is about transparent color for scrollbar-color property
florian: that property takes 2 colors one to the thumb, the other
applied to the track
florian: What does transparent means here ?
florian: Depend on the operating system, depend between current and
older one, they sometimes have design like shaded bottom
...etc...
florian: Currently it is not specified how this property affect those
other parts
florian: so what do we do with "transparent" (many possible design
choices)
florian: In general, browser applies it to the background
florian: We also discovered that some people use entire transparent
to make scrollbar disappear
florian: If it has a button what happens.
florian: Maybe we need a specific property like
scrollbar-transparency or scrollbar-opacity
florian: Even if we only think about the thumb, given a
semi-transparent color doesn't apply on the whole thing
florian: One way out of it it to be explicit neither the thumb color
nor the track color are pre-composed in any way nor ignored
florian: For the use case of making the whole scrollbar transparent
we can make a separate property
florian: One important thing: we need to specify something. Right now
its the author who is in charge of good contrast
florian: ignoring transparency means black
florian: If we don't specify the behavior, the author cant ensure
good contrast
florian: Proposal: there is no magic that applies the transparency of
those colors to the entirety of the scrollbar
florian: This color has used by UA to shade the various parts
florian: The colored part of the thumb is transparent toward the
track, and the track toward the background
<miriam> +1
??: what about pre-composition ?
florian: Current UA compose toward the background, including images
and gradients…
florian: not transparent toward the potential text on top
astearns: If we resolve to that, is there change to UA necessary?
florian: Not really
florian: When they have flat track/thumb, they already do that
florian: When you have a non flat scrollbar, you can't assume that
transparent means disappear scrollbar
florian: However if we go the other way, there might be discontinuity
(cf aqua or windows scrollbar)
florian: In an old fashion scorllbar design if you apply a semi
transparent color only to the colored parts but apply fully
transparent to the whole scrollbar, then there's a
discontinuity at very-but-not-fully transparent
florian: Whatever we decide today, we are not gonna resolve a new
property to control scrollbar opacity today
florian: Maybe this is a prerequired to resolve the rest
PROPOSED: we specify what UA are currently doing with transparent
color on their flat scrollbar today
florian: the WPT tests are not testing what is in the spec
PROPOSED: we also note that it doesn't mean that all scrollbars will
be totally transparent (its true currently, but a coincidence)
<florian> PROPOSED: transparent colors in the thumb are transparent
towards the track, and transparent colors in the track are
transparent towards the background; transparency in those
colors is not generalized to the entirety of the scrollbar
RESOLVED: transparent colors in the thumb are transparent towards the
track, and transparent colors in the track are transparent
towards the background; transparency in those colors is not
generalized to the entirety of the scrollbar
[some discussion about how UAs paint over the background directly,
not over e.g. text content underneath]
florian: Non flat scrollbar already exist at least on Linux
Received on Thursday, 4 July 2024 14:04:00 UTC