- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Feb 2017 21:32:04 -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.
=========================================
Grid
----
- RESOLVED: Automatic minimum is clamped by max track size not
final track size.
- RESOLVED: Specify that min-width: auto only resolves to the
automatic minimum size if the item spans at least one
track whose min track size is auto. It is otherwise
zero.
- Discussion on how percentages should be resolved during
intrinsic size computation:
- Originally there were two options listed; treating
percentage track sizes as auto or resolve to 0.
- Neither of these options seemed to work well/expectedly for
all use cases.
- The group developed six choices to select from:
a. Ignore percentage and treat as auto (like block %
heights)
b. Back compute percentages (like tables)
c. Percentages contribute zero, but resolve afterward
d. Percentages contribute intrinsic size, resolve
afterward during layout
e. Option c unless all siblings are percentage, else
option a
f: Percentages contribute their minimum size (min-width),
but resolve afterward
- Several people thought option b would be interesting, but
would take a bunch of time to solve.
- Option d was generally agreed to be easiest, but may not
solve all use cases and results in overflow when
shrink-to-fit sizing is invoked.
- In order to take a straw poll, the list was narrowed down to:
1. Ignore percentages
2. Backcompute percentages
3. Percentages contribute intrinsic size, but resolve
afterward
4. #3 with a switch based on min-width
- RESOLVED: Percentages contribute intrinsic size and they
resolve after layout.
- During the conversation dbaron raised an idea he had been
thinking through: to have properties that let you assign
the intrinsic sizes. This was interesting to several
people and he was encouraged to write it up, but it wasn't
the right solution for this specific problem.
- Mats's alternate proposal for stretching images in a
ratio-preserving way as well as the original options were
discussed.
- Options:
1) Make default sizing intrinsic (could opt into contain
with keywords)
2) Make default sizing contain (could opt into intrinsic
with keywords)
3) Add sizing options to alignment (Mats's proposal:
https://github.com/w3c/csswg-drafts/issues/523#issuecomment-268095890)
- RESOLVED: We're keeping the current specified behavior as it
is (no change to the default sizing, non replace
get stretched, replaced gets start and add new
sizing keywords to address the issues)
- There was also an expressed interest in adding contain to
sizing, but people needed more time to understand how it
would work.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/seattle-2017
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
David Baron, Mozilla
Bert Bos (W3C)
Dave Cramer, Hachette Livre
Emil A Eklund, Google
Elika Etemad, Invited Expert
Simon Fraser, Apple
David Grogan, Google
Koji Ishii, Google
Peter Linss, Invited Expert
Myles C. Maxfield, Apple
Simon Pieters, Opera Software
Naina Raisinghani, Google
Melanie Richards, Microsoft
Hiroshi Sakakibara (BPS, Beyond Perspective Solutions)
Jen Simmons, Mozilla
Geoffrey Sneddon, Invited Expert
Alan Stearns, Adobe
Surma, Google
Jet Villegas, Mozilla
Greg Whitworth, Microsoft
Steve Zilles, Adobe
Scribe: Myles
Grid
====
Implied Minimum Size of Grid Items
----------------------------------
issue: https://github.com/w3c/csswg-drafts/issues/283
fantasai: We were waiting for approval from Rossen and Igalia.
Rossen: It's a never-ending issue.
fantasai: Tab and I reviewed the issue.
fantasai: Percentages and intrinsic sizes deferred from last TPAC.
Rossen: I'm okay with intrinsic sizes.
fantasai: Resolved?
Rossen: Any objections?
Rossen: [reads final resolution]
Rossen: Clamping of fixed track size based on max size for implied
minimum (is the proposal).
RESOLVED: Automatic minimum is clamped by max track size not final
track size.
<fantasai> Specify that min-width: auto only resolves to the
automatic minimum size if the item spans at least one
track whose min track size is auto. It is otherwise
zero.
Rossen: any objections to ^^^?
RESOLVED: Specify that min-width: auto only resolves to the
automatic minimum size if the item spans at least one
track whose min track size is auto. It is otherwise zero.
Rossen: Let's close it.
fantasai: Yeah once edits are in.
Percentages and intrinsic size
------------------------------
<fantasai> https://github.com/w3c/csswg-drafts/issues/509
Rossen: In TPAC we resolved to keep percentages the same between
flex and grid, however they resolved
Rossen: and during intrinsic size computation.
Rossen: What was left was to decide if we try to reverse the
actual percentages, or do they compute to 0 (as we do for
most other things).
Rossen: Our position since TPAC is that they should be resolved to
0.
Rossen: Talking to manuel from igalia, he agrees.
Rossen: We need to reach consensus!
Rossen: Any opinions?
iank: Let's resolve to 0.
fantasai: I thought the other option was treating percentage track
sizes as auto
fantasai: not resolving to 0.
fantasai: I don't want to see that people will say 100% and it
will overflow.
Rossen: That won't be a problem.
fantasai: Is it resolving to 0 always or just for intrinsic sizing?
fantasai: the grid gaps definitely resolve to 0, but what about
grids that have content? why should that resolve to 0?
Rossen: 2 issues: percentage resolution for width of grid items,
and percentage resolution for margins and paddings.
Rossen: We'd compute width and height for auto always during
intrinsic sized calculations for everything else in order
to let the content inside measure itself. And the result
is whatever the content decides so it's not 0 for width
and height but for margins and paddings its 0.
fantasai: That's for intrinsic sizing, but not for real layout.
fantasai: Nobody wants overflow for intrinsically sized things.
fantasai: It should honor the percentage always or never.
fantasai: Honoring for layout but not intrinsic contribution is
not author friendly but it is engine friendly.
gregwhitworth: igalia says whatever we do for gaps should also be
done for tracks.
fantasai: Already resolved.
Rossen: Let's keep them consistent.
fantasai: Gaps have no content, so their intrinsic size is always 0
fantasai: For a track that has 0 content, it will work the same
way. If it has content it might not be 0.
fantasai: Gaps can't have content.
rachelandrew: The issue is if we are using a track as a gap for
some reason.
fantasai: I object to a solution which results in overflow.
Rossen: OK.
fantasai: There are cases where we might need to deal with it for
compat reasons like floats, but not here.
Rossen: Inline blocks need it
Rossen: as well as flexbox currently.
Rossen: We have implementers who want 0, fantasai wants an
objection.
fantasai: Computing to 0 doesn't make any sense.
fantasai: Please make a proposal.
fantasai: Resolving to 0 only works for gaps.
fantasai: Can we describe this option that is actually reflected
in what we're talking about.
jensimmons: 3 options, none compute to 0.
Rossen: Preferably the spec needs to be updated. First: the
percentage resolution should be done like how it was done
before like in grid blocks, Second: explicitly say
percentage gaps are resolved to 0 pixels when the height
is undefined.
Rossen: That is the last proposed behavior by manuel.
dbaron: Generally I would want to do better than 0 but
historically (outside of tables) Gecko is the only engine
that tries to do so.
fantasai: What does 0 mean?
Rossen: 1. The way we compute percentages for grid items inside
grid tracks, 2 the way we handle percentages for tracks,
and the way we percentage for gaps. These are separate.
fantasai: Gaps is easy: they are treated as empty tracks.
fantasai: So solution just falls out of that.
Rossen: Yes.
Rossen: For tracks, if we say that percentage resolves to auto,
meaning that you compute the intrinsic size, the size of
the track becomes that of the collection of grid items
inside of the track, then it becomes auto.
Rossen: the size of the track is computed based on the grid items
inside, and this is consistent with gaps, (because gaps
with auto will be 0), so our previous resolution stands,
and everything is ok.
Rossen: I would be okay resolving that tracks and gaps will be
computed as auto for these purposes.
fantasai: I'm okay with it too.
Rossen: Let's resolve!
fantasai: I want to make sure that we aren't self-inconsistent
because...
Rossen: We aren't.
Rossen: We were miscommunicating.
fantasai: No I was talking about items.
Rossen: We are in agreement about how tracks and gaps should work.
Rossen: We didn't resolve on gaps and tracks resolving to auto. We
resolved that they do the same thing but not about auto.
jensimmons: Before we resolve about auto, can we talk though the
rest of what's hard? We need to state implications.
Rossen: Let's assume we have 1 track with 1 item inside-
Rossen: item is 100% width and auto everywhere. Inside the item it
says "hello".
fantasai: That's about percentage on the item, not percentage on
the track.
Rossen: I'm explaining the scenario in its entirety.
fantasai: We have many differet scenarios.
fantasai: We need to think through use cases.
fantasai: What you were just proposing to resolve is not that case.
fantasai: You were talking about percentages on tracks being
treated as if they are auto, which is not this case.
Rossen: I was getting there.
Rossen: The track has 100% as well.
Rossen: The grid itself is float left.
Rossen: Sooooooo,
Rossen: the track is percentage, the 1 item inside is 100% width,
inside the item says hello.
fantasai: How about we start with the grid item doesn't have a
percentage based width.
Rossen: Let's say the grid item is fixed width: 100px
Rossen: In this case, the track (since it's percentage, but it is
asked the question how large can you be and how small you
can be without breaking your content)
Rossen: the track needs to answer that question. It will need to
ask its content inside. = 1 item, which is 100 pixels. So
the track can answer the question (100px). It doesn't have
a reason to be wider than that, so the result is a track =
100px with 1 grid item which has width=100px and stuff
inside.
fantasai: Now! If that track was instead 50%, what happens?
Rossen: So then, we would have the track would still report 100%
during intrinsic size, then when layout starts (real
layout) the parent, if it has 100px available, will give
it 100px of space. The track will then compute its
percentage, and will come out to be 50px. Then the
internal item will still be 100px and it will overflow.
fantasai: What is the use case for this behavior?
Rossen: I don't understand the question.
fantasai: Why does an author want this?
jensimmons: How about when the track is 50% then it still gets
100px.
Rossen: That means the grid gets 100px whitespace.
fantasai: Disadvantage is that as the percentage gets smaller, its
impact on the size of the container explodes. This isn't
great.
fantasai: Any cases that are close to 0 don't get overflow, what
is what you want.
fantasai: Another possible behavior: do all this stuff during
layout. We say "no, your percentage is invalid so you
get auto" so it lays out as 100 px because it forgot
about percentage.
fantasai: You say that if we ask for shrink wrapping, it
overflows, which is against the idea of shrink wrapping.
What is the use case for overflow here?
Rossen: I don't have any use cases.
fantasai: When an author gives a percentage, they want it to be
honored. When they say shrink wrap they don't want
overflow.
fantasai: You are trying to honor the percentage by overflowing.
fantasai: That isn't great.
Rossen: Can ::you:: propose a way to resolve this?
Rossen: It has to work with multiple percentage tracks with
percentage grid items. Something that won't explode in the
opposite way (b/c of used space).
Rossen: If you have this, I'd be happy to review it.
fantasai: I don't have an answer. but I object to always choosing
overflow. Nobody has a use case for overflow.
Rossen: They shouldn't have backward dependency.
fantasai: But it will happen.
fantasai: We should be thinking about use cases and not just what
is easy for an engine.
fantasai: use case = if you have an item in a track and if you
have a bunch of images, each has width = 100%, and you
have other content, and you want the width = 100% to
take that. you won't get the good result out of your
algorithm.
fantasai: A different algorithm would solve that. maybe that
algorithm is bad, but this one is definitely bad.
fantasai: Your solution has ::no:: use cases.
Rossen: I'm stating what's in the issue and what the web does
today.
jensimmons: fantasai, can you explain if you have a preference for
how you think this should work, what it is? or what
are the options that would work well?
fantasai: I don't have a clear idea other than overflow is always
bad.
jensimmons: What is left then?
fantasai: 3 options: 1) what we do with heights for blocks: if a
percentage height depends on its size of its container
and its container depends on the height of the items,
then we use auto. And this applies to intrinsic sizing
and layout.
Rossen: That would work if the rule gets applied everywhere in the
subtree.
Rossen: This case doesn't honor percentages.
fantasai: 2) my #1 priority is avoiding overflow. Honoring
percentages is next. Option 2 is backcomputing
percentages which has weirdness as you get close to 0.
fantasai: If the author does something that makes sense that it
works, but otherwise we get weirdness.
fantasai: We do this for tables
fantasai: but its legacy.
fantasai: 3) If you are percentage size, your intrinsic size
contribution is 0 (and your percentage is not
resolvable).
fantasai: So other children in the parent take the whole space.
fantasai: Then during layout the percentage gets resolved against
whatever the parent chooses.
fantasai: That works for your image use case, jensimmons; but if
all the items in the container are percentage-sized, it
collapses to zero.
jensimmons: That would freak me out.
fantasai: None is ideal.
fantasai: 4) we overflow. this is bad
TabAtkins: Dropping to auto is best. it matches with other places,
doesn't overflow, easy to explain. When I think about
this stuff: the less magic that can appear, the better.
I teach, so magic means difficulty. Easy to explain is
good. That's what I'd like
jensimmons: Things becoming 0 is mystical.
jensimmons: Outer container = size unknown, inner container =
percent which is unknown, I don't see a practical use
case. I see it happening a lot but I don't see it as a
useful that is intentional. People just find
themselves in this situation.
fantasai: What are examples of when people find themselves in this
situation?
jensimmons: If you have a container w/ percentage because you're
not using grid yet
jensimmons: then if you put stuff inside with grid, ....... but
wait this isn't a problem.
fantasai: One of the advantages of collapsing to 0 - the whole
thing turns into 0 if everything is percentage sized.
fantasai: Maybe we should look at other situations.
fantasai: ::draws on board:: a container, with an item inside, and
you want the inside item to be the size or the
container, but the container is sized by another child
with text inside.
jensimmons: Which option makes this works?
fantasai: The one where intrinsic size computation disagrees with
layout calculations.
iank: ::explains::
Florian: What's the downside?
fantasai: ::explains::
fantasai: Another way to solve this use case, I'm happy to go with
"just make everything auto"
jensimmons: What happens if we take that solution?
fantasai: Then you would get the container sized to the intrinsic
size of the image.
jensimmons: In this situation people would probably just add more
percentages everywhere.
fantasai: Is there a way to solve this use case anywhere else?
<dbaron> I think I do have another way to solve that case...
<tantek> jensimmons do you have a link to an example how people
are trying to do this today without grid?
Rossen: Another way is to make a hybrid: resolve to 0 always in
the presence of at least one grid item with non-percent.
Florian: That does not sound crazy.
Rossen: So you detect when to use which algorithm.
Rossen: This is an option but I don't like it.
fantasai: That would be confusing in terms of the layout
architecture.
fantasai: We don't have the case where the intrinsic size
contribution of a box is dependent on the size of its
siblings.
iank: Yes.
Rossen: That's computable easily
myles: If you add a child in script that triggers the other
codepath you get wildly different results.
iank: I also don't like the solution.
dbaron: Another solution that would let people do various things
that I've had in my head for a while that I was discussing
at dinner last night is that we should probably have
properties that let you assign the intrinsic sizes.
dbaron: That are different than width and min-width and max-width.
dbaron: These properties don't affect layout calculation, just
intrinsic sizes.
<dbaron> min-content-width, max-content-width,
min-content-inline-size, max-content-inline-size, etc.
<dbaron> (also -height, -block-size)
fantasai: ::writes all the options on the board::
1. Ignore percentage and treat as auto
2. Back compute percentages
3. Percentages contribute zero, but resolve afterward
4. Percentages contribute intrinsic size, resolve afterward
during layout
5. #3 unless all siblings are percentage, else #1
dbaron: I'll probably write a proposal for my idea independently
because they are valuable in their own right.
Rossen: Those don't actually help here.
dbaron: Actually it does work.
dbaron: ::explains::
jensimmons: You need very advance authorship to get this right.
Rossen: min-width and max-width can conflict
Rossen: but it would be fun.
Rossen: This is a powerful feature on its own.
Rossen: We'll have to work out its interaction with other sizing
properties.
Florian: If you use these properties to make the intrinsic size of
something depend on the rest of layout, that is scary.
zcorpan: What if you use percentages here?
dbaron: They wouldn't take percentage values.
dbaron: I did think about that.
Rossen: #2 "back-compute percentages" isn't numerically stable if
you have multiple tracks
Rossen: but if there is a proposed discrete algorithm, I'd be
interested.
iank: Would also change it for all layout modes.
Rossen: The web currently runs on #4 (percentages contribute
intrinsic size, resolve afterward).
fantasai: Except for some smaller cases that do #2.
jensimmons: Maybe we are leaning toward #3 (percentages contribute
zero, but resolve afterward).
Rossen: Why is 3 better than 4?
::general confusion::
jensimmons: This use cause will happen a lot.
Rossen: Authors will always shoot themselves in the foot.
dbaron: What's the difference between 1 and 4?
dbaron: #1 is the only one that affects layout.
Rossen: #1 is invasive and weird.
fantasai: #3 overflows the same way as 4.
Rossen: And is less useful than 4.
Rossen: If you have something that isn't an image, it will
contribute its size up to the track. So if everything
happens to be 100% in your track, you have a good looking
layout.
Rossen: If it's 50%, you have overflowing layout which is somewhat
consistent.
Rossen: In #3, you end up with 0 which is bad.
Rossen: I'm not proposing 3. I am proposing 4.
fantasai: #5 is bad.
Rossen: #5 is bad.
zcorpan: Floats use which?
<zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4807
float
<zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4808
table
fantasai: Mostly 4, sometimes 2.
Rossen: Every implementation except for some parts of gecko give
you 4.
Rossen: We spent exactly 7 days in a room trying to come up with
something clever with #2 but we gave up
Rossen: because it's easy to break
Rossen: trivially.
dbaron: #2 is done reasonably interoperable for tables, and is
done by gecko for margins and padding on inlines, although
in a slightly odd but not-that-bad way.
dbaron: If you have a float with percentage margins inside it,
gecko does it.
dbaron: Percentages on table cells or columns which causes
back-computation.
<dbaron> (that's responding to zcorpan's link)
iank: But only 1 level which makes it sane.
jensimmons: should we discuss examples and results?
<tantek> jensimmons: yes
<Rossen> http://jsbin.com/bimecoqasi/edit?html,css,output
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22float%3A%20left%3B%20border%3A%20solid%22%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20solid%20orange%3B%20width%3A%2040px%3B%20margin%3A%2025%25%22%3E
<zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4809
% padding on td
Florian: Rossen, you want #4 right?
Rossen: Discussing this with igalia, they want #4. I just heard
iank also say he wants #4 (iank: mhm). We are also in
favor of #4?
Rossen: We want to move grid forward
Rossen: on the rec track.
Rossen: This is one of only a few issues which are left.
Rossen: (pun not intended)
Florian: If we do #4, how do we do jen's use case?
Rossen: It works.
Rossen: Nevermind.
Rossen: In order to make jen's work, we need #3.
Rossen: Which is a change of behavior for web compat.
Florian: Can we make it work if we use dbaron's properties?
zcorpan: Yes.
Rossen: Yes.
Rossen: intrinsic-size: 0% and you are done.
zcorpan: you mean "0".
Rossen: yes.
Florian: Which opts you into #3.
jensimmons: This requires authors to use it, but authors would
bail.
jensimmons: People would just put a size on the grid container
instead of doing this.
rachelandrew: I don't like this idea of collapsing to 0, because
it's easy to accidentally do this.
jensimmons: It only collapses to 0 in the browser's mind, but then
the browser changes its mind.
Rossen: If there's nothing in the track, it goes to 0.
Florian: But if only percents in the track, 3 collapses to 0.
tantek: Yep.
rachelandrew: I prefer #4.
Rossen: Yes.
Rossen: What if we resolved???????????
Rossen: Call to action to see if people can make #2 work. But in
the absence, #4 seems safest.
iank: It would be a lot of fun
iank: ... to try to get #2 to work, but we would have to spend a
long time staring at it. In the absence of that, #4 please
gregwhitworth: "call to action" = time commitment?
<tantek> I think I prefer #2 for authors, and if that's not
implementable (or costly), then #4 seems like a
reasonably predictable alternative.
fantasai: ::writing on board:: #6: percentages contribute their
minimum size (min-width), but resolve afterward
fantasai: and we have an "auto" keyword to min-width.
fantasai: this is #4 with an opt-in to #3
fantasai: w/o adding a new property.
fremy: You can't change this behavior for existing layout models.
fremy: We can't change how "block" works.
Rossen: And you don't solve jen's case.
fantasai: You solve jensimmons case by writing img { width: 100%;
min-width: 0 }
Florian: You're not controlling the intrinsic size through
min-width. Instead, you are choosing not to use the
intrinsic size.
fremy: Grid items don't stack. They are drawn on top of each other.
fremy: Oh that's a column (to fantasai).
zcorpan: It's confusing to have different behavior in different
contexts. We should pick something that is consistent
with what we already have (like 4).
zcorpan: We can give tools to opt-in to other behavior (like
dbaron's stuff).
zcorpan: It becomes much more predictable
zcorpan: ... what the behavior is.
Rossen: OK.
<gregwhitworth> +1 zcorpan
Rossen: Let's try to resolve.
iank: I agree with zcorpan.
astearns: straw poll?
Rossen: Let's eliminate some stuff. #1?
fantasai: Yes.
Rossen: #2?
Florian: Is #2 possible to implement?
iank: It requires research.
tantek: #2 is like tables.
::general murmuring::
<dbaron> An example where Gecko back-computes percentages is:
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Adiv%20%7B%20background%3A%20aqua%3B%20float%3A%20left%3B%20border%3A%202px%20solid%20blue%3B%20%7D%0Aspan%20%7B%20margin-left%3A%2050%25%3B%20background%3A%20yellow%3B%20display%3Ainline-block%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%3E%3Cspan%3EHello%3C%2Fspan%3E%3C%2Fdiv%3E
<tantek> that seems to support #2 being implementable
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22float%3A%20left%3B%20border%3A%20solid%22%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20solid%20orange%3B%20width%3A%2040px%3B%20margin%3A%2025%25%22%3E
fantasai: This shows #2 behavior in block-level layout in gecko (
and nowhere else).
Rossen: Authors use percentages.
Rossen: If you argue for one side of percentages, i'll argue for
the other side.
dbaron: If your percentages add to > 100, you get strange results.
<iank> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22float%3A%20left%3B%20border%3A%20solid%22%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20solid%20orange%3B%20width%3A%2040px%3B%20margin%3A%2075%25%22%3E
<iank> ^explody example.
Rossen: Goes through items on board, to recap.
fantasai: #3 is useful for images or empty boxes, but not for
things with content.
Rossen: Kills #3
Rossen: 4? (gets some votes)
Rossen: Kills #5
Rossen: #6?
fantasai: #6 is #4 by default, but you can use min-width to
opt-out toward #3.
fantasai: This is useful for images.
Florian: #4 and #6 are good.
<dbaron> I don't like adding even more behavior to min-width (#6).
Options:
1. Ignore percentages
2. Backcompute percentages
3. Percentages contribute intrinsic size, but resolve afterward
4. #3 with a switch based on min-width
<dbaron> #4 renumbered to #3, #6 renumbered to #4
Florian: How realistic is dbaron's proposal?
dbaron: Pretty realistic because implementations already have the
concept.
dbaron: My thing makes #4 kind of silly because I don't want to
add yet-more behavior to min-width
dbaron: if you set min-width, you get all of these different
things with #4.
rachelandrew: I'd rather have a new property than doe something
new with min-width.
<tantek> agree with rachelandrew, rather not overload min-width
zcorpan: I want to be consistent with floats. Floats do different
things in different implementations. Spec is not clear.
fantasai: It's undefined.
Rossen: Almost everywhere floats do new #3.
fantasai: There is no spec.
Rossen: At some point we tried to agree but dbaron said he would
try to find the algorithm and define it and we didn't
finish.
dbaron: When you say "floats are different" do you mean stuff
inside floats or anything else that uses intrinsic sizing?
zcorpan: I mean the last 2 cases that were in IRC.
Florian: Those are just for shrink-wrapping.
dbaron: There was nothing specific to shrink-wrapping in those
example. I just wanted shrink-wrapping.
zcorpan: We should use the same behavior as shrink wrapping today.
dbaron: Grids have more complicated structure.
fantasai: If you do this with margins and paddings, and put the
percentage on the width, then it would overflow, because
the contents of floats that are percentage sized need to
not .... [trails off]
fantasai: Gecko was able to get things to not overflow for compat
for margins and padding, but not for width.
fantasai: We are looking at 3 different things, track, the grid
item itself, and the grid.
Rossen: Nobody ever said that tracks should follow #1
fantasai: But that was your first proposal!!!
fantasai: Flexbox does it too.
Rossen: Not quite.
fantasai: The difference between Flexbox and #2 is you can't go
over 100% because it's impossible. but! The flexing in
flexbox and the flexing in grid does #2.
fantasai: We use the ratios, and then backcompute how big the
thing has to be.
Rossen: Not overflowing is nice.
iank: Can we rule-out 2
iank: because implementors aren't sure it's possible.
iank: Rossen stared at it for 7 days trying to get it to work, we
aren't sure if it would work
Florian: It would be bad if we ended up in the same situation as
today with some browsers doing it one way and other
browsers doing it another way
Florian: unless everyone says they can do #2, we shouldn't
consider it.
Rossen: Let's straw poll
Rossen: Does everyone understand the issue enough?
<dbaron> Honestly, I don't think I understand the issue enough...
Straw Poll:
<Florian> 3, 4
<iank> 3
<TabAtkins> 1,3
<philipwalton> 3
<gregwhitworth> 3
<astearns> abstain
<zcorpan> 3,2
<surma> 3
<rachelandrew> 3
<myles> abstain
<jensimmons> abstain
<dauwhe> abstain
<Bert> abstain (I understand what they do, but can't say which is
better...)
<fremy> 3,2,1
<Rossen> 3
<gsnedders> 3, 2, 4, 1
<fantasai> copy Bert
<dbaron> I'm definitely against 1 and 4, but I don't actually
understand what we're talking about well enough to choose
between 2 and 3.
<melanierichards> ^ same
<tantek> mild pref for 2 (like tables), but similar to dbaron,
insufficient evidence to be sure 3 is not better
<jensimmons> (I'd need to go through common use cases to
understand how it impacts authors to be able to vote)
dbaron: I understand the behaviors, but not what we're applying
them to.
Rossen: We are applying them to grid items
Rossen: and also grid tracks.
(laughter)
fantasai: Actually let's do everything
fantasai: for consistency.
Rossen: We agree gaps and tracks behave the same.
Rossen: Consensus is #3.
RESOLVED: "Percentages contribute intrinsic size and they resolve
after layout"
Stretching images in a ratio-preserving way
-------------------------------------------
Rossen: 1 more issue:
<Rossen> https://github.com/w3c/csswg-drafts/issues/523#issuecomment-270514935
<fantasai> https://github.com/w3c/csswg-drafts/issues/523#issuecomment-268095890
fantasai: Mats's main objection is we have a solution for how to
put (ratio-preserving) an image in a grid area if its
bigger than the cell in its intrinsic size but not if
its smaller.
fantasai: Our previous resolution is good because I don't want to
put more sizing behavior in the alignment properties.
fantasai: The proposal is to add more keywords to do sizing in
alignment, which I definitely don't agree with,
fantasai: but the problem is valid
fantasai: but the way forward is not to revert the resolution.
astearns: Can we keep the resolution and perhaps work on this
later?
Rossen: Why not now?
Rossen: We are here.
Rossen: People are waiting for this.
jensimmons: I don't think we want to change after we ship.
Rossen: We've beaten this issue down so much ....
fantasai: I'm happy with our resolution because it preserve the
behavior of alignment of limiting its sizing controls to
just stretch
fantasai: we cut ourself off.
Rossen: Agreed.
fantasai: As far as the grid spec is concerned, we don't do
anything else here
fantasai: but we do have an issue against sizing where we need to
figure this out.
Rossen: Sizing or alignment?
fantasai: Sizing.
fantasai: Alignment is placement, sizing is ... sizing.
fantasai: Question is: how do we take the constraints of the box
and find the size of the thing that fits in the box.
fremy: So that means that the solution is in dbaron's new proposal.
Florian: With dbaron's thing it works.
Florian: You say "my intrinsic size is very large".
fantasai: You will get unexpected side-effects.
Rossen: Let's try to solve the issue with the tools we currently
have.
dbaron: I'm confused with the issue.
dbaron: Sounds like Mats agrees with what we resolved, and
fantasai sounds like she agrees with what we resolved, but
you're disagreeing.
astearns: In his response to the announcement, Mats disagrees with
"image grid items should not stretch at all by default"
<astearns> Mats's response to the minuted resolution:
https://lists.w3.org/Archives/Public/www-style/2017Jan/0006.html
fantasai: Mats wants contain behavior as the default for images.
fantasai: I'm opposed to that because that's a sizing behavior you
can't get with alignment.
dbaron: He wants contain behavior for images which are grid items.
fantasai: Might be reasonable except that alignment changes that
behavior, so you can't do both.
<jet> https://github.com/w3c/csswg-drafts/issues/523#issuecomment-271408851
[Mats's comment: My counter-proposal is that images should stretch
by default (as all grid items do) but in a ratio-preserving
way (as is expected for images in general), and that we solve
the remaining issue with how to align it in the non-filled
axis by adding some minor additions to CSS Align.]
Florian: If we solve it in sizing, that doesn't work.
Florian: To solve it in sizing, we have to keep the behavior we
resolved on, not the one he's asking for.
fantasai: Right now if you have several sets of alignment values
which have different behaviors.... normal is the initial
value, then we have stretch and start, center, end.
fantasai: start/center/end trigger shrink-wrap,
fantasai: stretch means I'm the same size as my grid item always,
fantasai: normal should be the same as stretch or start/center/
end, not a 3rd behavior,
fantasai: required to do alignment for alignment and not also do
sizing.
fantasai: So the default behavior (and start/center/end) gets
contain, or we take what we already resolved on.
fantasai: I don't have a strong opinion.
fantasai: I just don't want sizing keywords in alignment.
TabAtkins: Yes.
Rossen: Yes.
fantasai: 2 options: 1) No change to default grid sizing;
fantasai: non-replaced elements map to "stretch" and replaced
elements map to "start" and this is intrinsic size.
fantasai: and add new keywords to width and height for contain
<dbaron> Do you get the contain behavior if you specify a very
large width and also max-width: 100%; max-height: 100% ?
fantasai: 2) make default sizing contain
fantasai: This means non-replaced stretch (we don't want to change
this default behavior) and replaced items still map to
"start" but "start" isn't the same as intrinsic size,
it's equivalent to "contain". and use keywords in
"width" to get intrinsic size.
fantasai: I'm okay with either of these, but nothing that isn't
these.
dbaron: So what's the difference between these and the proposal?
fantasai: The current working group resolution is #1.
fantasai: In the issue, the proposal is to add new capability of
alignment to have it control sizing.
fantasai: 3) Add sizing options to alignment [Mats's proposal]
fantasai: .... and change default behavior to new keyword.
tantek: It sounds like we're focusing on new keywords, but Mats's
focus is on more author-friendly default behavior.
Florian: But the mechanism he achieves that is the thing that
fantasai objects to.
gregwhitworth: Even if you do that, you end up with a result which
isn't that author-friendly.
gregwhitworth: ::repeat an existing argument from the issue:: (
Mats's comment on Dec 1)
gregwhitworth: #1 is fine, and we can add new sizing keywords if
object-fit isn't sufficient.
fantasai: object-fit isn't sufficient. (draws picture to show why)
fantasai: Because there is a distinction between CSS box vs
replaced content boxes.
fantasai: I'm okay with #2 and that would make Mats happy.
jensimmons: What if we add new keywords to width and height to
contain? what does it look like to authors?
jensimmons: Like "width: contain;"???
jensimmons: Does this work everywhere?
fantasai: yeeeaaahhhhhhh....
fantasai: Probably would do a functional notation.
jensimmons: Could be useful.
dbaron: Doesn't necessarily apply everywhere.
dbaron: Can sort of do it today by "max-width: fill-available,
max-height: fill-available, width (or eight but ot both):
really-big-number"
dbaron: Maybe we should have a value that is "big".
Rossen: What if we continue thinking about this over a break.
<break>
Scribe: fremy
fantasai: There are 3 desirable behaviors for images:
fantasai: Stretch, shrink to fit, contain.
fantasai: Mats would like contain by default for images
fantasai: it seems useful to have keywords to control
fantasai: but the default is another question.
Rossen: Lets decide on default.
fantasai: Mats wanted contain by default, but we only do this by
constraining to allow smaller size right now.
TabAtkins: If we just go with number 1, and don't add anything
new, everything works except small images
TabAtkins: and even for small upscaled images there are
workarounds, if you know roughly your aspect ratio.
jensimmons: But by default a big image would overflow.
TabAtkins: Yes, but you can specify max-width: 100% like any other
place in css.
fantasai: But I think the agreement is that we don't need any new
alignment.
gregwhitworth: (clarification between object-fit cover and contain
behaviors)
fantasai: Blowing up and pixellating small images isn't great.
fantasai: In block layout, if you don't do anything, the image
uses its intrinsic size, you also need to specify
max-width [in response to jensimmons question which was
missed]
jensimmons: I think grid is different, we should not care about
matching block.
Rossen: No, I don't think.
zcorpan: And I would agree that anything but option 1 would be
unpredictable.
Rossen: Agree with option 1 too.
fantasai: +1
fantasai: To allow Matt's preferred behavior we would add a
"contain" value to width and height in css-sizing.
fantasai: It works as existing content filling value for things
that have no aspect ratio
fantasai: but for things that have one, you would choose the best
size to match min(CB width, max-width) x min(CB height,
max-height).
dbaron: Can't you just drop the max-width/max-height part here and
let the normal rules do that?
Rossen: And for intrinsic sizing?
Rossen: A proposal would be add contain as an optional keyword for
width.
fantasai: Not clear to me what that means.
Rossen: Okay, let's answer the intrinsic sizing question then.
fantasai: There are several options:
fantasai: 1 use the intrinsic size as we had specified max-content.
fantasai: 2 treat as 0.
fantasai: 3 use the calculation.
dbaron: Then you don't have CB width/height yet.
fantasai: Then you fallback.
dbaron: Doesn't work.
Rossen: Proposal would be to behave as auto.
<dbaron> I think 0 is fine
fantasai: Or fallback to icb width.
Rossen: But then you blow up to viewport size, doesn't seem useful.
fantasai: Agree.
fantasai: But what does fill-available do?
dbaron: It behaves like auto.
fantasai: Then I would match.
dbaron: I am not sure I'd want it like 'auto' [?].
TabAtkins: I would agree with that "auto" option.
Rossen: So I think we have a few questions to answer but a clear
way forward
Rossen: but we could resolve on getting grid behave like
everything else.
jensimmons: So if we don't do 2 we have to use workarounds to get
the contain behavior on small images.
fantasai: Yes (explains workaround).
Scribe: gregwhitworth
jensimmons: Does it matter if I apply height and width contain?
fantasai: Yes you have to apply both to get the effect.
fantasai: If you apply both you figure out what they are and
assign that to the width property.
Rossen: I don't see how this is aspect ratio preserving.
fantasai: Contain means aspect ratio preserving.
fantasai: You use the contain algorithm from object fit to
preserve.
Rossen: Oh that's what I was missing.
jensimmons: If I'm in grid and that the grid has an explicit
height and the items say width contain and height
contain does it do anything?
jensimmons: So in some situations it will do something others it
won't.
jensimmons: This is going to be incredibly useful.
fantasai: If the whole goal is to preserve aspect ratio maybe we
should do it as much as possible.
jensimmons: This will be my new favorite property.
Rossen: Let's go back to try and resolve this issue.
Rossen: Let's ask for 1.
jensimmons: I'm the only one asking for 2, and I'm not going to
object.
Rossen: Okay, any objections to resolve on option number #1: no
change to the default sizing, non replace get stretched,
replaced gets start and add new sizing keywords to address
the issues.
jet: I think our feelings on two or one depend on the sizing
discussion.
fantasai: So do we want to do a resolution
fantasai: that says we need to add contain?
RESOLVED: We're keeping the current specified behavior as it is.
fantasai: If there is consensus to add contain on principle then
maybe we should add it.
Rossen: In order to do that I need to understand better how
contain works
Rossen: and that's a discussion that needs to happen on its own.<div
id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Tuesday, 14 February 2017 02:33:40 UTC