- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 4 Dec 2024 20:23:13 -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 Grid/Masonry
----------------
- The group discussed the proposals to decide if Masonry should be a
part of Grid or a separate system (Issue #11243: Masonry Syntax
Debate)
- Presentations were given by both sides explaining their views and
reasoning
- Masonry as a separate display type:
https://lists.w3.org/Archives/Public/www-archive/2024Dec/att-0002/Masonry_presentation_to_CSSWG_____Dec_4_2024.pdf
- Masonry as a part of Grid:
https://lists.w3.org/Archives/Public/www-archive/2024Dec/0003.html
- They also discussed the TAG feedback which argued for a general
approach of integrating display types further:
https://github.com/w3ctag/design-reviews/issues/1003#issuecomment-2489688718
- At the end of the timebox the group did a strawpoll to see if there
was a preference developing, however the results continued to be
split. The two viewpoints will continue working on coming to a
consensus approach.
CSS Snapshot
------------
- RESOLVED: Add Scroll Anchoring 1, CSSOM 1, and Color 5 to Rough
Interop; add Nesting once it's republished. (Issue #9793:
Add specs to Rough Interoperability)
- RESOLVED: Add Selectors 4 to Rough Interop (Issue #9793)
CSS Sizing
----------
- There was an openness to clarifying the definition for issue #10605
(Intrinsic size of <img> / <video> with aspect ratio but no
definite size) however more thought was needed around describing
the desired behavior so discussion will go back to github.
Writing Modes
-------------
- RESOLVED: Allow consistent sideways-* and vertical-* writing modes
to share a BFC (Issue #10714: Allow sideways-x and
vertical-x to share a block formatting context?)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Dec/0001.html
Present:
Rachel Andrew
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Oriol Brufau
Stephen Chenney
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Chris Harrelson
Daniel Holbert
Ethan Jimenez Vargas
Jonathan Kew
Roman Komarov
Chris Lilley
Alison Maher
Jen Simmons
Gaurav Singh Faujdar
Alan Stearns
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Lea Verou
Jason Williams
Jeffrey Yasskin
Sebastian Zartner
Scribe: fantasai
Scribe's scribe: TabAtkins
CSS Grid/Masonry
================
Masonry Syntax Debate
---------------------
github: https://github.com/w3c/csswg-drafts/issues/11243
Slides from Jen Simmons:
https://lists.w3.org/Archives/Public/www-archive/2024Dec/att-0002/Masonry_presentation_to_CSSWG_____Dec_4_2024.pdf
Slides from Alison Maher:
https://lists.w3.org/Archives/Public/www-archive/2024Dec/0003.html
alisonmaher: [intros the topic]
alisonmaher: Several properties behave differently in each, or don't
apply, so we think a new display type would be better.
alisonmaher: Plus we can define a better default value for the
template tracks, creating an automatic masonry instead
of a single column
alisonmaher: Regarding grid fallback, needing one is a temporary
problem, so should focus on the future
alisonmaher: authors should make explicit fallback, to avoid surprises
alisonmaher: Positioning in masonry is simpler than grid, it's only
placed in 1 axis instead of 2
alisonmaher: Grid is confusing because authors might make a mistake
about which axis they are placing in (rows vs columns)
alisonmaher: separate model only has one axis
alisonmaher: this allows switching the axis easily
alisonmaher: Shorthands also are better with separate shorthand. Grid
shorthand is complicated, hard to use. Masonry shorthand
is easier because don't need to remember the order
alisonmaher: placement works differently in grid vs masonry
alisonmaher: Dense packing is also different: for grid can place in
any empty slot, but due to performance considerations
for masonry current proposal restricts to same-sized
track
alisonmaher: Masonry also has different intrinsic sizing rules, with
auto-placed items affecting all auto-sized tracks not
just the one they end up in
alisonmaher: alignment is also very different, open questions about
how this works in the masonry axis
alisonmaher: this means grid and flexbox are quite different in how
they behave
alisonmaher: in masonry layout auto-placed subgrids don't inherit
line names
alisonmaher: we expect there to also be other changes for submasonry/
subgrid that will lead to divergences
alisonmaher: Integrating masonry into grid will lead to spec bloat,
will be harder to teach, and lead to developer confusion
alisonmaher: Conclusion: masonry should be a separate display type
jensimmons: [intro slide]
jensimmons: At this point decision is about syntax -- mental model.
Behavior is same in both.
jensimmons: [reviews basic case]
jensimmons: Choice to Just Use Grid is extending Grid L1. [shows
example of grid vs masonry photo grid, with one
difference - the grid-template-rows: collapse line]
jensimmons: New layout type, creates a separate tool with separate
syntax that's similar but not the same as what exists
jensimmons: [shows table of properties being added]
jensimmons: We don't believe there's a compelling argument to add so
many new properties to CSS
jensimmons: Both have properties for defining tracks; defining
masonry axis
jensimmons: both have ways to define placement, and both have a new
slack property
jensimmons: both have shorthand, and a gap property
jensimmons: and both have ways to implicitly size tracks
jensimmons: more significant difference is grid-auto-flow vs
masonry-direction/fill/flow
jensimmons: Chromium argues that their new syntax is more
understandable. We disagree, just use grid-auto-flow
jensimmons: Other major difference is template syntax
jensimmons: Here's a column example using the template syntax.
Identical in grid 1, and masonry in both
jensimmons: When you layout rows in grid, template syntax is a bit
different -- you stack the template names to physically
diagram the names for the rows
jensimmons: Just Use Grid re-uses this syntax exactly; but new
masonry layout uses the column syntax for rows.
jensimmons: Chrome believes it's less confusing to use the same
syntax in rows vs columns; but we believe it's better to
use the same syntax between grid rows and masonry rows
jensimmons: Other difference is the auto-flow -- grid's indicates the
primary fill direction, Chrome believes this doesn't make
sense and changed it to match the orientation of lines
jensimmons: Debatable which is better. Might make sense if we had
time machine, but is it worth creating a new layout API
for this?
jensimmons: Lots of subtle differences are likely to trip people up.
They're familiar but not quite the same.
jensimmons: We shouldn't fork grid, would be confusing to authors.
jensimmons: Chrome argues that new display type allows better
defaults -- but the defaults propose aren't good
jensimmons: if you think through the default they propose, it doesn't
quite work as easily as claimed [see article]
jensimmons: requires deep understanding of autosizing
jensimmons: We believe it's better to just use grid. Very simple, one
new value, re-uses syntax and mental model makes easier
to learn
jensimmons: also easier to switch, e.g. at breakpoints or progressive
enhancement
jensimmons: follows CSS design principles to re-use what already
exists
[end presentations]
astearns: If you have comments, please add yourself to the queue
<lea> https://github.com/w3ctag/design-reviews/issues/1003#issuecomment-2489688718
lea: We did a TAG review on this
lea: My opinion is fully reflected there. I think the arguments
WebKit team makes are compelling.
lea: We thought not only should masonry be part of grid, but should
go further.
lea: a lot of arguments for integrating is that "grid is too hard".
In that case we should make grid things easier.
lea: complex things are possible, but simple things are not so easy
lea: Big part of Google's argument is defaults, but we could just
have smarter defaults -- there is precedent for this in CSS
lea: if we decided that would help ergonomics
lea: We agree that switching between grid vs masonry is common. Grid
might be a slightly better fallback than nothing, but minor
argument because people can use @supports
lea: Introducing all these new properties increasing the API surfaces
that authors need to learn. Less they can port over.
lea: Even if we say we will be disciplined, experience shows that we
won't. Even if not intentional, accidental.
lea: DRY - don't have multiple sources of truth
lea: One of arguments against masonry in grid is that grid's are 2D,
but actually in graphic design grids were often 1D
lea: I agree that most masonry use cases need simpler grids than
general grid use cases
lea: but that means we should make those grids easier to define for
both grid and masonry
lea: The more we looked into this, we realize there are 3 different
layout modes that give you 2D arrangement of children
lea: we recommended not just make masonry part of grid, but find ways
of integrating what we already have better
lea: could we come up with a shorthand that sets grid-auto-flow and
flex-direction, and promote that for layout direction in general?
lea: then authors only need to learn one control for it
lea: Another concern was overfitting
lea: it doesn't cover a lot of cases that look like masonry, like
Flickr-style grid
lea: it's like a horizontal masonry
oriol: Problem with jensimmons's reasoning
oriol: She said the proposed masonry-direction property would be new
syntax that doesn't match grid-auto-flow property
oriol: but this property matches flex-direction property
oriol: so instead of trying to be close to grid, tries to be close to
flexbox
oriol: closer to grid is a choice, could be consistent with different
things
astearns: One question I asked is, has anyone changed their mind on
which proposal they support?
astearns: I personally have. I thought that separate display property
made a lot more sense, in terms of designing the feature
and I was very daunted by the idea that we'd have to
consider both grid and masonry for any new development in
either
astearns: seemed sticky to me
astearns: but the TAG argument convinced me that we should do the
work of integrating these things
TabAtkins: Thanks for setting that up for me, because I'm going to
refute the TAG argument! I think they're wrong in this case
TabAtkins: You can draw a lot of surface-level connections between
Grid and Masonry, and Flexbox, and other hypothetical
layouts
TabAtkins: but when you actually look at details of how they work,
behaviors each one is capable of, they're pretty distinct
TabAtkins: if you try to combine together, it would be an unholy mess
of conflicting constraints -- e.g. flexing in items of
masonry or grid
TabAtkins: or you'd have a weird mish-mash of, "the 2D layout", but
if you call it a flex you get access to these properties,
call it grid, access to these other properties
TabAtkins: concrete example, "pillar" example mentioned in webKit
blog post, that wasn't compatible with the base concepts
in masonry and flex because it wants a shared block
formatting context
TabAtkins: grid etc have different formatting contexts, can't use
floats
<miriam> I didn't come up with the pillar idea - that was from webkit
<lea> actually, the TAG argument was that layout seems to actually be
a continuum, and syntax should accommodate that rather than
forcing one of two extremes (current flex vs current grid).
TabAtkins: they're specialized for what makes sense
TabAtkins: You can occasionally merge things together, but definitely
not something you can do that by default
TabAtkins: too distinct to be merged in a reasonable way
<jensimmons> That's why the "pillar" example will use `display:
block`. The argument being made when it was articulated
is NOT that it should be part of Grid, but that it
should be part of Block, and not it's own yet another
new mode.
<lea> Our argument was not "make it a part of grid" per se, but more
"don't introduce a completely parallel new thing". If you can
extend flex so that masonry can become part of that, that's
just as fine
TabAtkins: Then usability arguments.
TabAtkins: The masonry shorthand can be very similar to a standard
CSS shorthand -- fully reorderable, just put the bits you
care about
TabAtkins: integrated one, the grid shorthand is very complex, mixing
in masonry doesn't make it simpler
TabAtkins: would stay bad and get worse
TabAtkins: separating lets use design things catered to the use case
<lea> if the `grid` shorthand has poor usability we should improve
the grid shorthand, not design a new thing :)
<TabAtkins> The `grid` shorthand is complex *intrinsically*, it's got
a lot of concepts that have to all be put together. It
can't really be made much better.
<TabAtkins> And that intrinsic complexity is directly tied to it
being an inherently 2d layout mode, whereas Masonry,
like Flex, is "1d, plus a bit"
miriam: Like Alan, tend to agree with TAG on this. I'm not real
excited about a future where we keep inventing new layout
modes with slight differences.
miriam: I get that there's complexity, but it's worth the attempt to
figure out how to not invent new tracks every time we have a
new layout that has tracks
dbaron: I remember Ian arguing about the performance characteristics
with regards to intrinsic size calculations
dbaron: Was related to fundamental ordering between how parts of the
process run in grid vs masonry
dbaron: Good performance important for end users. Is that topic still
under debate? Or is masonry in grid syntax using the model
that Ian wanted
TabAtkins: Whether in grid syntax or not, using the distinct layout
rules we defined to work for it
jyasskin: Wanted to emphasize a couple aspects of TAG review
jyasskin: It seems really nice to keep the property from Chrome
proposal that you don't have to learn both, can just learn
to do masonry without learning all of Grid
jyasskin: even if that's in a unified system
jyasskin: perhaps still define masonry shorthand, and have it set
grid properties
<jensimmons> To create a simple masonry-style layout in Grid, you
just need 3 lines of code (4 with a gap). It's quite
simple.
jyasskin: Most consensus part of TAG feedback was to share properties
whenever possible
jyasskin: Not necessary to share the same 'display' values; could
define different 'display' values but share the properties.
jyasskin: One thing we didn't like about unified proposal was
`grid-auto-flow` in the unified proposal, where some values
were ignored.
<TabAtkins> Yeah, this is the usability point I'm pounding on
astearns: I'm not hearing a way forward yet. At some point, one of
the camps is going to have to concede in order to move this
forward.
lea: What if we do a straw poll. Not to decide, but to figure out how
far are we from consensus?
<fantasai> +1 lea
lea: People may have been convinced
POLL: 1) Just Use Grid 2) New Masonry Layout
<TabAtkins> 2
<lea> 1
<fantasai> 1
<kizu> 1
<oriol> 2
<bts> 1
<alisonmaher> 2
<jensimmons> 1
<masonf> 2
<florian> 1
<miriam> 1
<ethanjv> 2
<JaseW> 1
<astearns> 1 (changed from 2)
<dbaron> abstain
<ydaniv> 2
<rachelandrew> 2
<dholbert> 2 (weak preference)
<gfaujdar> 1
<chrishtr> 2
<SebastianZ> 2
<jfkthame> 1
<bramus> abstain
<kbabbitt> 2
<joshtumath> 2 (but being persuaded)
* ChrisL finds convincing arguments from both sides
<schenney> 1 but try to move toward common property names
<noamr> abstain (happy if we ship either!)
<jyasskin> I would love to see both camps' attempts to move a step
closer to a shared understanding. e.g. Do the WebKit folks
think it makes sense to define a masonry: shorthand in the
grid-unified proposal? Can they fix grid-auto-flow? Do the
Chromium folks see some properties that could be more
shared?
<romain> 1 (changed from 2)
<emilio> 1.5
jensimmons: Personally disappointed that we're not making more
progress. We've been having this argument for 5 years.
jensimmons: We have two implementations. We'd like to ship. Lots of
discussion over the last year.
jensimmons: Many folks have strong opinions, but the target keeps
moving. A lot of the concerns have been addressed, but
new reasons to keep separate.
<TabAtkins> I mean, same.
jensimmons: Argument is no longer about technical details, but
overall concept and authoring experience.
astearns: I believe both camps want to ship and are frustrated with
current impasse.
<rachelandrew> not new reasons here, same reasons I started with
(before I was at Google)
<florian> though we could still not reach consensus, I want to thank
both sides for presenting clear arguments, densely packed,
well delivered. I will go back to the presentations, and
revisit some points, it really was informative to present
the way it was.
CSS Snapshot
============
Add specs to Rough Interoperability
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9793
SebastianZ: I posted all the data I could collect in 1st comment
ChrisL: I'm broadly agreeing, but 2 things that have become CSS
Shadow have not been published in a long time and can't be
referenced
ChrisL: I do suggest adding Color 5. So much of it has been cleared
to ship
fantasai: Nesting hasn't been published in like 2 years
fantasai: I think it should be in rough interop, but it needs to be
updated on TR
fantasai: otherwise id' be fine with adding it
fantasai: so i'd be fine if it was updated, but not until it is
astearns: So stripped down is add CSS Scroll Anchoring 1, CSSOM 1,
and Color 5 to Rough Interop
<ChrisL> +1
SebastianZ: We can add CSS Nesting if it gets updated in time
fantasai: If Tab can update in the next couple weeks, happy to add
it :)
<TabAtkins> we'll see
ChrisL: Do we mean publish a new WD as we have today, or do a bunch
of work on it?
TabAtkins: I think the ED is pretty up to date
PROPOSED: Add Scroll Anchoring 1, CSSOM 1, and Color 5 to Rough
Interop; add Nesting once it's republished.
SebastianZ: One more thing -- Selectors 4
RESOLVED: Add Scroll Anchoring 1, CSSOM 1, and Color 5 to Rough
Interop; add Nesting once it's republished.
ChrisL: Not objecting to including it
astearns: Comment is that it's perhaps further than Rough Interop
PROPOSED: Add Selectors 4 to Rough Interop
RESOLVED: Add Selectors 4 to Rough Interop
CSS Sizing
==========
Intrinsic size of <img> / <video> with aspect ratio but no definite
size
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10605
emilio: This is about what happens when a video isn't loaded, and you
specify width/height but override it with 'auto'
emilio: There's inconsistency here with image.
emilio: Very common to have an unloaded video
emilio: Test in WPT that Blink still failing, but WK and GK pass
emilio: Not super well-defined. Should we improve it?
<emilio> https://wpt.fyi/results/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-aspect-ratio.html?label=experimental&label=master&aligned
is the wpt fwiw
astearns: Preference for what to define?
emilio: When I implemented this, I very explicitly thought about it,
so would prefer to align on Gecko/WebKit behavior
emilio: It is how images behave, so makes sense
astearns: What is that behavior?
oriol: I think the test emilio points out that Blink is failing is
not completely related
oriol: In Servo, we match Blink in a bunch of cases
oriol: Problem emilio points out is you have a video and image
element, both of which have width/height set to auto
oriol: they behave different in Blink
oriol: We behave like Blink, but pass the Test
oriol: so there's room to do both things
oriol: In particular, difference in Servo between images and video,
if an img has no resource, we fall back to 0x0 natural size (
not undefined), but video is undefined (no natural size) so
get default object size (300x150)
emilio: given you have aspect ratio, you end up with a sensible
behavior
emilio: given how common it has to have an unloaded video...
emilio: I think I need to think through this again, been a long time
emilio: I'll take it back to GH
Writing Modes
=============
scribe: TabAtkins
Allow sideways-x and vertical-x to share a block formatting context?
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10714
fantasai: WM3 said if you have a different writing mode, you form a
different bfc
fantasai: Made sense then, each writing mode went in a different
block-flow direction
fantasai: but in WM4 we introduced the sideways variants, which
differ from vertical only in line orientation
fantasai: so switching between those doesn't change block flow
direction, probably doesn't need a new bfc
fantasai: So does it make sense to allow them to share a bfc?
fantasai: In terms of use-cases, say an English block quote inside of
vertical Japanese
fantasai: and you formatted that with sideways-*
astearns: So firefox ships the sideways keywords. Does it establish a
new bfc there?
fantasai: Haven't checked, but also don't think we're under compat
pressure here
jfkthame: I think it does establish a bfc, but think we could change
that without too much difficulty
astearns: And Kent's comment is that we shouldn't change the spec
unless there's a good author use-case
fantasai: I think if you do mix these two... the cases where there is
a behavior difference are rare
fantasai: but if you did end up in such a situation, you'd want them
to be in the same bfc
TabAtkins: Obvious example is a float. If you started in Japanese,
and then switched to sideways English, and float intruded
into the English paragraph
astearns: So proposal is to change the spec to not require a new bfc
between sideways-* and vertical-* WM changes
astearns: and we'll see if it's web compatible
<oriol> The author can always force a bfc manually if desired
fantasai: Yes. I suspect it is since firefox is the only one shipping
sideways right now
astearns: Comments or objections?
RESOLVED: Allow consistent sideways-* and vertical-* writing modes to
share a BFC
Admin
=====
astearns: Next week we'll be inviting the CSS Next people to present
to the group about a new CSS icon
astearns: Also, huge backlog. If someone has 5-10 issues on a topic
that we can schedule a breakout for, happy to do more of
those
<bramus> @astearns: Are the date for the F2F confirmed?
astearns: I believe the Jan f2f dates are confirmed?
fantasai: Haven't gotten final confirmation from the events team, but
I have reserved it. Will update when I get notice soon
Received on Thursday, 5 December 2024 01:23:45 UTC