New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-grid] Stretching image grid items in both dimensions #523

Closed
MatsPalmgren opened this Issue Sep 22, 2016 · 60 comments

Comments

Projects
None yet
@MatsPalmgren

MatsPalmgren commented Sep 22, 2016

I'm wondering about how we should stretch grid items that has
an intrinsic ratio, such as images. The Grid spec just refers to
css-align which says:
https://drafts.csswg.org/css-align-3/#justify-self-property
"the stretch keyword sets the box’s used size to the length necessary
to make its outer size as close to filling the alignment container
as possible while still respecting the constraints imposed by
min-height/min-width/max-height/max-width."

which I think means that having 'stretch' in both dimensions
will resize the image to fill the grid area without respecting
the image aspect ratio
. I think this is a rather unfortunate
default behavior for Grid.

Some background; this topic was discussed for flex items here:
https://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
where everyone seems to agree that respecting the ratio is desirable,
but for various flex layout specific reasons, this could not be
achieved and it was decided to ignore the ratio (IIUC).

As far as I can tell, those reasons do not apply to Grid, so I see
no reason why we can't respect the ratio when stretching grid items
in both dimensions.

I think web authors generally prefer to preserve aspect ratios,
so that's what I think we should do for grid items.

@mrego

This comment has been minimized.

Member

mrego commented Sep 22, 2016

We were discussing that yesterday at TPAC (@fantasai, @jensimmons and me).
The conclusion we got was that the image should stretch (grow or shrink) in both directions, so we don't respect the aspect ratio unless you manually set width (e.g. width: 100%) or use a different value for alignment (like "start").

@fantasai

This comment has been minimized.

Contributor

fantasai commented Sep 22, 2016

Well, actually manually setting the width won't cause the aspect ratio to be observed: it just sets the width in that dimension, and since the initial value of align-self is stretch, the other axis will continue to just stretch.

Squishing images seems a little odd, but as a starting point it's useful: the object-fit options are then only one step away, and the alignment options can be used to release the stretch in either or both axes easily.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Sep 22, 2016

(Plus it's consistent with how blocks behave so not surprising at all.)

@MatsPalmgren

This comment has been minimized.

MatsPalmgren commented Sep 22, 2016

@mrego I don't think that solution works, because setting width:100%
might cause the image height to overflow the grid area. So the author
needs to know upfront the relative ratio of each image vs its grid area
to know which dimension to stretch. This is very inconvenient.

My proposal doesn't have that problem.
(and if by chance an author wants a ratio-destroying stretch to fill
its area completely, they can simply use width:100%;height:100%)

@MatsPalmgren

This comment has been minimized.

MatsPalmgren commented Sep 22, 2016

@fantasai, I don't think object-fit:contain works either since
it works on the content box, not the margin box as we want for
grid items. So if you add padding/border/margin to the image it
will cause overflow. Besides, the rule becomes somewhat elaborate
and requiring that authors comes up with workarounds like that for
something that ought to be the default behavior is inconvenient.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Sep 23, 2016

Cover example, image proportionally sized and clipped to fit:

  img { object-fit: cover; }

Contain example, margin/border/padding fitted to grid slot and image proportionally sized into it:

  img { object-fit: contain; }

Contain example, margin/border/padding fitted to proportionally scaled-down image:

  img { justify-self: center; align-self: center; min-width: 100%; min-height: 100%; box-sizing: border-box }

Contain example with future syntax, margin/border/padding fitted to proportionally scaled-down image:

  img { foo-self: center; max-size: fill; }
@MatsPalmgren

This comment has been minimized.

MatsPalmgren commented Sep 25, 2016

img { object-fit: cover; }

As you say, this leads to the image being clipped and is thus
not a solution to the problem at hand.

img { justify-self: center; align-self: center; min-width: 100%; min-height: 100%; box-sizing: border-box }

This leads to the image overflowing when the window is very wide
or very narrow. Thus it is not a solution to the problem at hand.
(also, having a margin doesn't seem to work?)
I've made a demo here:
https://people.mozilla.org/~mpalmgren/tests/grid/grid-align-center-min-width-demo.html
(Chrome has some problems when resizing this demo)

img { foo-self: center; max-size: fill; }

Suggesting magic future tech to solve this problem isn't serious.
Besides, it still requires that you write the above workaround rule to get
what ought to be the default behavior.

img { object-fit: contain; }

I've made a demo of object-fit:contain here:
https://people.mozilla.org/~mpalmgren/tests/grid/grid-object-fit-contain-demo.html
(Firefox has some problems with this demo at the moment)

I see the following problems:

  1. Like with most object-fit values, it makes the image scale down
    inside its content box. This leads to gaps between the image
    and the border. (Try resizing the window to be very wide or
    very narrow with the demo above.) This leads to ugly layout
    if you try to use a border, box-shadow, outline etc, since users
    expects such decorations to wrap the image.
  2. Since the image doesn't fill the content box, I suspect this
    also leads to other problems... like CSSOM reporting the "wrong"
    image size, the baseline not having any relation with the actual
    image position etc. Visual effects such as opacity, filter etc,
    also applies in the gaps, i.e. "outside" the image proper. I also
    suspect min/max/-width/-height will be awkward to use when
    the image doesn't fill its content box.
  3. It requires using object-fit which I suspect is a lesser known
    property.
  4. It requires adding a rule to get the behavior that really ought
    to be the default: it's preferable if layout preserves the intrinsic
    ratio by default (which some CSSWG members seem to agree
    with in the earlier discussion about flex items).

My proposal doesn't have any of the above problems and it provides
the desired behavior by default.

@dauwhe dauwhe added the css-grid-1 label Sep 26, 2016

@dbaron dbaron added the Agenda+ label Sep 27, 2016

@MatsPalmgren

This comment has been minimized.

MatsPalmgren commented Sep 27, 2016

To be clear, what I'm proposing is that spec says something like this
for the stretch/stretch case:

If the grid item has an intrinsic ratio, then resize the item in a ratio-preserving way
so that it fills its grid area in one axis without overflowing the other, while also
respecting its min/max size constraints.

@dbaron

This comment has been minimized.

Member

dbaron commented Sep 28, 2016

(It's possible you might want that rule to be conditional on the element having object-fit: fill.)

@cbiesinger

This comment has been minimized.

cbiesinger commented Sep 28, 2016

It seems that the proposed text is a bit underdefined in terms of how min and max sizes interact with the "ratio-preserving way". Also I'm not sure that the current definition of min sizes in grid actually allow you to preserve the aspect ratio if the image is too big in both axes and does not have a width or height explicitly specified on the image.

@MatsPalmgren

This comment has been minimized.

MatsPalmgren commented Sep 30, 2016

(It's possible you might want that rule to be conditional on the element having object-fit: fill.)

There are some pros and cons with that, but I don't have a preference.
Either way is fine with me.

@dbaron

This comment has been minimized.

Member

dbaron commented Oct 5, 2016

It seems that the proposed text is a bit underdefined in terms of how min and max sizes interact with the "ratio-preserving way".

Presumably using the rules in CSS2 section 10.4 that apply to this case.

@dbaron

This comment has been minimized.

Member

dbaron commented Oct 5, 2016

Just discussed in today's teleconference (I'll try to link minutes later). The conclusion is that we can change the mapping of align-content/justify-content: normal so that normal doesn't turn into stretch for replaced elements in grid.

@MatsPalmgren

This comment has been minimized.

MatsPalmgren commented Oct 5, 2016

OK, so normal on images now means "stretch as much as possible (preserving the ratio) without overflowing the grid area" as I requested?

@MatsPalmgren

This comment has been minimized.

MatsPalmgren commented Oct 6, 2016

I really like the proposed solution to make normal behave as "stretch-with-preserved-ratio"
for grid items that has an intrinsic ratio. Thanks!
https://lists.w3.org/Archives/Public/www-style/2016Oct/0068.html

Could you please clarify which behavior you want when the *-self value
is normal in one axis and stretch in the other?

I think it should fill the grid area in the axis that has stretch and resize the item in
the other axis according to the ratio, possibly overflowing the grid area in that axis.
Is that correct?

@astearns astearns removed the Agenda+ label Oct 11, 2016

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Nov 5, 2016

Bug 1218178 part 3 - [css-grid][css-align] Implement ratio-preserving…
… 'stretch' alignment for grid items with an intrinsic ratio. r=dholbert

w3c/csswg-drafts#523

xeonchen pushed a commit to xeonchen/gecko-cinnabar that referenced this issue Nov 5, 2016

Bug 1218178 part 3 - [css-grid][css-align] Implement ratio-preserving…
… 'stretch' alignment for grid items with an intrinsic ratio. r=dholbert

w3c/csswg-drafts#523
@dholbert

This comment has been minimized.

Contributor

dholbert commented Nov 8, 2016

Could you please clarify which behavior you want when the *-self value
is normal in one axis and stretch in the other?

I think it should fill the grid area in the axis that has stretch and resize the item in
the other axis according to the ratio, possibly overflowing the grid area in that axis.
Is that correct?

@fantasai / @tabatkins, I think this ^ is a question for you.

Mats' suggestion here makes sense to me, FWIW (and I can't come up with anything that's more sensible).

kuoe0 pushed a commit to kuoe0/gecko-dev that referenced this issue Nov 10, 2016

Bug 1218178 part 3 - [css-grid][css-align] Implement ratio-preserving…
… 'stretch' alignment for grid items with an intrinsic ratio. r=dholbert

w3c/csswg-drafts#523

fantasai added a commit that referenced this issue Nov 24, 2016

[css-grid] Make grid items maintain intrinsic ratio in default case per
#523. (First cut, needs review, didn't address object-fit question.)
@fantasai

This comment has been minimized.

Contributor

fantasai commented Nov 24, 2016

Checked in an attempt at fixing this per above discussion. :) Please let me know if anything is askew. I took Mats's suggestion for handling normal+stretch.

Wrt basing on object-fit... On the one hand, I think that would be very handy. On the other, no other layout mode responds to object-fit, so it might be confusing that Grid does. Note that the same effect can be had by specifying place-self: stretch in addition to object-fit: contain or whatever. I'm open to feedback on this issue, though, if anyone has a stronger opinion.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Nov 24, 2016

Agenda+ for certification of edits and the details wrt normal+stretch / object-fit prior to publication. Looking for review from all three implementation teams, and anyone else who wants to take a look.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Nov 26, 2016

Oh, just wanted to check that we're all understanding that stretch in one axis and center in another axis preserves the aspect ratio, right?

@MatsPalmgren

This comment has been minimized.

MatsPalmgren commented Nov 26, 2016

No, stretch stretches without preserving the ratio, normal stretches with preserved ratio.

I would summarize what we have implemented as:

  1. place-self:normal normal (default) - stretches the item with preserved intrinsic ratio to fill the grid area in one axis without overflowing the other
  2. place-self:stretch stretch - stretches the item to fill the grid area in both axis (the ratio is not preserved, unless the grid area happens to have the same ratio)
  3. Otherwise, if stretch is one of the values, stretching occurs to fill the grid area in that axis.
    If the value in the other axis is normal it is resized to preserve the ratio (may overflow in that axis)
  4. Otherwise, If normal is one of the values, stretching occurs to fill that axis, the other axis is resized to preserve the ratio (it may overflow in that axis)

IOW, the intrinsic ratio is preserved if at least one of the values is normal.

It gets more complicated when one or both axis also has min-/max-size constraints. I think we're following the CSS2 rules[1] there -- we're re-using the code that already implements that. The stretching occurs before applying those rules.
[1] the "Constraint Violations" table at the end of §10.4:
https://www.w3.org/TR/CSS22/visudet.html#propdef-max-width

Also, when the track max-sizing functions are definite, clamping the item to fit the grid area (per §6.6 in CSS Grid https://drafts.csswg.org/css-grid/#min-size-auto) also affects the above rules (the "may overflow..." above should not be allowed when clamping in that axis IMO, but let's sort out the clamping effect on this in #767)

Here's a couple of testcases to illustrate our stretching behavior (I intentionally
avoided any §6.6 clamping in these tests):
Testcase for growing an image to fill a larger grid area:
https://people-mozilla.org/~mpalmgren/tests/grid/grid-item-image-grow.html
Screenshot of Firefox rendering:
https://people-mozilla.org/~mpalmgren/tests/grid/grid-item-image-grow-firefox.png

Testcase for shrinking an image to fit a smaller grid area:
https://people-mozilla.org/~mpalmgren/tests/grid/grid-item-image-shrink.html
Screenshot of Firefox rendering:
https://people-mozilla.org/~mpalmgren/tests/grid/grid-item-image-shrink-firefox.png

(You need a Nightly build for these tests to display correctly: https://nightly.mozilla.org/ )

@fantasai

This comment has been minimized.

Contributor

fantasai commented Nov 27, 2016

OK, so, what I want to point out is that from an authoring point of view, the intrinsic aspect ratio should be preserved unless there's specific instructions not to. Maintaining the intrinsic aspect ratio trumps preserving the intrinsic size in any single dimension. Always. Changing a dimension effectively modifies the user-perceived "intrinsic size" in the other. Internally, we can define terms however we want, but I'm pretty sure that as far as the author is concerned, anywhere that we are failing to do this is an error.

An alignment value of center is definitely not an instruction for auto sizing in that dimension to ignore the aspect ratio. Going back to when we did not have normal... the options for alignment were stretch | start | end | center. And if one axis was stretch and the other center then the aspect ratio would have to be preserved. Only if stretch were specified in both axes would the aspect ratio be ignored: the intention of all non-stretch values of the alignment properties is to do the automatic thing that best preserves the intended presentation of the content, and would use extra space for the specified alignment. Shrink-to-fit sizing, in general, preserves the aspect ratio and Grid + Alignment should behave no different for the values that trigger it.

To address your feedback that the default behavior should be to preserve the aspect ratio, we decided to add an independent behavior for normal so that the initial behavior would not be the skewed result of stretch stretch. So normal normal is defined to be like start start except that the larger dimension is treated as stretch to contain-fit the item within the grid area. This shouldn't, however, cause the aspect ratio to be ignored by the previously-existing value combinations that were intended to honor it.

p.s. Fwiw, I'm a little concerned that the new normal complicates the field of values for the alignment properties by adding yet another sizing value, in particular one that gives a useful behavior but doesn't allow the alignment values to act upon it.

@MatsPalmgren

This comment has been minimized.

MatsPalmgren commented Feb 3, 2017

Fwiw, I agree that an intrinsic size should also make normal be treated as start in that dimension. I see no reason why <input> should stretch to fill its grid area by default now that images don't, for example.

@FremyCompany

This comment has been minimized.

Contributor

FremyCompany commented Feb 3, 2017

Adding myself to the conversation since it seems we might change the spec again.

Also, here is a test case:

image image image
https://jsfiddle.net/1fd948nz/ (Edge, Chrome, Firefox)

@FremyCompany FremyCompany reopened this Feb 3, 2017

@FremyCompany

This comment has been minimized.

Contributor

FremyCompany commented Feb 3, 2017

Also variant https://jsfiddle.net/1fd948nz/1/
None of existing browsers would be the per-resolution expected behavior for those two tests, right?

@astearns

This comment has been minimized.

Member

astearns commented Feb 15, 2017

We amended the Seattle resolution on the call today:
RESOLVED: The sentence beginning with "Items without an intrinsic ratio use," is what we as a WG wanted to use
and clarified what should happen for things without aspect ratios:
RESOLVED: replaced elements with only one intrinisic size are sized as start in that dimension and stretch in the other

@astearns astearns removed the Agenda+ label Feb 15, 2017

tabatkins added a commit that referenced this issue Feb 23, 2017

@tabatkins tabatkins closed this Feb 23, 2017

@fantasai

This comment has been minimized.

Contributor

fantasai commented Feb 23, 2017

Initial draft of contain is now in https://drafts.csswg.org/css-sizing/#contain-fit-sizing ; comments welcome (though please not in this thread ;)

triple-underscore added a commit to triple-underscore/triple-underscore.github.io that referenced this issue Feb 25, 2017

[css-grid] w3c/csswg-drafts@98893bc Rephrase the grid item sizing rul…
…es to be readable, and properly capture the resolutions in w3c/csswg-drafts#523
@mrego

This comment has been minimized.

Member

mrego commented Feb 27, 2017

I'm going to implement this on Chromium, just to be sure that I'm not missing anything, I understand this only applies to Grid Layout. So align-items: normal would be start or stretch depending if it's a replaced or a non-replaced element (just a summary).
However a flexbox with align-items: normal will work as stretch for both replaced and non-replaced elements.
Please let me know if I'm wrong on this assumption. Thanks.

mrego added a commit to mrego/csswg-test that referenced this issue Feb 27, 2017

[css-grid] Add test for Grid Items Sizing
Now that issue w3c/csswg-drafts#523 has been resolved,
I'm adding a new test to verify the default alignment ("normal")
for replaced and non-replaced elements.

mrego added a commit to mrego/csswg-test that referenced this issue Mar 1, 2017

[css-grid] Add test for Grid Items Sizing
Now that issue w3c/csswg-drafts#523 has been resolved,
I'm adding a new test to verify the default alignment ("normal")
for replaced and non-replaced elements.

MXEBot pushed a commit to mirror/chromium that referenced this issue Mar 2, 2017

[css-grid] "normal" alignment is "start" for replaced elements
"normal" alignment used to be "stretch" for all the elements,
however the CSS Grid Layout spec has been updated to change
this behavior for replaced elements:
w3c/csswg-drafts#523

A few tests need to be updated due to this change.
We also take advantage to make
fast/css-grid-layout/grid-align-stretching-replaced-items.html
a testharness.js test so we can get rid of the expected file.

BUG=666961
TEST=external/csswg-test/css-grid-1/grid-items/grid-items-sizing-alignment-001.html

Review-Url: https://codereview.chromium.org/2722613003
Cr-Commit-Position: refs/heads/master@{#454133}

gsnedders pushed a commit to jgraham/css-test-built that referenced this issue Mar 2, 2017

[css-grid] Add test for Grid Items Sizing
Now that issue w3c/csswg-drafts#523 has been resolved,
I'm adding a new test to verify the default alignment ("normal")
for replaced and non-replaced elements.

Build from revision f8dfabbc16a0e061f6ba61d1ad62e8d20e388c43
@FremyCompany

This comment has been minimized.

Contributor

FremyCompany commented Mar 23, 2017

Just a ping to allow people to review issue 1112 and give an opinion there?
(proposal to have flex and grid behave the same wrt defaults)

@fantasai

This comment has been minimized.

Contributor

fantasai commented Mar 23, 2017

Wrt conclusion stated in #523 (comment) ... here are the minutes.

The key excerpt is that three solutions were considered for handling replaced elements:

  1. Make default sizing intrinsic (could opt into contain with width/height keywords)
  2. Make default sizing contain (could opt into intrinsic with width/height keywords)
  3. Add sizing options to alignment (Mats's proposal in #523 (comment) )

The problem with option 3 is, as described in #523 (comment) , that what should be an alignment control devolves into a sizing control, which is objectionable.

This left two options: 1 & 2. Both allow for all of the relevant behavior to be specified, they just differ on the default. Several arguments tilted in favor of option 1:

  • François argued (during the break) that upscaling images isn't great, and it's likely people will want to place smaller images into grid areas and use alignment to control their placement.
  • There isn't a clear spec yet for how contain sizing would work. (Such a spec would have to consider not just the size of the grid area, but also the impact of min/max/specified sizing properties, so it's not hard but requires some thought.)
  • This default would be consistent with block layout, which is familiar to authors.
  • This default would be an easy place to start for common modifications like
    • simple alignment (via alignment keywords)
    • constraining the size (while preserving aspect ratio) via max-size: 100%
    • stretching to fit via stretch (and potentially using object-fit to preserve ratio)
    • fitting into the grid area contain-style via future keyword, as Mats has requested here

The WG therefore resolved on option 1, and actioned me and Tab to draft up a spec for contain as a keyword to width and height.

@MatsPalmgren Sorry for taking so long to post a proper summary. Please let us know what you think, and if this is acceptable to you. For my part, I am OK with either 1 or 2, but I would have to object to 3.

@MatsPalmgren

This comment has been minimized.

MatsPalmgren commented Apr 19, 2017

I still think image grid items should grow (or shrink) to fill their grid area while preserving their intrinsic ratio by default. I think width/height:contain is a fine feature to have, but it's sub-optimal since authors have to opt-in to what should be the default behavior, and it will also take a while before all UAs have implemented it. (I've already explained in a previous comment why max-size:100% and object-fit are bad solutions so I won't repeat that here.)

François argued (during the break) that upscaling images isn't great, and it's likely people will want to place smaller images into grid areas and use alignment to control their placement.

Opting out from that can be done by specifying width/height:min-content, no?

If option 2 makes image grid items grow/shrink to fill their grid area in a "contain sizing" way by default, that's certainly acceptable to me. I'd be interested to review a more fleshed out proposal though... in particular how it interacts with align/justify-self:stretch.

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented May 10, 2017

The CSS Working Group just discussed Stretching image grid items in both dimensions.

The full IRC log of that discussion <dael> Topic: Stretching image grid items in both dimensions
<dael> Github Topic: https://github.com//issues/523#issuecomment-295075752
<dael> Rossen: I don't see fantasai yet.
<zcorpan> Github Topic: https://github.com//issues/523
<dael> Rossen: Anyone from Mozilla want to handle this? Or do we move on? Current tag is customer not satisfied.
<dael> TabAtkins: We should wait on fantasai because she might have more to the topic to explore.
@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented May 10, 2017

The CSS Working Group just discussed Stretching image grid items in both dimensions, and agreed to the following resolutions:

  • RESOLVED: ticking with Seattle resolution: making the default instrinsic
The full IRC log of that discussion <dael> Topic: Stretching image grid items in both dimensions
<TabAtkins> Yeah, I think that's probably the best error, zcorpan
<dael> Github topic: https://github.com//issues/523
<dael> fantasai: In seattle we had three options. One we wouldn't take b/c violates design guidelines. Other two we would have contain & intrinsic size behavior. You could opt into either. We picked intrinsic for the default. There's details in https://github.com//issues/523#issuecomment-295075752
<dael> fantasai: We closed that, but Mats disagrees with the resolution. All other issues on Grid are closed as of when we stopped accepting issues.
<dael> fantasai: This issue has a commentor disagreement so comes back to WG. Do we stick or do we change to contain sizing by default and opt-in for intrinsic via keyword-max-content or something like that.
<dael> Rossen: Opinions?
<dael> jensimmons: My opinion is I agree #3 should not be considered. I'd be okay with leave as-is, but I agree with Mats that as an author having the default be contain would be more handy and make more sense. We need both as an option and the tool to switch definitely. The default I'd lean contain.
<dael> TabAtkins: Reason why we didn't go for contain is it puts sizing control in this prop...
<dael> fantasai: TabAtkins we changed.
<dael> jensimmons: That was 3 which we agreed not to do
<dael> fantasai: Option was default is contian on all keywords, not jsut normal.
<tantek> do we have comments from anyone else who is actually implementing this besides Mats?
<tantek> reviews the issue
<dael> jensimmons: Ideally we would have tool to switch between, but the wayt he world works if we set default to contain we would get the switching tools quicker. Not certainly, but might.
<rachelandrew> I'm still keen on the resolution
<dael> Rossen: But forcing a less then optimal default as a forcing tool i sn't doing much good.
<tantek> long issue is long
<dael> jensimmons: Agreed. I still like contain as a default. That's a secondary non-heavy
<dael> TabAtkins: I'm concerned that when we have contain sizing....having different defaults based on layout of parent it makes the design confusing. It's better if we have consistancy.
<dael> jensimmons: [missed]
<Rossen> +1 to what Tab said
<dael> fantasai: Flexbox resizes to fit hte container. It does only do that with a single line. If you have wrapping it takes intrinisic
<dael> TabAtkins: It obeys constraint of flexbox and a bit of aspect ratio magic. The sizing is normal flexbox, not just images.
<dael> jensimmons: You can make the same arguments here.
<dael> TabAtkins: I disagree. Part of flex is doing this one thing. We're not adding a different way of sizing.
<dael> jensimmons: I think from author prospective there would be something similar to having default of flexbox where they are both text and image contained. If there's an image just left with intrinisic size it starts to overflow and that's not typically what authors want. Authors expect content to stay in grid cells.
<tantek> "won't spill outside" e.g. the [CSS is Awe]some problem
<dael> fantasai: Things that are smaller then grid size, contain will cause them to size up.
<dael> rachelandrew: I don't like the upscalling. I like the original resolution b/c i t's the most consistant and easier to explain. the upscalling will cause problems.
<tantek> didn't follow Rachel's comment
<gregwhitworth> +1 to TabAtkins rachelandrew
<dael> fantasai: Another thing to consider is grid is being deployed and we don't have a definition of contains that WG approved. Changing will c ause impl stress.
<dael> TabAtkins: Adding that, even if we had a contain definition, it's still transition stress because it's shipped without this. They're getting things to look well and then this change will break pages.
<dael> fantasai: I would say if it was significantly better thing to do it might be worth doing, but since we're debating and there's good for both sides, given the status we're at it makes sense to go with intrinsic a nd add the contain keyword. That would be my position.
<dael> TabAtkins: I agree.
<rachelandrew> +1 to fantasai
<dael> fantasai: I'm sympathetic, but it's not so clearly better that it's definitely the right answer.
<dael> TabAtkins: I would also threat it differently if it was obvious fix instead of possibly better.
<dael> Rossen: I'm seeing people favor option 1. Let's try for resolution.
<dael> Rossen: Unless jensimmons you feel there's something else you want to add.
<dael> jensimmons: I don't want to block it, but I think we need to define contain.
<dael> fantasai: We have a definition, we need comments. THere is a definition in sizing 4. Mostly waiting for dbaron and Mats there.
<dael> jensimmons: We should keep going forward on getting that done b/c it's desperately needed.
<dael> dbaron: Does option 1 match what impl ship today?
<dael> Rossen: I believe so.
<dael> tantek: It does.
<dael> s/tantek/ TabAtkins
<dael> jensimmons: I'm curious about that. I'm not sure what Mats impl and he did Gecko.
<dael> TabAtkins: I'd hope he's not impl something different. Even if he is, the other browsers aren't.
<dael> dbaron: I would disagree with TabAtkins' hope. But I don't know what he did.
<tantek> this issue feels like it has many aspects, are there at least some aspects we can converge on?
<dael> Rossen: Let's go back to this. Sincec Mats' isn't here I'd liket o call for consensus on #1. We'll continue working on contain.
<tantek> I'm having trouble keeping track of n resolutions over the past on this and n options
<dael> Rossen: Obj to sticking with Seattle resolution: making the default instrinsic?
<fantasai> testcase -
<jensimmons> we don’t have interop on https://jsfiddle.net/1fd948nz/1/ at the moment, fyi
<dael> RESOLVED: ticking with Seattle resolution: making the default instrinsic
@atanassov

This comment has been minimized.

Collaborator

atanassov commented May 10, 2017

Test case for the above discussion added by fantasai:
https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5143

@fantasai

This comment has been minimized.

Contributor

fantasai commented Dec 4, 2017

Was just tech-editing someone's introduction to Grid Layout and noticed her description of the default alignment behavior for grid: it's stretching unless there's a specified size, in which case it's start. Having replaced elements behave as start by default matches this -- technically they don't have a “specified” size, but the intrinsic size stands in for that specified size, yielding consistent behavior for items that have a concrete size. I think this behavior makes sense and is understandable for authors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment