- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 16 May 2019 18:54: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.
=========================================
Grid
----
- RESOLVED: Change the specs so that the default scroll area
includes paddings by default for Grid and Flexbox (Issue
#3665: Include padding in scrollable overflow area)
- The group had trouble visualizing Issue #3646 (Consider setting
base sizes to growth limits when sizing under max-content
constraint) and will spend some time with a whiteboard later on
in the F2F.
CSS Sizing
----------
- RESOLVED: Use min-height: auto to solve problem of content
overflowing aspect-ratio (Issue #3268: Rethinking how to
prevent overflow in a container with an explicit aspect
ratio)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sf-2019
Present:
Rachel Andrew, Fronteers
Rossen Atanassov, Microsoft
Tab Atkins, Google
Amelia Bellamy-Royds, Invited Expert
Tantek Çelik, Mozilla
Emilio Cobos, Mozilla
Dave Cramer, Hachette Livre
Elika Etemad, Invited Expert
Jihye Hong, LGE
Koji Ishii, Google
Brian Kardell, JS Foundation (phone)
Ian Kilpatrick, Google
Rune Lillesveen, Google
Chris Lilley, W3C (phone)
Cameron McCormack, Mozilla
Theresa O'Connor, Apeoplee
François Remy, IDLAB
Manuel Rego, Igalia
Florian Rivoal, Invited Expert
Hiroshi Sakakibara, BPS(Beyond Perspective Solutions)
Jen Simmons, Mozilla
Hyojin Song, LG Electronics
Alan Stearns, Adobe
Morten Stenshorne, Google
Greg Whitworth, Microsoft
Fuqiao Xue, W3C
Scribe: fremy
Grid
====
Include padding in scrollable overflow area
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3665
fantasai: This is a follow-up of last issue
fantasai: where we resolved to take explicit tracks into account in
the scroll area
fantasai: but we had a tangent discussion about considering the
padding
fantasai: We have compat restrictions in the case of block
fantasai: [missed the details of the compat case]
fantasai: But we don't have such a compat issue for grid, so we can
do this the way authors expect
astearns: And we would be doing this for flexbox as well?
fantasai: Yes
fantasai: We already had people asking for this to be fixed for
blocks
fantasai: and the closest we could do was to do this correctly when
alignment properties have a non-default value
dholbert: Doesn't chrome already do that in the block direction?
fantasai: Yes, but we want to change the spec to require both axises
<rego> example for flex and grid:
https://jsbin.com/yizuzanado/1/edit?html,output
dbaron: What are you proposing to include exactly?
fantasai: Boxes that are in flow, and their border box, plus the
entire grid, and the padding around all this should be
included in the scrollable area
dbaron: And what is the change?
fantasai: Include the paddings
florian: When the alignment is the default
dbaron: But how about the margins?
dbaron: I thought it wasn't interoperable
dbaron: I would like the spec text to be very clear about what
margins are included
dbaron: For example, descendant margins, collapsing margins, and
their interactions
florian: But this is orthogonal to padding though
dbaron: Yes, you're right, I just didn't know what was the change
proposal about
dbaron: I would be fine with any behavior, but would like the spec
to be clear
tantek: Do we have tests?
fantasai: no, but I can make one
<fantasai> testcase -
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22display%3A%20grid%3B%20width%3A%20100px%3B%20height%3A%20100px%3B%20padding%3A%2010px%3B%20overflow%3A%20scroll%3B%20border%3A%20solid%22%3E%0A%20%20%3Cdiv%20style%3D%22width%3A%20100px%3B%20height%3A%20100px%3B%20background%3A%20blue%3B%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
<fantasai> In Firefox, there's only padding in the top/left
<fantasai> In Chrome, you also have padding at the bottom
<fantasai> Authors expect padding on all sides.
<tantek> I see padding on all sides of the blue square in FF67
nightly
Rossen: Sounds great, let's do it
Rossen: Back when IE implemented this, we did it "right" be default
Rossen: then got compat issues
Rossen: but ideally we think this should be the default, so I
support this change
astearns: Where are we gonna write that?
fantasai: In the same place as where the rules are today, but we can
add a note to explain why block must be an exception
jensimmons: I think for authors it's great that the new layout work
properly, and then there is legacy
jensimmons: It's great to clean cut from the past, if you rely on
new things, you don't have to be aware of old legacy
issues
astearns: What about dbaron's concern that everything should be well
defined
fantasai: We should add all these details in the overflow spec
fantasai: but the general behavior should be in the alignment spec,
that only deals to in-flow content
fantasai: But well, I agree, there will be changes in a couple of
specs to achieve this result
astearns: Grid and flexbox are probably gonna be released before
overflow though
astearns: so pulling it in would help get this to REC sooner
florian: We can add a note in those specs, but in the end overflow
is required for all modes, so it doesn't matter all that
much
<tantek> fantasai, I see the same result in Safari and FF67. Blue
square with padding all around it between it and black
border
<rego> tantek: this is another example
https://jsbin.com/yizuzanado/1/edit?html,output
<tantek> rego, that example is inconsistent across FF67 (no
scrollable padding bottom & right), and Safari (no
scrollable padding right)
astearns: any objection to this proposal?
<fantasai> proposed resolution: include padding in scrollable
overflow area, edits to grid/flexbox/alignment/overflow
RESOLVED: Change the specs so that the default scroll area includes
paddings by default for grid and flexbox
tantek: Is there commitment to make the change in chrome?
rego: Yes, we will make the change
tantek: Cool
<rego> at least we'll send the patch to Chromium and WebKit, if
Apple doesn't agree with this I don't know
Rossen: Just wanted to note that I had prior discussion on this
topic, and one of the rules that some webkit engineers cared
about was...
Rossen: ... to minimize the amount of empty space you are scrolling
to
Rossen: but for grid and flexbox, they are used as structure for
other things, and it's important to preserve space because
the space is part of the structure
Rossen: So I don't think dropping padding there is an option that
isn't weird
Rossen: but we might want to give a chance to webkit folks to take a
look
astearns: As for all resolutions, things can be reversed if needed
but as far as I know, we have a webkit contributor here
planning to make the change
Setting base sizes to growth limits under max-content constraint
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3646
oriol: There are two issues in there
oriol: One is that when sizing a grid under max-content constraint
oriol: when computing the space for item with intrinsic size
oriol: we only consider the base size of tracks
oriol: which can be smaller than the size of the track in the end
oriol: So, maybe we should consider instead of the contribution of
the item minus the track size
oriol: consider the contribution of the item minus the growth limit
oriol: (explains the example in the issue)
oriol: When the growth limit of a track increases, we could increase
to base size up to that growth limit
oriol: This means that when you are using fit-content
oriol: you need to do first min-content then max-content
oriol: This is a lot of work
oriol: but chromium isn't doing this all the time
oriol: They perform a single layout track, and sets a base size of
the tracks which is the min-content, and the growth-limit is
the max-content
oriol: which is ok if there are no spanning items, but if there are
spanning items the result is wrong
oriol: However, with my proposal, we wouldn't need to keep track of
different base sizes for these two cases, and therefore we
can always do only one single layout for fit-content
oriol: (one single *extra* layout pass)
* fantasai is wondering what's the relationship to
https://github.com/w3c/csswg-drafts/issues/3648
astearns: Thanks oriol
astearns: Some people in the room are reviewing this in a bit more
details
astearns: Anyone has a response?
astearns: Or should we continue this in the issue?
rego: One question, are we sure that what the change is what authors
would expect?
rego: If it is, I think the change oriol proposed should get done,
but maybe it isn't what authors expect, I'm not sure
<bkardell> rego are you saying things would break?
astearns: jensimmons? Do you have an opinion?
jensimmons: Not yet
Rossen: The issue is fairly new
Rossen: maybe we need to take more time
<tantek> TBH I can't visualize this. Any chance of projecting an
example for things like this? E.g. before/after change?
<bkardell> tantek, yes please
<tantek> bkardell right?
<bkardell> it sounds like a lot of people would appreciate that
Rossen: maybe we can use whiteboards at lunch
<florian> I am a little confused. Does that relate to
https://github.com/w3c/csswg-drafts/issues/2356 ?
fantasai: I'm in favor of that
...
fantasai: With regard to the labels, I want to publish a new grid
update
fantasai: So I'm classifying changes between big changes and minor
fixes
fantasai: and I would want to first get to the changes that are just
fixes
fantasai: and continue to work on bigger changes on a more relaxed
timeline
rachelandrew: Is that just a performance issue?
rego: Well, I mean, not entirely
rego: but it would enable firefox to match both the spec and chrome,
because in Chrome we don't follow the spec because it's both
faster and easier not to follow it
rego: With the proposed change, we could both update to this new text
<tantek> (wants what Jen Simmons said minuted, but can't remember
exactly to type it himself)
<jensimmons> I said: Let’s figure this out. It should make sense for
Authors. And we want to squash any interop problems…
CSS Sizing
==========
Preventing overflow in a container with an explicit aspect ratio
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3268
fantasai: So jensimmons filed this issue about how we are going to
handle a non-replaced element's aspect ratio
fantasai: It's possible that the content might overflow the element
fantasai: so do we want to make sure the aspect ratio is a rigid
ratio, or just a minimum ratio?
fantasai: There are multiple ways to do this
fantasai: One would be to take advantage of min-height: auto to
use min-content or aspect-ratio, but otherwise use only
the aspect-ratio
jensimmons: We talked about it before, if you have paragraph with a
couple of words an an aspect ratio
jensimmons: if the ratio allows for breathing room at the bottom,
it's fine
jensimmons: but if it's smaller because the paragraph has lots of
words, then it's overflowing
jensimmons: so we thought maybe the default behavior would to take
min-content into account
<fantasai> Florian's proposal to use min-height:
https://github.com/w3c/csswg-drafts/issues/3268#issuecomment-437731901
fantasai: So, could we resolve and add this into the spec
florian: min-content and max-content are the same in that direction
florian: but if they wouldn't be in the future, which one would we
want to use?
florian: Right now, we don't have mechanism to tweak it but it might
come later
<dbaron> Was having min/max-aspect-ratio one of the options?
dbaron: min-aspect-ratio/max-aspect-ratio
dbaron: but width/height are defined in the other direction
dbaron: (of priority?)
fantasai: Yes, but you can apply the ratio in both directions,
because we do it in the direction that is auto
jensimmons: I don't know what min-aspect-ratio or max-aspect-ratio
would mean, and I don't think we need a three-part
aspect ratio system
dbaron: But if you worry about sizing of height, I guess by then the
width has been set
dbaron: The idea I was thinking is that you might want an aspect
ratio, but that could be taller or wider, you could use
min-aspect-ratio
dbaron: Well, ok, maybe I got this backwards
dbaron: so it's fair to say that min and max might be confusing in
this case
dbaron: but it's more expressive
jensimmons: I don't think there is a use case for max-aspect ratio
jensimmons: I think the desired behavior is that you set an aspect
ratio, and if there's more content it grows bigger... or
it overflows
jensimmons: you want the aspect ratio to either be strict
jensimmons: or allow for the box to grow
jensimmons: It's not a minimum aspect ratio, it's the desired aspect
ratio unless it gets overflowed
jensimmons: I don't know what the use case is for a maximum aspect
ratio
jensimmons: or a range of aspect ratios
jensimmons: From authoring / film industry... doesn't make sense
jensimmons: You want a particular target, or you let it slide
because it's not a good idea (overflow)
jensimmons: I'd rather do the 1st proposal not the 2nd, to summarize
Scribe: fremy & fantasai
rachelandrew: Trying to think of a use case this doesn't solve.
Would like something written up with an example, say
to authors, "this is what we're thinking of doing,
behaves like this. Can you think of any use case it
doesn't solve?"
rachelandrew: People are doing this all over the web, so have an
idea of what they need
rachelandrew: We could get this out there and see if it'll solve the
problems
florian: agree with jensimmons
florian: The thing you brought up, dbaron, is what the proposal is
trying to solve
florian: Want to grow by default if too much content
florian: min/max-aspect ratio is too confusing
florian: and the first one gets most of what you want, and you can
enforce strictly if you need
jensimmons: 2 use cases most common
jensimmons: 1 - video or empty decorative box
jensimmons: not a video element video, but iframe or object or
something
jensimmons: other use case is teaser cards or something like that
jensimmons: Maybe you want them all squares
jensimmons: but you don't want them to constrain height, because
want to allow overflow
jensimmons: Is anyone imagining a different class of use case?
bkardell: I'm hesitant to even bring this up, because not sure it
fits in conversation, but not that long ago I worked on a
project that was CMS-oriented
bkardell: It was very open to what authors could provide
bkardell: There were maybe 2-3 different kinds of images with their
own aspect ratios
bkardell: There was some negotiation
bkardell: wanting to deal with the actual aspect ratio was the issue
we had there
bkardell: but seems the opposite of what jen's talking about
bkardell: might not be relevant...
astearns: We're talking here to add an aspect ratio to non-replaced
elements
astearns: so behavior needs to be specified for when content can't
match aspect ratio that was specified
astearns: Images always can
jensimmons: Images come in when you use object-fit: cover or contain
jensimmons: and want to give a particular aspect ratio
jensimmons: but that's about interaction of explicit and implicit
aspect ratios
fantasai: One of the benefits of the min-height: auto solution
fantasai: is that we can easily turn off the grow behavior
fantasai: for example when we have scrolling in place
fantasai: which I think is what we want by default
fantasai: This is what min-height: auto is for
dholbert: One thing to think about is the thing with aspect-ratio is
not itself scrollable
dholbert: but it has a scrollable child
dholbert: min-height: auto means be as tall as the thing inside the
scrollable thing
dholbert: because the scrollble content is one level below
dholbert: Fixable by setting min-height: 0
dholbert: but might be worth thinking about
fantasai: Actually, that spec has a simple solution
fantasai: The question is whether this is web-compatible
fantasai: so we need to implement this and see in a canary build if
that works
cbiesinger: It's in the backlog, but only for width
fantasai: Well, you said you could only do this for width, but
eventually we would want to try both
fantasai: but width is a good start
florian: Maybe this is one place where in the block axis we have a
difference between min-content/max-content... maybe not
florian: max-content you expand all the content. min-content you
don't...
Rossen: That's super weird
Rossen: I think it is super weird. It is also a behavior that is
desired.
Rossen: If we going to introduce something like this, let's not
re-introduce max-width or something
Rossen: Let's add another property
florian: I did not mean the max-width property
florian: I meant the max-content keyword
florian: min-height: auto grows you beyond the auto height
florian: If you specified min-height: max-content you would grow and
min-height: min-content you would not
jensimmons: We started there, but decided to use auto instead
jensimmons: You'd get the same result
florian: Thing I hadn't considered is what dholbert brought up, when
it's the children of the thing with an aspect ratio that
are scrollable
florian: Do you want control over that?
florian: ...
jensimmons: My expectation is that if you assign an aspect ratio to
a box and inside there's controllable content, then your
desire is to keep that content at that aspect ratio
jensimmons: and then the content scrolls
jensimmons: That would be awesome
jensimmons: The fact that children is scrolling, want the container
to grow?
fantasai: I think this is one of the big mistake we made, and I
really want this fixed
fantasai: I am afraid of the webcompat
fantasai: so I can't make this change just by myself
<fremy> +1 to what fantasai said
fantasai: But authors shouldn't have to set weird height:0 etc hacks
to work around this
astearns: But this is orthogonal to this issue, right?
fantasai: Yes
<tantek> +1 on fantasai's proposal from an authoring perspective. I
hope we can do it and maintain compat!
<fantasai> proposal is to use min-height: auto to solve the problem
of having the box grow past its aspect-ratio in order to
accommodate content that would otherwise overflow
jensimmons: [gives an example]
jensimmons: If I have 400px wide box with 1:1 aspect ratio and
content is 700px high
jensimmons: min-height: auto computes to 700px, therefore wins over
the height calculated by aspect ratio
jensimmons: author can set min-height: 0 to get that content ignored
in the sizing
dholbert: For both axes?
fantasai: I think so, but not if both are auto
dholbert: (example about a very long word you can't break)
AmeliaBR: object-fit?
fantasai: This is about non-replaced elements, doesn't apply
astearns: Objections to proposed resolution?
RESOLVED: Use min-height: auto to solve problem of content
overflowing aspect-ratio
Received on Thursday, 16 May 2019 22:55:34 UTC