W3C home > Mailing lists > Public > www-style@w3.org > February 2017

[CSSWG] Minutes Seattle F2F 2017-01-13 Part I: Grid [css-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 13 Feb 2017 21:32:04 -0500
Message-ID: <CADhPm3trD8MiN9VREaLbaF0WX4L=cvkYgTUB_d4HQFsjTtSppw@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 14 February 2017 02:33:40 UTC