- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Jun 2024 19:22:24 -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.
=========================================
CSSOM
-----
- There still is not general agreement on an overall approach to
shorthandifying properties (Issue #8398: How safe is it really to
shorthandify properties?). Some group members are proposing a
general guidance against shorthandifying well-established
properties, but others preferred investigating mitigation
strategies to ensure shorthandification was still possible when
justified.
CSS Rhythm
----------
- RESOLVED: Switch block-step-insert margin and padding values to
margin-box | padding-box and add content-box, with
attention to impact on aspect-ratio (Issue #10486: Add
`content-box` to `block-step-insert` so authors can have
content grow instead of adding space)
Anchor Position
---------------
- RESOLVED: Rename position-try-options to position-try-fallbacks
(Issue #10395: Rename `position-try-options` to
`position-try-fallbacks`)
View Transitions
----------------
- RESOLVED: ::view-transition-old` renders new live image (if
available) if old element is offscreen at capture time
(Issue #8282: Ignore offscreen elements from
participating in transitions)
- RESOLVED: The geometry animation on the `::view-transition-group`
pseudo is same as before (Issue #8282)
CSS Position
------------
- RESOLVED: No change to specification (Issue #8040: Containing block
of dialog fixed position children)
CSS Contain
-----------
- RESOLVED: Use Chrome/Firefox behavior (Issue #10268: Zoom and
container queries)
- florian introduced a possible solution to issue #5648 (contain:size
shouldn't fragment as monolithic), but there wasn't strong
implementor interest. The group ran out of time on the call
before they could discuss the use case further, though.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jun/0001.html
Present:
Rachel Andrew
Rossen Atanassov
Kevin Babbitt
Oriol Brufau
Stephen Chenney
Keith Cirkel
Emilio Cobos Álvarez
Matthieu Dubet
Elika Etemad
Robert Flack
Chris Harrelson
Mason Freed
Brian Kardell
Jonathan Kew
Ian Kilpatrick
Roman Komarov
Una Kravets
Vladimir Levin
Khushal Sagar
Miriam Suzanne
Luke Warlow
Regrets:
Chris Lilley
Bramus Van Damme
Lea Verou
Chair: Rossen
Scribe: chrishtr
Scribe's scribe: fantasai
CSSOM
=====
How safe is it really to shorthandify properties?
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8398
fantasai: This was a question we discussed during the F2F
fantasai: Wanted to follow up and see what the issues are, and what
it takes to resolve them
fantasai: in order to make progress
chrishtr: For well-established CSS properties (have significant usage
across browsers), it's not worth it to shorthandify them
after the fact
chrishtr: so we shouldn't do that
chrishtr: It's not worth the effort / risk / churn / cost of
implementation and testing and potential compat risk
florian: You're right that there is a significant cost, churn, etc.
and so we shouldn't do it lightly
florian: but if there are strong reasons for a particular case we
might want to do it despite the risk and cost
florian: for such cases we should figure out how to do it, for such
rare cases
fantasai: This is a kind of important extension point for CSS, so
it'd be good to find out how we can make it less risky, in
cases where it's justified
rossen: Should we continue such discussion in the issue?
rossen: or should we accept the proposed resolution, and then
continue to work on the issue for exception situations?
<fantasai> https://github.com/w3c/csswg-drafts/issues/8398#issuecomment-2123561486
fantasai: chris are there issues other than the ones Tab mentioned on
issue 8398?
chrishtr: My other concerns are the ones I mentioned in the comment
(developer confusion/churn, cost of implementation, ...)
chrishtr: don't know of specific compat risks other than then ones
mentioned in Tab's comment on 8398 above
<dbaron> (with the caveat that I think the description of the first
of Tab's 2 issues is more complicated than what Tab
described, as we discussed at the face-to-face)
flackr: Maybe we could resolve not to do standard shorthandification,
but if there was a way we can do it that avoids compat risk
we could accept that?
fantasai: If we don't have a mitigation then it would have to be on a
case-by-case basis
<emilio> +1 to fantasai
oriol: Wondering what is meant by "well-established", maybe we could
experiment with a specific case and learn more?
chrishtr: What I meant by well-established is a CSS property that has
been around a while and is relatively widely used on sites
oriol: For particular cases it's still possible it wouldn't break
anything
oriol: Is the position that implementations don't want to take the
risk?
chrishtr: Yes, Chrome would prefer to spend its effort elsewhere
florian: Not shorthandifying would lead to us introducing more
longhands when designing new features, for example we often
design a simpler feature in the first iteration
florian: whereas shorthandifying we'd potentially be able to have
fewer
florian: Think we should still try to find mitigations
<fantasai> +1 florian, we've done this multiple times
florian: We shouldn't do things with risk without limitation, but
shouldn't ban it either
florian: Don't think we should ban it
flackr: Don't think anyone is proposing a ban
florian: Proposed resolution would amount to a ban?
CSS Rhythm
==========
Add `content-box` to `block-step-insert` so authors can have content
grow instead of adding space
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10486
fantasai: This is an issue from Jen where she pointed out that
block-step-insert has two values: margin and padding.
pointed out use cases for content.
fantasai: These names don't align with other naming
<fantasai> block-step-insert: margin | padding
<fantasai> block-step-insert: margin-box | padding-box | content-box
fantasai: Propose to change to add the -box suffix and also include
the content variant
<florian> +1
rossen: Sounds reasonable, don't know why we didn't do content before
fantasai: Just because it's an early spec, probably accidental
lwalrlow: Has any implementation shipped?
fantasai: No
lwarlow: Cool, then sounds good
iank: Does setting this property effectively override aspect-ratio
for an image?
fantasai: Yes. But maybe it shouldn't, good point?
iank: If it doesn't override aspect-ratio, how does it work with the
original use case mentioned?
fantasai: If you set a fixed width it's like setting a height which
affects aspect-ratio
fantasai: but if width were auto then maybe it makes sense for it to
pass through
iank: Stretch is also involved
iank: for grid and flex
fantasai: Currently this property doesn't apply to flex or grid, but
might happen in the future
iank: Concerned about all sorts of complications for replaced elements
fantasai: Should probably enter the algorithm in a similar place to
min-height and min-width
iank: Just needs to be documented explicitly in the spec as to where
it is in the order of operations. Probably twice, similar to
aspect-ratio
fantasai: Should be doable for block flow, but flex and grid could be
more complicated
iank: More concerned about replaced elements than flex or gird
fantasai: Will write up proposed edits and send to you (iank) for
review
rossen: Are we good to go for the proposed resolution?
fantasai: Yes, just need to be careful about replaced element
RESOLVED: Switch block-step-insert margin and padding values to
margin-box | padding-box and add content-box, with
attention to impact on aspect-ratio
Anchor Position
===============
Rename `position-try-options` to `position-try-fallbacks`
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10395
fantasai: When we were designing position-try longhands, the
reordering option reordered all of the options
fantasai: Now it's really just fallbacks that are there - just the
base style and the current trys
fantasai: Suggesting we could rename to fallback to reflect this
<miriam> +1 it's clearer
<emilio> +1
<lwarlow> +1 from me
<bkardell> +1 (I was a 👍 on the issue already)
una: Wanted to say that I don't necessarily have strong opinions on
this, but Tab did. Move to next meeting?
rossen: Seeing strong consensus here, can always re-open. Any other
concerns from anyone?
RESOLVED: Rename position-try-options to position-try-fallbacks
View Transitions
================
Ignore offscreen elements from participating in transitions
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8282
khush: This is a continuation of something discussed at the F2F
khush: We had a high-level resolution that we should avoid capturing
things offscreen, and in particular not capture images for them
khush: Today I'd like to go into UA styles for this
khush: for something in the old and new state, proposal is that we
keep size animations
<fantasai> +1
khush: Another question was whether to keep the pseudo element for
the old thing. Propose to keep it because there developer code
expects it
khush: "there is developer code that expects it"
khush: Think there would be less of a compat risk if the new image
had something instead of nothing?
khush: By default you get a cross-fade in these cases, but don't want
to do that and instead just show the new image
khush: Propose that there be a 0->0 opacity animation for the old and
1->1 for the new. Reiterating that all this is to minimize
compat risk.
khush: Also propose removing mix-blend-mode: plus-lighter
khush: For exit animations, seems less clear
khush: in these case you're animating an element that has no content
khush: One option is to generate a new pseudo and animations are
technically there but irrelevant but it doesn't exist, another
option is to have no pseudo
fantasai: I agree that the option about not generating a pseudo is a
bad option, we shouldn't do that
fantasai: As for generating the pseudo but having no image backing
it, the whole point is for cases where it's offscreen
before and after right?
khush: Propose we do it based only on the old state, because it has
to be done at the beginning of the animation.
khush: Even for cases where things animate on screen it seems ok to
skip the image because the user never saw the old content
anyway
flackr: Reason to keep around the pseudo is because the developer
might have animation keyframes for it
fantasai: The alternative would be that the old pseudo has no image
and the new one is 1->1. Either way you're just showing the
new image
flackr: Default behavior is the same in either case
khush: That's why I'm lukewarm on it, because it's hard to say what
is less compat risky without deeper analysis
fantasai: Would it be a problem if we set up the cross-fade animation
as normal?
khush: If you set up the cross-fade as normal, then you're assuming
the pseudos are all set up and it cross-fades?
khush: Yes, but it makes it harder to optimize out in the browser
implementation
fantasai: If it's really needed for optimization that's fine, but
otherwise just due to implementation complexity..
vmpstr: We can probably optimize the animation by detecting this
situation
khush: If we keep the default cross-fade it is harder to detect...
vmpstr: Harder optimization but plausible to do so
khush: If needed I can find a hack to optimize
flackr: From a developer perspective it's better not to have
animations be different in these situations
khush: Remaining questions is just about not having cross-fade, and ?
khush: Ok resolving on the first two question and then investigating
implementability of avoiding cross-fade changes
<flackr> +1
<khush> `::view-transition-old` renders new live image (if available)
if old element is offscreen at capture time
RESOLVED: ::view-transition-old` renders new live image (if
available) if old element is offscreen at capture time
<khush> The geometry animation on the `::view-transition-group`
pseudo is same as before.
RESOLVED: The geometry animation on the `::view-transition-group`
pseudo is same as before.
CSS Position
============
scribe: flackr
Containing block of dialog fixed position children
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8040
chrishtr: I propose closing this no change to specification
chrishtr: We resolved 9939 at the F2F, having to do with static
position. Given that, emilio mentioned he's good with this
resolution given that change.
chrishtr: There's no changes for fixed pos elements in top layer,
they'll continue to be according to their position in the
layout tree as re-positioned
Rossen: Any objections?
RESOLVED: No change to specification
CSS Viewport & Contain
======================
scribe: chrishtr
Zoom and container queries
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/10268
emilio: What Firefox and Chrome are doing for container queries and
zoom in terms of coordinate space makes sense
rossen: Propose to specify the Chrome and Firefox behavior
rossen: Would like to hear from WebKit
matthieu: Don't have a strong opinion, if what Chrome and Firefox are
doing makes sense then let's go with that
RESOLVED: Use Chrome/Firefox behavior
CSS Contain
===========
contain:size shouldn't fragment as monolithic
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5648
florian: We previously deferred this issue to contain level 2
florian: Idea is that size containment has two requirements: if it
has size containment and it's in the context of
fragmentation, then you don't want content in the box to
change the size of the sum, and not change the size of each
fragment
florian: For the first, it's good enough for it to always have a
fixed size
florian: However where you fragment and size of fragments depends on
the content of this box
florian: To avoid this problem we defined size containment to force a
monolithic behavior
florian: This suffices, but may be too restrictive
florian: e.g. if you have a box that is tall enough to have 4 but
have 5 and then could have two columns of 2.5, but with
monolithic it'd be wasting space?
florian: Suggestion is to introduce a concept "quasi-monolithic" that
has most but not all of the concepts of monolithic
<florian> Quasi-monolithic boxes are similar to monolithic boxes:
<florian> forced breaks within a quasi-monolithic box must be ignored
by the box’s own fragmentation context
<florian> quasi-monolithic boxes should not be fragmented
<florian> if a quasi-monolithic box needs to be fragmented, the box
is sliced at a point which does not depend on the box's
content, only on its size and its position within its
fragmentation context.
<florian> However, unlike monolithic boxes, when a quasi-monolithic
box is thus broken up, its content may be fragmented and
laid out normally within each of the fragments instead of
being graphically sliced—although graphically slicing is
also allowed.
florian: The difference between quasi-monolithic and monolithic is
that you can fragment within the child boxes (?)
florian: Browsers would gain more options for how to spread content,
which might be better for printing and multicol readability
florian: Should we allow this new thing in the spec? Give up?
dholbert: You mentioned that quasi-monolithic boxes should avoid
being fragmented. Wondering what that means in the
situation of a quasi-monolithic box of 1/3 page height but
it just barely goes off the end, should we move the whole
thing to the next page or cut it?
florian: Should avoid fragmenting if possible but some leeway
florian: Don't remember how much leeway there is
iank: I'd err on the side of keeping it monolithic for now.
iank: not hearing strong developer feedback
iank: In some cases Chromium is the only implementation that treats
break-inside as non-monolithic. Advised people to use contain:
size for some cases.
iank: Prefer no change to spec for now
<dholbert> correcting earlier notes, iank had actually said "Chromium
is the only implementation to treat `break-inside:avoid`
as monolithic"
florian: If there is no implementer interest then perhaps we should
just close the issue
florian: but wanted to raise this because developers might want that
fragmentation, and used container queries and the result was
monolithic that could be bad. Maybe better to offer
implementation options?
miriam: We're running into a case where people set containment
explicitly, and where they set it implicitly (e.g. via
container queries). For container queries the minimum
containment required is desired. Maybe there is a way to
address that with new modes or keywords.
Received on Wednesday, 26 June 2024 23:22:57 UTC