- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Oct 2024 17:11:07 -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 Overflow, Contain, and Sizing
---------------------------------
- RESOLVED: Take 2nd option (reserve space as for scrollbar-gutter)
and add a new value to scrollbar-gutter for inline-axis
scrollbars (tbd) (Issue #7875: `overflow: auto`
incompatible with size containment and container queries)
- Florian will file a new issue on the new scrollbar-gutter value.
CSS Content
-----------
- RESOLVED: Mark counters in 'content' alt text as at-risk (Issue
#10387: Use case for counter / counters in content alt
text?)
CSS Variables & CSSOM
---------------------
- RESOLVED: Serialize custom properties with empty value as a single
space (Issue #9847: Empty value doesn't round-trip)
CSS Anchor Positioning
----------------------
- RESOLVED: All conditions listed (other than which property it's
used in) are computed-value time (Issue #10955: Should
anchor() be validated at parse time when it is known
invalid?)
- The editors were actioned to clarify (by adjusting the legacy
wording) that anchor() is invalid outside inset properties.
CSS Values
----------
- RESOLVED: Use commas for progress() (Issue #10489: Syntax of
progress() vs mix() functions)
CSS Images
----------
- In order to address issue #7648 (Mesh gradient / Freeform gradient
/ 2D gradient) we need info on PDF compatibility and color
interpolation abilities of the options, so we know what is
possible to render to screen and print.
Properties Values API
---------------------
- RESOLVED: Drop validation of fallbacks with regards to their custom
property (Issue #10455: Are fallbacks provided for
registered properties validated by the CP syntax?)
CSSOM View
----------
- RESOLVED: We will expose large/small/dynamic objects representing
the layout viewport sizes as accessors with width/height/
block/inline properties; details and which object TBD
(Issue #8709: Expose small/large viewport dimensions of
the layout viewport)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Oct/0002.html
Present:
David Baron
Oriol Brufau
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Simon Fraser
Daniel Holbert
Jonathan Kew
Roman Komarov
Chris Lilley
Florian Rivoal
Alan Stearns
Josh Tumath
Sebastian Zartner
Regrets:
Rachel Andrews
Tab Atkins-Bittner
Robert Flack
Chris Harrelson
Miriam Suzanne
Bramus Van Damme
Lea Verou
Scribe: fantasai
Scribe's scribe: emilio
CSS Overflow, Contain, and Sizing
=================================
`overflow: auto` incompatible with size containment and container
queries
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7875
florian: A bit left on this issue. Already dealt with overflow and
size containment
florian: some instability in that, but solved already [quotes
resolution]
florian: in terms of 'overflow: scroll' we can apply the same
principle, but first phase is with scrollbars and size
accordingly
florian: second phase where we don't need to add them, since already
there
florian: solves first part of problem, but left with another one
florian: which is question of instability of 'overflow: auto' and
'contain-intrinsic-size: auto"
florian: if you put content in the element it adds scrollbars, then
you freeze; if other way around, if freeze without knowing
content then scrollbars don't take room and size
differently, it's a problem
florian: In order to solve this I see 2 alternatives
florian: 1. contain-intrinsic-size:auto causes overflow:auto to
compute to overflow:scroll
florian: this removes instability by removing flexibility
florian: 2. reserve only scrollbar gutters; scrollbars don't get
painted unless there's overflow but we reserve space for them
florian: could explain as used value of scrollbar-gutter, but would
need a new value for inline axis
oriol: I prefer the 2nd option, getting these gutters looks better
than having scrollbars that don't scroll
oriol: though making overflow convert to scroll would be easier to
implement
oriol: fine with either option
kizu: Prefer the 2nd option. Especially I was surprised when
scrollbar-gutter doesn't work in horizontal axis, would be
useful
kizu: so support adding the new value and using it for this case
astearns: Asking for clarification on 2nd option -- this could be
explained in terms of scrollbar-gutter -- if we go with
this option, are we absolutely adding a new value to
scrollbar-gutter?
florian: We have a choice. We could explain it conceptually without
involving the property, or we can add a new value to the
scrollbar-gutter property and invoke that value
florian: but as mentioned, the new value could be useful in other
cases
astearns: Other opinions?
PROPOSED: Take 2nd option (reserve space as for scrollbar-gutter) and
add a new value to scrollbar-gutter for inline-axis
scrollbars
florian: Need a name for it?
fantasai: Existing values?
florian: auto | stable (applies to both start and end values)
florian: but we need a new value for inline and block
<florian> auto | stable && both-edges?
florian: Currently scrollbar-gutter only applies to block-axis
scrolling (scrollbars on the inline-axis edges of the box)
florian: Could add new keywords 'inline' and 'block' and 'both' to
combine with 'stable', defaulting to 'inline'
florian: I'll open a new issue
RESOLVED: Take 2nd option (reserve space as for scrollbar-gutter) and
add a new value to scrollbar-gutter for inline-axis
scrollbars (tbd)
ACTION: Florian to file a new issue on the new scrollbar-gutter value
<RRSAgent> records action 1
CSS Content
===========
Use case for counter / counters in content alt text?
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10387
emilio: This came up during implementation of alt text content feature
emilio: it looks simple, but very complex to implement because
counters work on the layout tree
emilio: it's fine to mark at risk, but given nobody supports it and
unclear if use cases though some mentioned in the issue...
emilio: so wondering if we should just drop
fantasai: Prefer to mark at-risk
fantasai: Nobody says it's a bad idea, and there are some use cases;
just a question of implementability
RESOLVED: mark counters in 'content' alt text as at-risk
CSS Variables & CSSOM
=====================
Empty value doesn't round-trip
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9847
oriol: In the past, we didn't have any property that would accept
empty value as valid
oriol: but we changed custom properties to trim whitespace and accept
empty values
oriol: problem is with CSSOM, because in setProperty if you provide
an empty string, then instead of trying to set an empty value
it behaves as removeProperty
oriol: so if you serialize a custom property that's empty string, it
won't round-trip
oriol: Some possible improvements
oriol: 1. For custom properties we could stop doing removeProperty
for assigning the empty string.
oriol: but might have some compat problems at this point
oriol: 2. Instead of serializing empty values as empty string,
serialize a single space. This will round-trip.
<dbaron> option 2 sounds good to me
oriol: Could also use a comment instead of space, but space seems
preferable
<kizu> +1 to a space
<ChrisL> single space seems a good way, to me
<fantasai> +1 to space
astearns: Has anyone tried implementing?
oriol: No
fantasai: I think there's a benefit with being consistent in the way
we remove properties
emilio: +1 to that. Serializing to space is simpler and less
inconsistent
astearns: any opinions against?
RESOLVED: Serialize custom properties with empty value as a single
space
CSS Anchor Positioning
======================
Should anchor() be validated at parse time when it is known invalid?
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10955
<fantasai> https://drafts.csswg.org/css-anchor-position-1/#valid-anchor-function
fantasai: [summarizes the issue]
fantasai: some of the invalid cases we can figure out at parse time
fantasai: like whether it's used in an inset property or what not
fantasai: the spec is not very clear on whether we're allowed to
validate at parse time vs. used value time
fantasai: Question is, do we want to do parse-time validation insofar
as possible, or doing everything at computed-value time?
astearns: If we do as much invalidation as we can at parse time, are
you concerned that the edge cases where we can't invalidate
at parse time would be confusing to authors?
fantasai: That's the common case
fantasai: because things like the thing not being an abspos are more
likely to trip authors
fantasai: I think it'd be easier for devs if we can validate what we
can at parse time
fantasai: but computed-value time is going to be common too
emilio: It doesn't seem that we can take this very far, e.g. parsing
invalidation would be limited
emilio: e.g. custom property can't be validated even if registered
emilio: I think it's only wrong sides that can be parse-time
validated?
emilio: I agree in principle that validating as much at parse time as
possible is better, but in this case might not be worth it
kizu: Another perspective, not sure if I see a big difference
kizu: if we can do it at parse time it would be nice, but in practice
don't think I ever wanted to use a fallback in this case
kizu: but no strong opinion
astearns: If we do have these two modes, roman will take advantage of
them somehow
fantasai: Actually... I was thinking the opposite, if we go with the
two modes, then in the future you could set left in the top
side and I bet roman would find it eventually useful
<ydaniv> more likely devs will use `@supports`
astearns: They'd be able to use @supports for specific cases but then
might try to do that for cases we can't determine at parse
time...
fantasai: Right but those are a condition on the box
emilio: Feels weird that adding a registered property could change
the fallback behavior
emilio: Can you even drop an anchor function on a ??
emilio: but then syntax of left/top becomes subtly different, which
is not amazing but maybe fine
emilio: no strong opinion either way
emilio: Not super useful, and maybe a headache for interactions with
other feature
fantasai: That's fair
dbaron: Assume everyone agrees, but you mentioned one of the
conditions is what property it's used in
dbaron: that piece should be parse-time no matter what
dbaron: so assuming we're debating the other cases
ACTION: Editors to clarify (by adjusting the legacy wording) that
anchor() is invalid outside inset properties
<RRSAgent> records action 2
emilio: Given that, my concern about custom properties goes away
emilio: The only weird thing is having different inset properties
having slightly different syntax
<dbaron> The spec currently says "It is only valid to be used in the
inset properties."
emilio: What if you do inset: anchor(top); Is that valid or not?
emilio: but if we validate at parse time it would expand to something
invalid
fantasai: I think that convinced me
fantasai: that and we can't validate in logical properties
fantasai: so it'd be very weird to validate in a very small number of
cases
fantasai: I think we clarify by removing the mention of it being in
an `inset` properties
fantasai: the rest of these are computed-value time
astearns: So close no change (only editorial tweaks?)
PROPOSED: All conditions listed (other than which property it's used
in) are computed-value time.
RESOLVED: All conditions listed (other than which property it's used
in) are computed-value time.
CSS Values
==========
Syntax of progress() vs mix() functions
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10489
fantasai: So we have progress() and mix(), both in values-5
fantasai: They have subtly different syntax, but they both have value
then range
fantasai: progress has keywords, mix() commas
fantasai: This is inconsistent, we should try to make them consistent
fantasai: align on either commas or keywords
fantasai: Question is which direction to go for
astearns: TabAtkins mentioned mix() can't use keywords
fantasai: that's true, top-level mix ??
fantasai: well it can
fantasai: but might be better for it to use commas or something else
fantasai: We discussed at TPAC about upgradable commas
fantasai: we probably need to talk about it again
fantasai: Other advantage of commas is it's consistent with clamp()
astearns: I have a preference for keywords so it's unfortunate to not
be able to use them in mix()
fantasai: So resolution we did about keywords was disambiguating
using curly braces, then keywords would be fine here
fantasai: I think keywords are more readable in general
fantasai: but I can see the argument for consistency
emilio: Was going to argue for commas
emilio: If I know syntax uses commas, I can use both
emilio: otherwise, presumably the keywords would vary from one to the
other
emilio: so if keywords are inconsistent, the strongly prefer commas
astearns: We could make the keywords consistent, but maybe less than
optimal for one
fantasai: We could probably do of/to
fantasai: that might be workable for both
<fantasai> mix(<progress> of <start> to <end>)
<fantasai> progress(<value> of <start> to <end>)
astearns: but only if we make authors wrap values that they're
passing in in curly braces if those values contain 'of'
or 'to'.
fantasai: Right. Though we don't generally use those as top-level
values.
oriol: I'm not a big fan of adding restrictions of what mix() can
accept.
oriol: extra constraints would be confusing
oriol: so given the nature of mix() would prefer commas instead of
keywords
oriol: Also seems confusing even if you are not using one of the
keywords that we use as separators, the values could contain
keywords, and it's not visually clear where one value starts
and other ends
astearns: Commas also have the issue of values containing commas
?: would need to wrap it in braces in that case
oriol: Instead of something specific for mix(), you don't need to
worry about special keywords, just only wrap if have commas
emilio: color-mix() also uses commas
emilio: that makes me stronger for commas
astearns: Sounds like we are getting close to a resolution to use
commas as separators
astearns: for progress() to match mix()
fantasai: I think it's also beneficial because progress() is a math
function, can take expressions directly without wrapping in
calc(); and so using commas is easier to visually parse in
this case
RESOLVED: Use commas for progress()
CSS Images
==========
Mesh gradient / Freeform gradient / 2D gradient
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7648
ChrisL: We need more information here.
ChrisL: 1. PDF compatibility, need to be able to print
ChrisL: 2. Color interpolation possibilities
ChrisL: We need to know that what we produce can be rendered in
screen and print
ChrisL: There's discussion of syntax, and no agreement on which we
would go for (or both or combine)
ChrisL: Not ready to discuss here, but do need info.
PROPOSED: We need info on PDF compatibility and color interpolation
abilities of the options, so we know what is possible to
render to screen and print.
SUMMARY: We need info on PDF compatibility and color interpolation
abilities of the options, so we know what is possible to
render to screen and print.
Properties Values API
=====================
Are fallbacks provided for registered properties validated by the
CP syntax?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10455
kizu: We have weird behavior which is surprisingly interoperable but
not strictly defined
kizu: If we use a registered custom property that validates its
value, but use it in a different property, and use var(--foo,
fallback) and provide a fallback which is not accepted by this
custom property
kizu: the result is unset in all browsers
kizu: basically it is validated by the custom property, not by the
property it's applied to
kizu: in the comments Oriol and Tab agree that we should remove this
restriction
fantasai: The fallback should validate against the property, not the
custom property
emilio: +1 to removing this restriction. Also need to do more work
for fallbacks.
astearns: Removing would match the spec?
kizu: No, opposite. Implementations do what nobody expects.
kizu: But not useful.
emilio: Implementations match the spec, just spec is bad.
emilio: Don't expect compat risk, we should try to change
PROPOSED: Drop validation of fallbacks wrt their custom property.
RESOLVED: Drop validation of fallbacks wrt their custom property.
CSSOM View
==========
Expose small/large viewport dimensions of the layout viewport
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8709
ydaniv: Already resolved to export viewport object that exposes the
properties you can read regarding the layout viewport
ydaniv: on that object proposal is to expose large/small/dynamic
accessors
ydaniv: for the width/height/block/inline properties
ydaniv: so that developers can read those in JS
smfr: Are these live? do they change when you scroll?
fantasai: Small/Large are static... dynamic changes
smfr: But position changes?
fantasai: Only exposes size, not position
smfr: Do we fire an event when dynamic size changes?
ydaniv: I think we already have those
ydaniv: that's the resize event
ydaniv: Visual viewport exposes events, no proposal here to make this
also an event target
smfr: Ok
smfr: Not sure about the timing of dynamic viewport change and event
firing, might not be accurate
emilio: This is not equivalent to the visual viewport resize
emilio: The visual viewport size, I don't think it changes with the
dynamic viewport
emilio: changes when zooming in and out
astearns: So continue discussing, or resolve on adding large/small/
dynamic objects to window?
smfr: Slightly concerned about .viewport being confused with visual
viewport
emilio: But that's a different discussion
smfr: Exposing these somewhere, just unsure where
PROPOSED: We will expose large/small/dynamic as accessors with width/
height/block/inline properties; TBD on which object
ydaniv: Could also resolve on making this the layout viewport
ydaniv: Other than naming, don't think there's an objection
PROPOSED: We will expose large/small/dynamic objects representing the
layout viewport sizes as accessors with width/height/block/
inline properties; TBD on which object
PROPOSED: We will expose large/small/dynamic objects representing the
layout viewport sizes as accessors with width/height/block/
inline properties; details and which object TBD
RESOLVED: We will expose large/small/dynamic objects representing the
layout viewport sizes as accessors with width/height/block/
inline properties; details and which object TBD
Received on Wednesday, 9 October 2024 21:11:38 UTC