- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Mar 2025 19:45:09 -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.
=========================================
View Transitions
----------------
- RESOLVED: view-transition-name:auto never matches an explicit
view-transition-name:<ident> (Issue #11614:
view-transition-name: auto when matching id should
namespace)
CSS Align & Anchor Position
---------------------------
- RESOLVED: Change the way medium-safety alignment is handled to
instead invoke the scroll adjustment machinery when
handling an anchorpos fixpos element (Issue #10860:
Default safety and fixpos)
CSS Text
--------
- RESOLVED: autospacing happens *after* bidi-reordering, and we'll
add a complex example to the spec (Issue #10803: Spacing
across element boundaries for BiDi content)
CSS Sizing
----------
- RESOLVED: No normative change to spec, but add example like Oriol's
and make the implication clearer in the spec. (Issue
#10721: Content contribution of
min-inline-size:fit-content and
max-inline-size:fit-content)
- RESOLVED: For the final step in determining natural sizes, use the
determined aspect-ratio to coerce the block size to match
(Issue #11236: How to transfer intrinsic keywords via
aspect ratio?)
- RESOLVED: Add a 'size' shorthand property (for 'width'/'height'),
no relation to @page's 'size' descriptor (Issue #820:
Adding a 'size' shorthand for 'width'/'height')
- When discussing issue #11716 (Resolved value of min size properties
doesn't round-trip) the group discovered that the proposed
behavior may already be done in flex and grid. There wasn't time
to discuss further on the call, but folks will investigate
further to resolve next week.
====== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Mar/0008.html
Present:
Tab Atkins-Bittner
Kevin Babbitt
Oriol Brufau
Keith Cirkel
Yehonatan Daniv
Elika Etemad
Robert Flack
Simran Gill
Daniel Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
Ian Kilpatrick
Roman Komarov
Vladimir Levin
Alison Maher
Florian Rivoal
Cassondra Roberts
Alan Stearns
Miriam Suzanne
Joshua Tumath
Sam Weinig
Regrets:
Chris Harrelson
Bramus Van Damme
Scribe: TabAtkins
Scribe's scribe: noamr
Administrative
==============
fantasai: Tim wanted to publish a FPWD of Forms?
astearns: Yup, people should weigh in on the issue
astearns: will take it up next week
<fantasai> https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2715192840
astearns: maybe should have co-editors?
fantasai: I think jarhar has been co-editing, functionally speaking
astearns: Luke would be a possibility too, they've been doing PRs.
I'll get some co-editors together for next week.
<astearns> https://wiki.csswg.org/planning/newyork-2025#new-york-f2f-april-2025
astearns: First - register for NY meeting
astearns: Attending in-person *or* virtually, put availability in the
wiki so I can construct the agenda
CSS View Transitions
====================
view-transition-name: auto when matching id should namespace
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11614
vmpstr: We added view-transition-name:auto
vmpstr: matches the VT name based on the element's ID attribute, and
acts as match-element otherwise
vmpstr: This name isn't exposed anywhere, it's "auto" in
serializations
vmpstr: but wanted to clarify that the ID ident shouldn't match
another VT that specifies a manual ident that happens to be
the same
vmpstr: Like `view-transition-name: foo` on one element and
`view-transition-name:auto` on an element with id="foo"
shouldn't match
astearns: Looks like there's agreement in the thread
astearns: Anyone in the room actually want the behavior we're
prohibiting?
<TabAtkins> sounds fine to me
<TabAtkins> no opinion either way, really, happy to defer to editors
<bkardell> makes sense
<noamr> +1
fantasai: I thought that's what we'd adopted originally, that the ID
would only be used to link elements together, not something
expose-able to other CSS. So this makes sense to me.
vmpstr: proposed: view-transition-name:auto will never match an
explicit view-transition-name:<ident>
astearns: any objections?
RESOLVED: view-transition-name:auto never matches an explicit
view-transition-name:<ident>
CSS Align & Anchor Position
===========================
Default safety and fixpos
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/10860
TabAtkins: A corner case in anchor positioning, common in certain
situations. Original containing block, plus "safety". If
something overflows the containing block it can still
overflow until its original containing block
TabAtkins: The problem is that for fixed positioning you'd get some
bad behavior, because the original containing block is the
viewport. If you scroll a bit you'd get bad overflowing
behavior
TabAtkins: Proposing to always to default a fixed position element to
unsafe element, rather than default to the medium safety
TabAtkins: This shouldn't have real effects to users of the feature,
the element should remain on screen when possible, but
it's a bit of a tweak
astearns: Is this modifiable by the author?
TabAtkins: This is just the default behavior if you don't say safe/
unsafe on one of the alignment keywords
TabAtkins: We shouldn't have the default do the wrong thing for
common scenarios. We just propose to change the default
safety
fantasai: Re-adjust it to be as if it was safe?
TabAtkins: The medium safety is correct but can't be implemented.
Current definition of medium safety rely on layout
information but not on scroll information
TabAtkins: Anchor position can respond to scrolling. In order to do
the medium safety, it can't work in the way defined in the
space. We need to define it as unsafe in the layout and
then correct it using the scroll adjustment behavior
TabAtkins: Rather than layout time behavior creating the medium
safety, it needs to be created by scroll adjustment, in
order to be compositable
<fantasai> https://github.com/w3c/csswg-drafts/issues/10999#issuecomment-2430366312
<fantasai> This never got resolved either
fantasai: I am glad that we're not changing the user observable
behavior; no opinion about how we get there
<TabAtkins> proposed: change the way medium-safety alignment is
handled to instead invoke the scroll adjustment machinery
when handling an anchorpos fixpos element
<TabAtins> (note to the above IRC-only comment; the resolution was in
the preceding comment, the edits were for that)
RESOLVED: Change the way medium-safety alignment is handled to
instead invoke the scroll adjustment machinery when
handling an anchorpos fixpos element
CSS Text
========
Spacing across element boundaries for BiDi content
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10803
fantasai: So text-autospace inserts spaces between "changes" in a
script
fantasai: If you have Chinese with a little English, there should be
some gap around the English otherwise it feels cramped
fantasai: Question is what to do with bidi text
fantasai: we don't insert space between Chinese text and a *symbol*,
only between Chinese text and a letter
fantasai: so if you had a stretch of rtl text, like Hebrew that ends
with a symbol
fantasai: and you give it a direction so it all flips
fantasai: so symbol is on the left, Hebrew letters on the right
fantasai: Chinese text before and after
fantasai: if you insert space before reordering, you'll put it on the
left side, which ends up between the Chinese text and the
symbol, while the Hebrew and Chinese don't get a space
fantasai: So correct answer is to manage the space in visual order,
after bidi reordering
fantasai: This is challenging, it interacts with linebreaking in
awkward ways. Hard to get perfectly right without maybe
some backtracking
fantasai: so I think the correct answer is visual spacing
fantasai: For practical purposes, might tolerate getting it wrong in
some complex cases
florian: Do we need to spec the allowance for getting it wrong?
florian: Or just spec the right thing and expect people to get it
wrong sometimes, but they should still try?
fantasai: I'm not sure
fantasai: I think it's important to make sure we get right - if both
sides require spacing, it's done correctly, never get
double space on one side
fantasai: that's minimum bar
astearns: I think we should specify what we want to see, without
allowance, and only do that "getting it wrong is allowed"
part if we have to
fantasai: I think that's reasonable.
fantasai: If authors are running into problems with certain cases,
they can complain, and then we'll know those cases matter.
astearns: So proposed resolution is we specify that autospacing is
done after bidi reordering
astearns: and you should never double auto-space any side
fantasai: Yeah, that's implied
florian: Do we want to add a note about it being hard?
TabAtkins: Useful to acknowledge if something is significantly
difficult
TabAtkins: Here be dragons, when implementing
fantasai: I think they'll notice
astearns: Would be good to have at least one example, hopefully we
can find a real-world example
florian: Could have a note which is less silly than my earlier
phrasing. "CSSWG acknowledge that the interaction of this
with line-breaking may be challenging to implement"
fantasai: or, as bkardell suggests, literally say "here be dragons"
astearns: [restates proposed resolution]
RESOLVED: autospacing happens *after* bidi-reordering, and we'll add
a complex example to the spec
CSS Sizing
==========
Content contribution of min-inline-size:fit-content and
max-inline-size:fit-content
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10721
oriol: When you're computing intrinsic contribution of a fit-content
element, what should happen?
oriol: If you use fit-content on the preferred sizing property, it's
clear that for the purpose of computing min-content
contribution, you treat it as min-content; for max-content
contribution, you treat it as max-content
oriol: but if you use this keyword on min or max sizing properties,
it's less clear what should happen
oriol: What webkit does is it just ignores the keyword, so in a min
property it treats as 0, in max it treats it as none
oriol: Blink used to have the same behavior, but changed to align
with Firefox
oriol: Firefox behavior is, when computing intrinsic contributions,
fit-content acts as min-content in min sizing property, and as
max-content in a max sizing property
oriol: I was implementing in servo and I think there's a better
behavior, and I think it's what's actually specified in the
spec, and is a bit simpler to implement
<oriol> https://github.com/w3c/csswg-drafts/issues/10721#issuecomment-2414743959
oriol: Some testcases ^^^
oriol: In this testcase, magenta wrapper has a fixed width - first
very narrow, then between, then wider
oriol: element with black border is inline-block, so shrink-to-fit
oriol: the inline-block contains one element with `width` to a huge
amount, and max-width:fit-content
oriol: so webkit ignores the max-width so the width makes it all
explode
oriol: Gecko and blink treat it as max-content, so the inline-block
is always sized as max-content
oriol: I think the servo column is better. Do the same for the three
sizing props
oriol: you always treat it as min-content when doing min-content
contribution, and similar for max, for all three properties
oriol: So if magenta wrapper is narrow you'll use the min-content
contribution, if wide you'll use the max-content contribution,
and if between it'll be between
oriol: I think this is a better match for fit-content, trying to fit
into the container
oriol: so I propose the spec is right, and servo is right, and other
browsers should match
fantasai: Thanks for the fantastic examples
fantasai: As editor, I think Servo's impl is correct. It reflects the
author's request
fantasai: In 2.1's definition of min/max sizing properties, it says
you literally run layout by subbing in the value for
'width' and then clamp appropriately; this matches that
behavior as well
iank: I think this is likely fine.
iank: Hopefully no compat issues, but on the surface it's not too
difficult for us to do
astearns: So are we resolving the spec is correct?
oriol: Yes
iank: It's not obvious to me that the spec is correct, so clarifying
would be good for the future
oriol: At end of the issue I posted the quote of the spec that I
think is backing the servo behavior, we can clarify or add
some examples
<TabAtkins> examples++
fantasai: The spec doesn't make a distinction between what
fit-content size means based on property, so I don't think
it can support an interpretation that it works differently
in the different properties
astearns: So let's make that explicit
astearns: So proposed resolution is we add examples like Oriol's and
make the implication clear in the spec
RESOLVED: No normative change to spec, but add example like Oriol's
and make the implication clearer in the spec.
How to transfer intrinsic keywords via aspect ratio?
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11236
iank: Replaced elements have three things
iank: natural width, natural height, natural aspect ratio
iank: You can have a natural width of 20, height of 10, and ratio
would be 2/1
iank: it used to be possible (in svg, at least) to have the natural
sizes not match the aspect ratio
iank: This is more of a problem now with aspect-ratio property
iank: can have natural width/height of 20px and 10px, and an
aspect-ratio property of 1/1
iank: so what happens
iank: There's places where you're sizing a replaced element where you
only look at natural sizes, but then the aspect ratio comes in
(to transfer min-height to a width, for example), and they're
disjoint
iank: There's a step which normalizes the natural sizes and aspect
ratio
iank: I think simplest answer is we coerce the natural sizes to match
the aspect ratio
iank: so if your natural sizes are 20px/10px, and aspect-ratio is
1/1, we coerce the block size to match and it becomes 20px/20px
natural size
iank: We have this normalization step for SVG. You can specify only a
natural width, no natural height, yes natural aspect-ratio, and
we harmonize the three together
iank: so I think we should do the same when all three are specified
but disagree
astearns: When you say you don't care, you example had us adjusting
the block natural size
astearns: is the other option adjusting inline size...?
iank: You could adjust block/inline/width/height
fantasai: Or larger/smaller
iank: Mild preference for adjusting block size
fantasai: I think if we do this fixup, adjusting the block size makes
sense
fantasai: in most layout algorithms block size is the dependent size
fantasai: aspect-ratio in general works that way, it prioritizes that
dependency direction
oriol: Yeah in my second comment, I say we adjust the block size when
transferring. So I'd prefer to be analogous
<TabAtkins> +1
dholbert: Makes sense about aspect-ratio property
dholbert: Without aspect-ratio I think this doesn't matter? SVG says
to derive the intrinsic aspect-ratio from the intrinsic
sizes if they're present, ignoring the view-box. Is that
right, Ian?
iank: I thought there was a case...
iank: viewbox aspect ratio of 1/1, width=10 height=0
iank: in that case the natural sizes are 10/0
dholbert: Right, the 0 is equivalent to not having a size, not
worried about that corner case
iank: Okay, then yeah I think it's otherwise correct, we can discuss
offline if necessary
iank: A little icky with a 0 width or height, I think we have some
compat for it rendering as 0 height, and this would change it
to non-zero
TabAtkins: So ignoring SVG complications, we can limit this to just
aspect-ratio property?
iank: I think we want this for aspect ratios generally
iank: This is part of the normalization step, svg's aspect-ratio
comes from the width/height, and only if that doesn't exist
does it come from the viewbox
iank: so now we'll take aspect-ratio property into account
iank: This can also happen in contain-intrinsic-size, it gives a
natural width/height
iank: so this can't just be for the aspect-ratio property, need fixup
to work consistently
<dholbert> this is the SVG spec text I'm remembering RE getting
aspect-ratio from width/height (if present), and falling
back to viewBox (
https://svgwg.org/svg2-draft/coords.html#SizingSVGInCSS ).
Just noting for reference; I'm on board with what IanK
just described
astearns: So this just applies to replaced?
[some confusion, but yes]
iank: Proposed resolution: for the final step in determining natural
sizes, use the determined aspect-ratio to coerce the block size
to match
astearns: questions? objections?
RESOLVED: For the final step in determining natural sizes, use the
determined aspect-ratio to coerce the block size to match
Adding a 'size' shorthand for 'width'/'height'
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/820
fantasai: Wow this was old.
fantasai: Not clear what to do here, but people want it solved
fantasai: Complication is there's an existing size property in @page
rules
fantasai: and it's not equivalent to setting width/height
fantasai: width/height apply to the page area
fantasai: this is implemented by PDF renderers
fantasai: Added this after chatting with emilio, who suggested maybe
we just treat 'size' in @page specially, so they set a
different size property, while everywhere else it's a
shorthand
fantasai: so wanted to know if it's viable
<fantasai> https://github.com/w3c/csswg-drafts/issues/820#issuecomment-810626883
<ntim> I like the idea
astearns: Seems a little icky to have different processing based on
where 'size' comes up
astearns: but maybe in this case it's reasonable
<TabAtkins> (I think there's not really any better solution. Also
slightly icked but okay with it for the benefit.)
florian: Yeah, unfortunate, but since the weirdness is so scoped it's
probably okay
oriol: In @page, it has descriptors not properties
oriol: so a name conflict isn't *great* but not a big deal
technically. Can just say that 'size' descriptor and 'size'
shorthand are different
emilio: I think this is the only way to make it work
emilio: but maybe it could be cool to make 'size' in @page a legacy
alias for some other name, like 'page-size'?
emilio: that would be easier to implement, I think, then I don't need
to deal with the name conflict as much.
<florian> +1
emilio: and maybe less confusing long term
astearns: Do you have a mechanism to only apply an alias in one
at-rule context?
emilio: Yes, easily
emilio: just within the @page descriptor, if descriptor name is
'size' return 'page-size'
<fantasai> https://github.com/w3c/csswg-drafts/issues/820#issuecomment-544582026
fantasai: We'd previously resolved to make it an alias and have
page-size be the name
fantasai: Response we got was some products support JS and 'size' has
been supported as long as PDF renderers have existed
fantasai: so we could do aliasing, but would have to make sure it
doesn't break CSSOM
emilio: Yeah, aliases already work nicely for that
ntim: Any usage data on 'size'? I guess Elika has answered the
question
ntim: Any browser have data?
fantasai: Primary usage isn't in browsers, it's in pdf renderers. So
big market difference in both content and userbase
emilio: I think browsers do support 'size' in printing, it's fairly
used
iank: Yeah people generate PDFs from browsers all the time, and do
use the 'size' descriptor
iank: So the markets are actually pretty overlapping
florian: And epub readers too
florian: At least notionally, interactive pages user agents
ntim: Common on web sites though?
florian: When you print a web site, yeah, reasonably
iank: Very common in enterprise use-cases to have printable pages
iank: and they use @page on those
<fantasai> https://www.w3.org/TR/css-cascade-5/#aliasing
ntim: I ask because in webkit, @page is pretty poorly maintained and
we haven't seen many bug reports
iank: I suspect we have the best support among browsers here, and
enterprises are just targeting Chrome for printing webapps
astearns: So proposed resolution is we add 'size' shorthand property
that has nothing to do with '@page/size'
astearns: Concerns?
RESOLVED: Add a 'size' shorthand property (for 'width'/'height'), no
relation to @page's 'size' descriptor
ntim: Would longhand be physical or logical
fantasai: I think would have to be physical because that's how we
generally handle shorthand properties with both directions
fantasai: We map to the physical directions by default
florian: Would be good to have a switch but we don't have yet
ntim: Possible confusion with inline-size/block-size, versus width/
height
ntim: but otherwise fine with this
emilio: Should we discuss the alias in @page?
astearns: Separate issue
emilio: I'll file one
Resolved value of min size properties doesn't round-trip
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11716
oriol: Sizing 3 changed the initial value of min size properties. Was
'0', now is 'auto'
oriol: but for back-compat, on block/inline-block/inline/table, when
you use gCS() 'auto' can serialize as 0
oriol: Problem is Sizing 4 added aspect-ratio, and that makes 'auto'
behave differently than 0 on those boxes
oriol: so if you use gCS() you see 0, but it has a different meaning.
if you assign it back, the value changes.
oriol: So I propose if aspect-ratio is a non-initial value, the "auto
can serialize to 0" hack isn't applied
oriol: hopefully web compatible to change
iank: I'm a little concerned. we already had auto problem for flex/
grid, min-size:auto was treated differently too
iank: didn't roundtrip there either
iank: A little concerned that if gCS() starts returning 'auto' things
could break. scared about compat.
iank: mostly because this is the default
iank: but width/height also don't fully roundtrip anyway
emilio: I think they do in gecko, blink has some bugs with scrollbars
iank: Nah, height:auto vs explicit value changes definiteness, which
affects percents
iank: so the idea that width/height roundtrips is a spec fiction
emilio: Similar concern. I think in principle we should probably do
this, but it does scare me compat-wise
emilio: Can try it, see what happens
emilio: Middle ground, maybe less scary, is doing this for layout
boxes where we know it makes a difference, like for flex items
emilio: but still not sure it's worth
oriol: You mentioned flex items, for those it's already the case,
'auto' serializes to 'auto'. it only serializes to 0 for
block/inline/inline-block/tab
oriol: So only *those* will change, and only when aspect-ratio is a
non-initial value
astearns: Out of time. Can resolve to try fixing this roundtripping,
or take it back to the issue. Ian, emilio, preference?
iank: Can we put it at start of call next week? want to check some
things. I didn't realize we were already doing this for flex/
grid items.
emilio: Same. I think this makes it a bit less scary.
astearns: So let's take it back to the issue. We'll revisit next week.
astearns: HDR breakout in a few hours
Received on Wednesday, 12 March 2025 23:45:42 UTC