- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 8 Mar 2024 09:56:07 -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 Values
----------
- RESOLVED: Make semicolons an optional upgrade to commas in CSS
functions (Issue #9539: Better handling of arguments with
commas)
- RESOLVED: No change, keep with the existing resolution [existing
resolution:
https://github.com/w3c/csswg-drafts/issues/6026#issuecomment-1832443514
]
(Issue #6026: Use of 100vw is causing pointless
horizontal scrollbars on some websites)
CSS Pseudo
----------
- RESOLVED: Custom properties don't apply to the highlight pseudos.
On highlight pseudos, the var() function takes from the
originating element (Issue #9909: Revisit CSS Custom
Properties in highlight pseudos)
CSS Contain
-----------
- RESOLVED: If a content-visibility:auto element is skipping its
contents but has not yet determined its visibility, don't
fire the contentvisibilityautostatechange event until you
do know the visibility (Issue #9803: Should the first
`contentvisibilityautostatechange` event be fired without
knowing if the element is close to the viewport)
CSS Writing Modes
-----------------
- RESOLVED: All of the text spacing properties don't apply to the
squished-together character of text-combine-upright;
text-spacing-trim is treated as trim-all (Issue #9423:
Spacing within text-combine-upright)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0005.html
Present:
Rossen Atanassov
Tab Atkins
Kevin Babbitt
Oriol Brufau
Stephen Chenney
Daniel Clark
Elika Etemad
Robert Flack
Chris Harrelson
Daniel Holbert
Ian Kilpatrick
Vladimir Levin
Alison Maher
Florian Rivoal
Alan Stearns
Miriam Suzanne
Regrets:
Rachel Andrew
Yehonatan Daniv
Jonathan Kew
Chris Lilley
Romain Menke
Noam Rosenthal
Bramus Van Damme
Lea Verou
Sebastian Zartner
Chair: Rossen
Scribe TabAtkins
Scribe's scribe: fantasai
CSS Values
==========
Better handling of arguments with commas
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9539
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1918019555
TabAtkins: General problem is, we have several function in-flight
which can take argument values that are the full set of
CSS value syntax including comma-separated lists.
TabAtkins: example might be var(), which isn't a problem because we
intentionally put fallback as the last part, so you can
know whether the commas are top-level or part of the
argument
TabAtkins: but for several other new things, that's not possible
TabAtkins: Right now the proposals for these, when your function
could contain commas, we switch to using semicolons to
separate arguments in those functions.
TabAtkins: but it does mean that during design phase of a function,
we have to decide whether to use commas or semicolons
TabAtkins: It's also a bit weird to have two distinct syntaxes,
especially when most uses of these functions won't need
semicolons -- most of the time will not contain commas as
part of the argument, just a keyword or whatever
TabAtkins: So using semicolon for these when 99.9% of cases don't
need it is odd
TabAtkins: We came up with several options
TabAtkins: 1. Don't use semicolons. Instead, allow functions to have
some way to wrap arguments e.g. function, brackets, etc.
TabAtkins: For example, 'item()' which just wraps its contents and
means its contents.
TabAtkins: we could use brackets, like Grid already does
TabAtkins: or curly braces, which aren't allowed top-level but can
use inside a function
TabAtkins: Alternatively, could make the semicolons an optional
upgrade
TabAtkins: That is, you start parsing assuming comma separation
TabAtkins: but if you hit a semicolon, reparse the function as
requiring semicolons between arguments and treating commas
as part of the arguments
TabAtkins: I am mildly inclined to go with option 2, where semicolons
are an optional upgrade
TabAtkins: can be done across all of CSS, so don't have to think
about which functions
TabAtkins: Doesn't require extra level of nesting which we try to
minimize
TabAtkins: that said, I'm OK with any of these options
TabAtkins: Opinions?
astearns: Lea has asked a few times, instead of generic function, why
not bare parentheses?
TabAtkins: I responded -- previously purposely avoided bare
parentheses. We used them originally e.g. for grid names,
but switched away, because that would mess up SASS.
TabAtkins: those arguments still apply
astearns: I have a slight preference for option 1 with short function
name
astearns: I also think square brackets would be fine
<florian> [removed myself from the queue because I wanted to ask and
say the same thing as astearns]
oriol: Personally I'm fine with current situation of just using
semicolons.
oriol: It's true that we need to think about it at the beginning of
the function design, but it's ok to me
oriol: I'm also OK with option 2
oriol: among the others, they seem strange
oriol: I would be OK with parens, but the others seem a bit strange
to me
oriol: Also argument about SASS, I wonder if there would be a
possibility for them to wrap... This is a 3rd party tool, we
shouldn't constrain CSS development to match outside tooling.
fantasai: Like Oriol, I'm fine with current situation of designing it
form the beginning. also fine with option 2. I could live
with braces, but I think the function option reads as if
it's part of CSS rather than an escaping mechanism.
fantasai: so I'd prefer avoiding using a function.
fantasai: For brackets, we already use that in other parts of CSS
(Grid) so it's potentially confusing there.
fantasai: But we'd *never* use braces in that same way, so we won't
have the same problem
fantasai: So mild pref for semicolon; their identity is a stronger
comma and it's fitting we use it for that purpose
Rossen: Other opinions?
TabAtkins: Straw poll?
<TabAtkins> 1. No change (design functions to use ; when it's needed)
<TabAtkins> 2: use [] wrapper.
<TabAtkins> 3: use {} wrapper.
<TabAtkins> 4. use function wrapper (item() or similar)
<TabAtkins> 5. Upgradeable semicolon (comma in general, but authors
can choose to use ; instead when necessary)
Votes:
<TabAtkins> 5, 3
<astearns> 4, 2
<vmpstr> 4, 2/3
<fantasai> 1, 5, 3
<oriol> 1, 5
<schenney> 2,4,1
<miriam> 5,3,1
<flackr> 5, 4
<florian> 3,5
<kbabbitt> 2/3, 4, 1
<iank> 5, 1 maybe
<Rossen> 4,3
<dholbert> (abstain)
astearns: Tab, you had a worry that {} might break parsing, is that
still a concern?
TabAtkins: For naive (regex) parsing yeah, but all good tools should
have a real parser
fantasai: If you can't do bracket matching your tool is already gonna
break everywhere, so minimum you need to bea ble to bracket
match
<schenney> 5 is also most popular 2nd option, I think
<fantasai> Total counts: 5.5 for 1, 2 for 2, 7 for 3, 6 for 4, 7 for 5
Rossen: More first-place votes for option 5
flackr: Is there a problem with nesting the functions?
TabAtkins: That's fine, because the function itself will be the
wrapper
Rossen: Let's resolve on 5.
<florian> WFM
<florian> +1
TabAtkins: Was close, but 5 ekes out, and if any strong objections
can re-discuss
Rossen: Any objections to #5?
RESOLVED: Make semicolons an optional upgrade to commas in CSS
functions.
Use of 100vw is causing pointless horizontal scrollbars on some
websites
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6026
iank: I think now, with Bramus's data, this is likely fine
iank: Bramus did a lot of analysis on it. still a little concerned,
but someone can take the risk and see what happens
<fantasai> Bramus wins MVP of the issue! \^_^/
TabAtkins: When overflow is set on the root element (specifically;
not body), we will take the scrollbars into account when
calculating viewport unit sizes
iank: Yes, specifying overflow:scroll on the root is sufficiently
rare that people shouldn't run into this
iank: Probably won't solve the general case on existing sites, but
people can fix it moving forward
iank: One caveat is that enterprise is always hidden in this type of
analysis, so if someone rolls it out there might be a hidden
part that changes our resolution
TabAtkins: +1
fantasai: Why didn't we want to do it for body propagation? Too
common?
iank: Yes, I think it would break way too many sites
fantasai: Other thing in the thread is having the dv* units respond
to scrollbar
fantasai: So I guess it would make sense to say that dv* would
respond to scrollbar...
TabAtkins: dv* units are always between small and large units, right
now; we should be careful about losing that
<astearns> previous resolution:
https://github.com/w3c/csswg-drafts/issues/6026#issuecomment-1832443514
astearns: I linked to the existing resolution that already covers
this, this discussion is about us not undoing that
Rossen: So keep no change?
Rossen: Objections?
RESOLVED: No change, keep with the existing resolution
Rossen: Do we need something for the dv units?
fantasai: No, we should do that in a separate issue
miriam: Do we also need, in the new issue, to mention CQ units?
fantasai: Would need to be a more separate issue
CSS Pseudo
==========
Revisit CSS Custom Properties in highlight pseudos
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9909
schenney: I filed this based on two things
schenney: First, one of the comments on the bug report when we tried
to enable the highlight inheritance chain
schenney: Someone in a tool was setting a custom property on
::selection on every element, expected it to use the custom
prop from the element
schenney: Second, when I looked at SO about the ::selection pseudo,
there was at least one answer that ended up saying "just
use custom props for your selection pseudo"
schenney: so this appears to already be a big behavior, custom
properties driving selection behavior
schenney: Previous browser behavior, this *was* the correct way to do
it - customs would inherit through the originating element
chain
schenney: So I propose we change the spec to also inherit custom
props from originating elements
schenney: This may be great for devs, but it poses problems for impl
and spec
schenney: First, at minimum it's a memory hog, you have to copy
custom props onto all your selection pseudos.
schenney: every time the property set changes you have to reallocate
a new custom property set for the element
schenney: Second, what do you do when a custom prop is defined in
both the highlight inheritance chain *and* the originating
element?
schenney: "correct" answer depends on context, hard to spec a
reasonable behavior
schenney: So in hindsight I think we shouldn't make the change. But a
lot of webdevs have come in and said we *should* make it.
schenney: So, is there anything sensible to do about when there's
clashing declarations?
fantasai: I think one thing suggested in the thread which is fairly
simple is to have "normal" properties inherit through
highlight chain, but take custom properties from the
originating element
fantasai: and *only* the originating element
fantasai: So you can't set custom props on an article::selection and
have that visible to a span::selection
fantasai: but you can set it on `article` and inherit to the span,
and then it'll be visible in span::selection
fantasai: I don't like an interleaved where it's inherited from two
places at once, but I think in this limited case it's okay.
The entire set of normal and the entire set of custom each
have a single place to inherit from
schenney: I think that's equivalent to saying custom prop defined on
highlights are ignored?
fantasai: No. We *could* define it that way and it probably wouldn't
break much. But we could also still allow highlights set on
you to win, and just inherit from the element.
fantasai: but maybe that causes more problems
schenney: Right, you'd have to say they apply to the element it's set
on but not inherited... that causes issues. Simpler to just
not allow it
fantasai: Yeah
schenney: I think this is probably fine.
schenney: So do we do this for just ::selection or all the highlight
pseudos?
fantasai: All, I think
schenney: Yeah, for consistency
fantasai: And the same arguments apply for the other highlights too
schenney: I think there's not enough usage to really draw conclusions
from on the other types yet
fantasai: Lea mentioned wanting to do syntax highlighting with
highlight pseudos
fantasai: being able to use variables with them would be useful
schenney: Syntax highlighting does seem to be the primary usecase for
highlights, especially for perf, agreement
schenney: So proposed resolution: custom properties are disallowed in
highlight pseudo-elements. They inherit from the
originating element.
fantasai: Would that work for Lea's use case?
TabAtkins: Yes, because she sets the theme colors on the originating
elements
schenney: I think the only difference practically is if you change
the custom prop on the originating element chain, in a way
that's out-of-sync with how you change the highlight
"pseudo-classes" on the chain
schenney: That's the only way to get into trouble
dandclark: I was thrown off by Lea's example, it seems you can make
it work with either proposal
dandclark: I think our main concern was not breaking old code relying
on the current browser behavior
schenney: I think that's right
schenney: My primary motivation is that people currently do a lot of
custom properties on the elements and expect it to be
visible to the selection. allowing that really increases
the likelihood we can actually ship
dandclark: We are changing long-standing behavior by changing the
selection behavior at all, what's the bar for us to know
if it's shippable?
dandclark: When we switched to inherit custom props from root we got
some reports of real breakage, like form github
dandclark: It sounds like what I'm hearing is that it's not too bad
to just inherit the custom props, performance-wise
schenney: From a perf perspective, as long as we don't allow custom
props to actually be set on the highlight itself, then from
a code complexity perspective it works fine
schenney: In trying to launch highlights in chromium, we've run into
this issue, and people relying on the fact that they could
change the selection for just one type of element and
explicitly not have it inherited
schenney: But that second one has been fixed in the most important
sites affected by it, so I think with this change we'll
have a good chance of shipping the fixes
fantasai: So the proposal is custom props don't apply to highlight
pseudos. The var() function takes from the originating
element
vmpstr: Clarify on var() - that "takes from originating" is just for
the highlight pseudos, not in general, right?
TabAtkins: Yes
RESOLVED: Custom properties don't apply to the highlight pseudos. On
highlight pseudos, the var() function takes from the
originating element.
CSS Contain
===========
Should the first `contentvisibilityautostatechange` event be fired
without knowing if the element is close to the viewport
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9803
vmpstr: We have an event that fires when content-visibility:auto
state changes (form skipped to not skipped, or vice versa)
vmpstr: Question, what to do if we haven't determined visibility for
the element yet
vmpstr: Can happen if we add the content-visibility:auto then force
rendering
vmpstr: Visibility is done at IO timing, so not done yet
vmpstr: Naively we'd fire an event that says "it's skipped" then at
IO time we fire another saying "it's visible", two events in
rapid succession
vmpstr: Filer of the issue suggests we just don't fire the event
until we've actually had a chance to determine the visibility
<TabAtkins> +1, makes sense to me
vmpstr: One extra - "unless there's something else making the element
relevant to the user", then we already know it's relevant and
fire it immediately
vmpstr: so if the element is skipping its contents but we haven't
determined its visibility yet, don't fire the event
<chrishtr> +1 to the resolution
RESOLVED: if a c-v:auto element is skipping its contents but has not
yet determined its visibility, don't fire the
contentvisibilityautostatechange event until you do know
the visibility
CSS Writing Modes
=================
Spacing within text-combine-upright
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9423
fantasai: There's a feature text-combing-upright which causes glyphs
in upright vertical text to combine into a single combined
block
<TabAtkins> like if you want "23" it'll smush into one block
fantasai: We specify that letter-spacing doesn't apply inside the
smushed box, we treat it like a single character
fantasai: We didn't specify the other spacing properties, like
word-spacing
fantasai: Proposal is we ignore all of them
fantasai: and for text-spacing-trim we treat it as trim-all
fantasai: Generally you won't run into these situations anyway, but
if you do you probably don't want extra space making it
even more squished
florian: I initially thought we wanted some options here, but on
further thought I think we don't, and that fantasai is right
<TabAtkins> +1
Rossen: objections?
<fantasai> illustration ->
https://www.w3.org/TR/css-writing-modes-4/images/tate-chu-yoko.png
RESOLVED: All of the text spacing properties don't apply to the
squished-together character of text-combine-upright;
text-spacing-trim is treated as trim-all
Received on Friday, 8 March 2024 14:56:40 UTC