- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:10:44 -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.
=========================================
Flexbox
-------
- RESOLVED: Take existing algorithm, mark it as informative, and
explain why that is (Issue #8884: Intrinsic main size
algorithm for row flexboxes not web compatible)
- RESOLVED: Spec what chrome has implemented in canary currently
(Issue #8884)
- TabAtkins and fantasai will look into the compat findings for
further iterative improvements to the algorithm.
CSS Grid (Continued)
--------------------
- RESOLVED: Close no change. Spec is what we intended. Action to
file bugs on browsers and create WPTs (Issue #8966:
Honoring the specified width/height of a subgrid)
CSS Box
-------
- RESOLVED: margin-trim doesn't apply to floats (by default), and
we'll explore the interaction in the future (Issue
#8547: Use cases for margin-trim on floats)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/38
Scribe: bramus
Flexbox
=======
Intrinsic main size algorithm for row flexboxes not web compatible
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8884
iank: Currently all the implementations have same interop algorithm
for single line row flexboxes
iank: This however does not take a bunch of stuff like flex basis
into account
iank: Effort by Tab and Elika to specify an algorithm that would be
compatible that takes all that sufficiently into account
iank: Chrome has been experimenting with this algorithm
iank: and tried to ship on canary. tldr is that currently spec
algorithm is not web compatible
iank: We added test cases for sites that we know that we broke
iank: Impact was very very wide
iank: We broke a lot of stuff, like gmail
iank: We are likely a lot or compat constrained
iank: Have a proposed algo, that we have been running in canary and
we have not broken anything (yet)
iank: I think this is a floor for us to start
TabAtkins: We've been avoiding looking at this issue for a while
TabAtkins: I need to refresh my brain on why this case gets 300px
wide in the spec
iank: Keep in mind that is only 1 of the issues that we ran into,
there is at least 5 different issues that we run into that are
subtly different
iank: We tried a variation where we tried to fix a few things when
the flex fraction is ??? its not gonna work. We are very
compat constrained
iank: We think that we can go for a super relative small incremental
fix, that fill fix the ??? case that will fix some flex basis
being a definite thing.
iank: Roughly it is if the flex base size is greater than the main
contribution and it can't shrink then use that. Same for
growing and same for max contributions.
iank: For other things we are way more compat constrained
iank: We broke everything
fantasai: There are two halves to intrinsic size computation. min
and max content sizing
fantasai: These are different in a bunch of cases. did we break both
of them?
iank: Yeah, both
iank: got reports for both
fantasai: The min content stuff we were trying to make it there was
no overflow within the items. So the ??? was larger than
the naive version for partly that reason
fantasai: The max content one we get a size that is bigger but also
don't get the max content size if you do the current
behavior, which does not seem like it satisfies the use
case?
iank: Need to check, but we also broke the max content size. People
have relied on current behavior because we have good interop.
We think we can get away with respecting flex-basis as
described because that is very broken
iank: is running on canary, so we might identify issues
fantasai: Seems unfortunate, because we can't size a flexbox to fit
its content if not following the spec algo
fantasai: like you get a random size in implementations right now
astearns: Proposed change is to revert the algorithm?
fantasai: This was original algorithm that was never implemented,
so nothing to revert to
iank: We tried to implement to see if its compatible
astearns: How did we manage to get to interop?
fantasai: Were doing a much more naive implementation. If you take a
flex-grow that wraps, then impl would just pretend there is
1 row and max-content would be widest item which is not
the case when it wraps.
fantasai: that kind of thing where a simple approach was taken ???
fantasai: people are therefore relying on weird behavior
iank: I think we can fix flex-wrap column case
fantasai: The hardest one!
iank: Like col wrapping flexbox boxes are minimal while the number
of row flexboxes is high
fantasai: I have not dug into this issue, but wonder if we at some
point might need a switch sizes property
iank: I think we can get a long way there. ???. It would be nice,
but I am not hearing from devs about the brokenness, as
opposed to the column wrap case
iank: The row case is “sure, whatever”. Don't know how much value
there is in a switch for devs.
iank: We would have had a lot more reports about it
astearns: So, what do we want to do?
fantasai: I think Tab and I are gonna need to do a follow up and
figure out what spec changes are needed and also what
comes back from web compat
iank: Having a quick look at definitive flex basis case is pretty
simple. We are 90% sure that we can do this change.
iank: It seems like a col wrap case and not a lot people set a flex
basis
iank: If we get a resolution about path forward with flex basis
algorithm then we can roll forward. Won't push to beta channel
without out
fantasai: Seems like step in right direction. We should take
resolution to support going in this direction
TabAtkins: Yeah
iank: Yeah, we think this is a flaw and that we can ship this
iank: incremental changes
iank: I think that is path forward
fantasai: From spec perspective we ???
astearns: Take the algorithm that is in the spec that turned out to
be problematic from a compat concern, leave it in the spec
as informative note with explanation about it being a note
and then add this 1 change so that blink can try shipping
fantasai: It is creating an algorithm for … we have to draft the
algorithm + blink change
fantasai: it is adding a new algorithm
fantasai: I agree on keeping it as informative note
fantasai: with mention that we are going to tweak it more
iank: At the very least, also writing down what browsers are
currently doing
iank: and the incremental thing
astearns: So first resolution is to take existing algorithm, mark it
as informative, and explain why that is.
astearns: Objections?
RESOLVED: Take existing algorithm, mark it as informative, and
explain why that is.
fantasai: Second bit is to tentatively spec what chrome has
implemented, and mark it as tentative
iank: Also tweak it if there is feedback
astearns: Objections?
astearns: With intent to improved it as much as we can
astearns: Proposed is to tentatively spec what is interoperable for
this area of flexbox sizing, and mark it as tentative
fantasai: I'd rather spec what chrome is doing
astearns: Other browsers any concerns about this?
dholbert: Seems fine to me
sammy_gill: Double check that is the conservative and web compatible
version
iank: Yes, web compatible up to canary
iank: We might find out that we broke stuff when pushing to beta
astearns: And you said you found 6 issues?
iank: Yes, we've had cases that broke large sites
RESOLVED: Spec what chrome has implemented in canary currently
TabAtkins: It is in the thread
astearns: (missed)
CSS Grid Continued
==================
Honoring the specified width/height of a subgrid
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8966
alisonmaher: There are three different parts to this issue
alisonmaher: First example, we are in subgrid in both directions with
width of 50px. According to spec subgrid is always
stretched in subgridded dimensions
alisonmaher: We like to confirm width should be ignored, given that
cols are subgridded. blink stretches but webkit sets
size of subgrid to 50px and gecko is doing combination
where text is stretched but subgrid is 50px
alisonmaher: width should be ignored here
fantasai: Yes, that was intention of the spec
alisonmaher: Any more comments?
astearns: Action here is to file bugs for other vendors
alisonmaher: In 2nd example subgrid is not ?? and we like to
confirm ???
fantasai: You only ignore alignment and sizing in the subgridded
axis, not in the other axis
alisonmaher: That makes sense
astearns: Action is to file a bug for blink
alisonmaher: 3rd example the subgrid inline axis is not subgridded.
Question is should we ignore min content size of the
subgrid and instead use the specified width 50px. This
would ??? to overflow available space
alisonmaher: gecko and webkit use specified width, while blink
considers the min content size
fantasai: So this is a subgrid, subgridded in the block axis but not
inline?
fantasai: you should honor the width
alisonmaher: Then we should file a bug as well
astearns: And please add WPT for all scenarios
iank: There is mininal test cases but generally the whole subgrid
area is under tested
iank: This set of fixes on the blink side are relative major, so we
want to make sure beforehand that this is the expected thing
astearns: Proposed resolution to close no change. Spec is what we
intended. Action to file bugs on browsers and create WPTs
astearns: Objections?
RESOLVED: Close no change. Spec is what we intended. Action to file
bugs on browsers and create WPTs
CSS Box
=======
Use cases for margin-trim on floats
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8547
Sammy_Gill: This is an open ended discussion. While doing some
prelim work on floats we found that there are some
complexities
Sammy_Gill: We want to come back to the working group and see if
there has been high demand or if there are significant
benefits to authors
fantasai: (draws on whiteboard: float with some text wrapped
around it)
fantasai: I can see wanting to trim both in-flow and float margins.
fantasai: I have a page with some text at the top and an image here
fantasai: you generally want float and text to be flush at the top
fantasai: if we trim all margins on the inline stuff but not the
float, you are gonna have a margin at the top only on the
float, so they won't be even
fantasai: Why the margin? maybe you have two floats, not sure which
one(s) end up flush with the top.
fantasai: I can see having separate controls for floats vs in-flow
content.
fantasai: It is possible that if you float something, it is not
furthest to the side
fantasai: so you might not be able to select the float that is flush
with the side
fantasai: that is the use case
iank: I think when yeah it is sort of a judgement call. some folks
want it, some don't
iank: The implementation complexity is significant
iank: For example, if you trim, then that float might get placed
somewhere else
iank: Another one is that you may have to restyle layout from the
root like bfc to get the layout to be correct.
iank: You might need to backtrack the whole entire way
iank: Very complex
florian: For floats that are meant to be floats, looking at print is
a good source of use cases
florian: If you look at antenna house formatter (css to pdf tool)
they do this slightly differently. Instead of margin
trimming they let you set multiple types of margin, e.g.
float-to-float margin, float-to-text margin,
float-to-container margin, which you can set separately,
but that might not remove complexities
florian: where you try to do a book-ish layout, you might need it
iank: A simple formatter might get away with this, but here its more
complex
astearns: That said, existence of these controls in print formatters
is evidence that some people do want to have control over
these things
iank: Yeah. From what I have seen, some people do want to
control this
iank: but compared to the general feature it is less
iank: The demand is not as large from what I have seen
fantasai: One question: are complexities from both axis or just from
inline?
iank: The block start margin is likely fine modulo the placement
thing
fantasai: That might be acceptable
fantasai: Inline dimension there is complexities like block end
fantasai: Complexities on all sides. least troublesome is block
start. most is block end
<dbaron> (inline dimensions in the middle for how troublesome)
fantasai: Block end margin is complicated? Doesn't it only apply to
bfc root?
Sammy_Gill: The trimming for block end margin extends through entire
bfc and not just the block
fantasai: For the block-end margin, the float does not cause the
non-bfc-root to grow/shrink
iank: ...except when you have clearance
fantasai: If we had margin trim on block end side apply only to bfc
root would probably satisfy the use cases
iank: It still is complex. that float might before the content. If
it has end margin ??? it might get replaced ??? so you might
need to backtrack
fantasai: But you don't remove bem?
iank: That still is ???
fantasai: It probably should not
fantasai: It should not cause the float to be placed again (?)
fantasai: The margin trim should not on the bottom not cause it to
move. It should allow the bottom margin of the bfc to
shift upwards until it is flush with the bottom-most
border edge of the floats
fantasai: I think what won't cause problems
fantasai: I think use cases for block layout in general is block
axis margin. Can't think of example for inline axis
trimming except for floats
iank: There is still issues with blocks and margins
astearns: It may be around float stacking where bottom edge of one
float can affect a subsequent float
iank: Yeah, also fun stuff about <br> that clear stuff
iank: brs get complicated
iank: brs are magical
florian: So my takeaway that there are usecases and it is hard
florian: Suggestion to take it back to github
fantasai: Suggestion not apply margin trim by default to floats, try
and find a syntax that would allow margin trim to apply to
only floats or floats and all other content, and then work
through some of the block axis issues at least
myles: One side is about implementation discussion, then making this
an author opt in does not help
fantasai: But then you can implement it in stages
iank: If we make default not apply to floats, then webkit can
implement without affecting floats then we can add an
extension to floats which we can decide upon later
florian: opt-in to be defined later also allows for introducing
partial solutions as opt ins, if we can find some that are
reasonably easy to implement and do solve meaningful
subsets of use cases
scribe: dbaron
myles: Main concern is about implementation cost of final thing
eventually in the future.
myles: staging it out over years doesn't satisfy that.
myles: If we end up with multiple different opt-ins, problem is
worse in the end.
fantasai: It seems that an author might reasonably set it
independently for inline flow and floats.
fantasai: otherwise I wouldn't want this
myles: I'm not making a judgment about one side of the issue or the
other, just trying to clarify about implementation complexity.
fantasai: I want to talk more with Ian to understand where the
complexity is coming from.
fantasai: I wonder if the complexity is actually intended.
fantasai: Some of the complexity may not be desirable
iank: Sammy_Gill may have more of it loaded in his head right now.
iank: Discussion I had with Alan at WebKit a while ago.
astearns: Not as much about margin-trim itself, but how it affects
all of float positioning which is complicated
Sammy_Gill: Example here is reasonable, but when you make it apply
to all floats then it gets hairy
iank: If we resolve not to apply to floats in the moment... web
developers are great at telling us when they think something
is broken, so we can get a sense of demand later on
myles: Sounds like a great compromise
florian: In terms of usage, ... usable-ness of floats increases
significantly with well functioning fragmentation and page
layouts. So we don't see this much on the web. If we
increase our fragmentation capability, we might also
increase our need for fancy floats, which will remain
complicated.
florian: Original use case for floats not used all that often on the
web, but used plenty on paged media
myles: Comment about usage of floats or about margin-trim?
florian: Floats in general... but once floats are used more, people
will want more fancy floats features
hober: Aren't floats used all the time, to a first approximation?
fantasai: Way they're used on the web and the way they're used in
paged media are quite different
fantasai: Many ways they're used on the web are correctly being
replaced by grid and flexbox
fantasai: If we had developers trying to do what floats were
intended for on the web, demand for these features would
increase
myles: I think we should tentatively resolve that they don't apply
to floats, and then try to understand use cases and slice/
dice issues.
astearns: proposed resolution: margin-trim doesn't apply to floats
(by default), and we'll explore the interaction in the
future
RESOLVED: margin-trim doesn't apply to floats (by default), and
we'll explore the interaction in the future
Received on Sunday, 10 September 2023 15:11:20 UTC