W3C home > Mailing lists > Public > www-style@w3.org > December 2014

[CSSWG] Minutes Santa Clara F2F 2014-10-27 Part III: Shrink-to-fit, Sizing

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 17 Dec 2014 20:43:57 -0500
Message-ID: <CADhPm3u9NXt-qts1CpG8Ly1JAshYreGnBfSVOx_gtJPp9KUSjg@mail.gmail.com>
To: www-style@w3.org
Shrink-to-fit
-------------

  - There was no agreement on the best behavior to create
      interoperability for layout.  Everyone seemed to like their
      own approach.
  - Several people were tasked with writing e-mails to the list
      describing their float layout for intrinsic sizes in order to
      try and create an agreement for how the sizing approximation
      works and then spec that.

Sizing
------

  - No one had a perfect solution for how to resolve intrinsic sizes
      of non-replaced blocks when the width isn't definite.
  - Assuming the value is 0 was raised and garnered some interest,
      but there was a desire to ensure that the description is
      correct.
  - The interested parties will work together offline for a solution.

===== FULL MINUTES BELOW ======

  Scribe: dael

Shrink-to-fit
-------------

  plinss: Let's get started.
  glazou: Is fantasai around for sizing?
  dbaron: Can someone text her?
  plinss: Who put this on the wiki?
  TabAtkins: I assume fantasai.
  plinss: Let's skip to inline-box?

  <gregwhitworth> http://jsfiddle.net/xzt063uv/2/
  gregwhitworth: IE does layouts and we want to get interoperability.
                 We want to figure out a way to do it without
                 layout, but we often get live sites that don't
                 render correctly. We'd like some feedback from
                 others who don't want to change their system.

  <dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2006AprJun/0170.html
  dbaron: I managed to dig up last time we discussed this issue.
  dbaron: In the above minutes.
  dbaron: We didn't have a conclusion then.
  dbaron: A bunch of us have made architectural decisions that we
          don't do layout for this. We don't have major
          compatibility issues. It would be nice to have and
          agreement on what the rules are.
  dbaron: Gecko code and webkit/blink code is somewhat different and
          I don't think coming to an agreement between those is hard
          and I think it would be web compatible.
  gregwhitworth: I agree. We have a lot of problems with what we do.
                 I think a lot of people don't test us. We don't
                 want to switch because people layout the same until
                 shrink to fit.
  dbaron: That's not ignoring the spec. It doesn't define behavior.

  gregwhitworth: At the end of the day we just want websites to work.
                 We could say match us, but technically you're right
                 that when you push down isn't defined. As an author
                 I would expect the same layout and shrunk.
  dbaron: There's no laying out.
  gregwhitworth: They literally...if you look at the layouts
                 personally I think they should be the same.
  dbaron: Prior to 2006 or so we did it, but we stopped because it
          had tons of bugs and was slow. We decided webkit was
          surviving with doing what it was doing so that was
          compatible for web content.

  gregwhitworth: Let me track down the thread. I think it was
                 someone from Opera who said Presto is doing it
                 differently.
  florian: I think that was morten on the list.

  gregwhitworth: We don't have huge performance issues. I think most
                 authors would expect our behavior. What's the
                 working group's consensus? I don't want it to
                 stagnate because we have a few bugs.

  SimonSapin: What does it mean to do layouts...it depends on how
              much width is available, but we don't always have that
              information.
  dbaron: In the old days, all the layout code had a mode where you
          could execute that code with a value for available width.
          It would then place everything as if there was no width
          constraint. We would place floats along those lines.
  Rossen: When we run in unconstrained width we really run it
          unconstrained. Obviously you can't resolve percentage
          because they're meaningless.
  SimonSapin: What do you do with percentages?
  Rossen: You can backwards resolve or resolve against a computed
          shrink to fit size.
  dbaron: The what do you do with x, the answers are always what are
          you doing when computing intrinsic widths. They just use
          the layout code to do that instead of separate code.
  Rossen: So there's pretty much no difference in the two codes.

  gregwhitworth: It feels like again we all like our thing. I'm
                 looking for a just deal with it.
  dbaron: The algorithm I wrote was for the approximation stuff.
  dbaron: I would vastly prefer not to go back down the trying to do
          layout path. I think IE is the only major engine doing that

  gregwhitworth: Putting aside interoperability and implementation
                 details, do you not find it odd as an author that
                 the layout is completely different?
  dbaron: It's no different than if the absolute element had the
          same width. The only difference is the width for the
          abspos element. Yes it is a little weird but...
  gregwhitworth: I don't know where else to take this. If everyone
                 else is holding fast.

  Bert: One other thing. I'd like to have for things like tables and
        grid layout, you do layout where the width you want is the
        one that minimizes the height, that gives you most compact
        tables as possible.
  Bert: Maybe there should be a switch somewhere to use a different
        algorithm and then you really search for the smallest way to
        pack the content.
  Bert: Smallest in this case is smallest height
  Rossen: So that's your max content. It's shrink to fit.
  Bert: It's more complex than the basic approximation like two
        floats could fit together. You may have to do the layout
        multiple times. I've seen it done and you get beautiful
        tables. You may need a fast computer if you want it
        interactive.
  Bert: I don't know how it works with animation. I guess you turn
        it off. It's something to keep in mind and it may be a
        future way. For print especially you can get better layouts.

  Rossen: So, dbaron, you mentioned performance as an issue.
  dbaron: A lot of the gains came from how we do invalidation. We
          didn't permanently maintain the layout data so we would
          have to redo layout. I'm guessing you don't have that
          problem?
  Rossen: No.
  Rossen: In our case we have ways of reusing that data when we
          identify that it will be the same result so you only do
          the necessary overrides.

  gregwhitworth: Again, I point to the example where there's room in
                 the container for that stuff to fit. In the test
                 case your constraint is the viewport. It shouldn't
                 be pushed because technically there's room to fit.
  gregwhitworth: I'm leery to say match when it's a different result.
  Rossen: Given the content that's out there, does it make sense to
          have a higher quality of implementation? So the user
          expectation will match regular layout more? Or is this an
          edge case enough so we would go and change how we behave.
  gregwhitworth: I'd say 50/50.
  Rossen: I've seen bugs that argue both. The ones that suck are on
          the outer level of websites that control their layout
          through floats. That's where we have broken layout inside
          shrink to fit layouts.
  Rossen: Hopefully with grid and flexbox they'll move away from
          that practice, but in the meantime we're stuck with broken
          behavior.

  Rossen: One question is, dbaron, is this an idea you guys would
          even entertain, is to do something from approximation or a
          different way to do layout? If it's out of the question
          there's no reason to do this.
  dbaron: I think going back is pretty out of the question. I
          couldn't justify probably at least one person year of
          engineering time when what we have now is web compatible
          and works.

  Rossen: So if this is the case, can we at least spec that?
  dbaron: Spec the way the approximation works? I can do that. At
          one point I think I posted to the list what we do. I'd be
          interested in seeing what webkit does.
  smfr: We do the same as Gecko in this case.
  dbaron: There are some differences. They're subtle, but we
          sometimes get bugs.
  gregwhitworth: So can we action that or...?
  dbaron: I can write up the Gecko behavior.
  gregwhitworth: Anyone willing to write up others?
  TabAtkins: I can try and ping our people that know the details.

  Rossen: So where would we put that?
  gregwhitworth: Sizing?
  Rossen: It could be.
  plinss: Is the current text vague or silent?
  Rossen: It's basically a lot of hand waving.
  Rossen: Okay. I think we're done with that issue.

  ACTION TabAtkins: spec their float layout for intrinsic sizes
  <trackbot> Created ACTION-659
  ACTION dbaron: spec their float layout for intrinsic sizes
  <trackbot> Created ACTION-660

Percentages and Indefinite Sizes
--------------------------------

  TabAtkins: fantasai, did you put sizing on the agenda?
  fantasai: No.
  SimonSapin: I did.

  SimonSapin: In the sizing spec for the intrinsic sizes of
              non-replaced blocks - there are different cases
              depending on if the repeated width is definite or not.
  SimonSapin: If it's not definite...

  dbaron: What does it mean for definite?
  SimonSapin: Fixed length or a percentage that's against
              something definite.
  dbaron: So definite is a length or a percentage that resolves to
          length.
  fantasai: Could be resolving against ICB, but it doesn't have to
            do layout, just drill down.
  florian: Including calc?
  fantasai: If the things being calc are definite.

  SimonSapin: When it's not definite the spec says:
  <SimonSapin> If the computed inline-size of a block-level box is
               min-content, max-content, or a definite size, [...]
               Otherwise, if the computed inline-size of the block
               is fit-content, auto, or fill, its min-content inline-
               size contribution is its min-content inline-size plus
               any inline-axis margin, border, and padding.
  <SimonSapin> http://dev.w3.org/csswg/css-sizing/#block-intrinsic

  dbaron: So you're saying it should say what to do with percentage
          size and padding?
  SimonSapin: Yes.
  dbaron: It should.
  dbaron: I guess different browsers do different things. I believe
          this is a thing where Gecko does it different than other
          browsers.
  SimonSapin: I haven't tested.

  <dbaron> http://dbaron.org/css/intrinsic/#mbp-adjust
  dbaron: I wrote the above when trying to write this up.
  dbaron: I did write a definition that inverted the percentage in
          padding and margin. I believe Gecko does that, but not
          other browsers.
  Rossen: We don't for sure.
  dbaron: Gecko not for width, but padding and margin.
  SimonSapin: For some reason I thought the answer was treat
              percentage as 0.
  Rossen: That's what I do.
  fantasai: Maybe that was just in grid layout.
  Rossen: That would make sense.

  dbaron: The other interesting thing is that it does that for
          preferred width, but treats it as 0 for minimum.
  SimonSapin: Is there a reason?
  dbaron: Web compatibility. The reason for 0 as min content. The
          preferred width is because it works better.
  Rossen: I'd be surprised if webkit's did that. We don't.

  dbaron: The compatibility was the min-width. I guess I'm okay with
          dropping inversion if that's what everyone else does.
  fantasai: If it gives clearly better results, might be worth
            considering.
  dbaron: I'm okay with doing 0. I think everyone else has been
          doing that for a while.

  plinss: Is that specified?
  dbaron: No.
  plinss: So add it to sizing?
  fantasai: I think 0 makes sense if it ends up being 0. If you
            calculate assuming 0 and then calculate percentage
            against that size we have a problem.
  dbaron: And that exists in all the other browsers.
  fantasai: If we're making it 0 or intrinsic size we should make it
            0 for everything.

  gregwhitworth: That's the argument we just made with floats.
  dbaron: The other thing is hopefully people will be using floats
          for layout less over time.
  fantasai: And intrinsic sizing goes into everything.
  fantasai: If you special case floats, it doesn't make sense.
  dbaron: Floats are the only concept in CSS 2.1 that requires you
          to do layout to compute an intrinsic size.
  dbaron: They're the only place where you need height info to
          determine intrinsic widths. What Microsoft wants to do you
          need to know the height of every float to calculate the
          intrinsic width to layout. You're doing layout of lines.
  dbaron: To determine if two floats are next to each other you need
          to know the height of each line. It adds a lot of
          information to be able to calculate without a lot of value.

  fantasai: So if we're assuming 0 for intrinsic size, we should
            assume 0 for layout.
  dbaron: I'd argue that because layout is interoperable.

  Rossen: So you're okay with dropping to 0?
  dbaron: Yeah. I mean, everyone else is doing it.
  fantasai: So your ideal would be the opposite of Microsoft? So
            floats are extra complex, but lets do it for all these
            other things because it makes sense. And Microsoft
            argues the opposite that we want to do this for floats,
            but everything else is 0.
  Rossen: Percentages are funky when you backwards resolve so if you
          have many table cells that are percentage in width,
          backwards resolving most of the time is unreasonable.
  dbaron: Tables do resolve backwards, but only for table layout,
          that's interoperable. But we're not talking about table
          layout right now.

  SimonSapin: I don't know how much of an argument this is, but the
              way Servo does layout, we can't have any results from
              layouts for intrinsic width. We compute them all
              before we start layout for the heights.
  fantasai: I think Servo needs to change its architecture.
  Rossen: I don't think...I can probably come up with grid layout
          scenarios that would have a similar dependency. Rows that
          are fragment dependent. Vertical text is another one.
  Rossen: I'm not sure how we got to that discussion.
  gregwhitworth: Because the resolution is what I was trying to
                 argue so I hijacked it.

  plinss: I'm not sure if I'm hearing consensus.
  dbaron: One other point. The argument for wanting to try and do
          this the right way and invert the percentages is kind of
          weak because it's only web compat in 1/3 of the cases. We
          can look at width padding and margin. For web compat we
          can only do it for margin and padding.
  fantasai: This is block layout?
  dbaron: Yes.
  fantasai: It may be we have to cut our losses for this and do it
            correctly for grid and flexbox.
  plinss: So have a layout mode that authors can opt-into?
  dbaron: I'd be happier about trying to do it the right way in
          layout modes then adding mode switches.
  fantasai: I think that's probably fine. Block layout is really
            about stuff in the flow. Fancy sizing isn't its forte.

  plinss: Will you get prettier answers the other way, for example
          like ebooks?
  fantasai: I definitely want to look into trying to figure it out
            for flexbox and grid.
  dbaron: I'm not sure I'm comfortable changing flexbox that much at
          this point.
  fantasai: They should be consistent.
  dbaron: The last substantiative change to flexbox had a lot of
          problems.
  fantasai: Is that flex-basis? The resolution was "let's change the
            spec to this and get feedback" and then it was suddenly
            implemented.
  fantasai: That was also syntactic, not a layout issue.

  dbaron: So are we leaning toward we want these all 0 for block and
          try to do the inverting for new layout modes?
  fantasai: Makes sense.
  Rossen: I wouldn't change flex at this point.
  dbaron: Then we get to argue about what's new and what's old.
  Rossen: They're both old for us.

  TabAtkins: Given the problems table layouts had when we wanted to
             add new functions, like we can't do min/max. You
             objected on tables. You had to do a piece-wise linear
             function.
  dbaron: We should investigate that, yes.

  plinss: So what's the resolution?
  fantasai: I'd like it if you said "make my box as wide as it need
            to be to not wrap", you get that.
  Rossen: In all cases?
  fantasai: Ideally yes. If we can't because compatibility then we
            have a problem. I think we should honor the request to
            not wrap. And if the internet is dumb and we can't do it
            in some cases, then we can't, but if we can do it we
            should try and do it.

  plinss: So again...do we have a resolution, do we need to
          investigate more?
  fantasai: I don't know. I think we should stick four of us in a
            room with a whiteboard and the sizing spec.
  Bert: What FF does looks better than what Safari does. FF
        currently calculates that if you want everything on one line
        you get everything on one line. It really looks better. I'm
        trying to see about others. Prince puts you on one line but
        makes it bigger than it needs to be.
  Bert: So I'd rather not make it 0.

  plinss: So cage-match tonight with a whiteboard?
  dbaron: Do we have a whiteboard?
  plinss: We can ask.
  <fantasai> The meeting room is non-conformant wrt CSSWG meeting
             room specs...

  <fantasai> ACTION fantasai: Put IE's nearest-scrollable-box
             behavior into orthogonal flows spec
  <trackbot> Created ACTION-661

  plinss: So we'll loop back tomorrow? Folks will work this out
          offline?
  Rossen: Sure.

  SimonSapin: My understanding of intrinsic sizing is that it's
              intrinsic and doesn't depend on the context around it.
  SimonSapin: When we have a writing mode it isn't how intrinsic
              sizing is supposed to work. In particular the
              intrinsic block size.

  Rossen: What we do, basically the obvious pitfall is we say it's
          shrink to fit, assuming you do layout for shrink to fit.
          If you, let's assume you have one long line of text. You
          don't want shrink to fit that's one long line of text.
  Rossen: I believe there's text in writing modes that spec if you
          have no height in the orthogonal switch you cap that to
          the viewport. We do nearest scrollable box of viewport.
  Rossen: We discovered with orthogonal flow, the cases are mostly
          having some kind of webpage where you scroll down and find
          an example of vertical text. The idea is you want to be
          able to see that in your screen. You don't want to have to
          scroll both ways. In our implementation we cap the size of
          the vertical orthogonal content to be the min of your
          nearest scrolling ancestor and your viewport.
  Rossen: With that in mind you can go and compute your min and max
          size. You need to define that. Max size can be the layout
          that you would produce when you cap content at the min.
  Rossen: The min of the content would be the cap size, the viewport
          or nearest scrolling.
  Rossen: That's a fairly good result in almost all practical cases.
          I'm pretty sure you're looking to avoid where you have the
          min and max to be one line height.

  SimonSapin: Should sizing describe all of this whenever it talks
              about min/max block content size?
  Rossen: It's a split between writing modes and sizing. I think
          fantasai and I spoke about this, but I would expect it
          defined in one of the two or both specs.
  SimonSapin: Does it make sense to talk about that for things that
              aren't flows?
  fantasai: There's a couple things. If you set the keywords on the
            height you need some kind of result. There's also if you
            support writing modes it's not just the immediate
            orthogonal flow thing, you have to be able to compute
            the content size.
  SimonSapin: Once you're inside the block direction because the
              length direction.

  SteveZ: It seems to me it isn't totally writing modes. In
          principal you could have something else that changes
          direction like if you do rotating with layout. So it
          should be covered as a change in block direction.
  SimonSapin: How is that different?
  SteveZ: It's basically what you get with tabs on the sides.
  fantasai: We're implementing that in terms of writing modes.
  SteveZ: There's no reason to assume writing mode is the only place
          we'd want to change the block direction. Or we can say it
          is.
  fantasai: That's kind of what we landed on.
  fantasai: Unless we want to do 45 degree rotations.
  SteveZ: I think we should decide if it's with the orientation and
          in that case it goes with writing modes, but there's no
          harm in having a reference.
  fantasai: Oh yeah, there isn't.
  SteveZ: There's other things like a sequence of inline images.
          Like in vertical form it lays out and we have the same
          issue.
  Rossen: We had a similar issue with flex with intrinsic size of
          images in vertical flex versus horizontal flex. It's
          arguably the easiest to deal with it in writing modes and
          deal with just this weird case.

  Rossen: So SimonSapin, was your main point to figure out where
          this should go or what the expected behavior is or is
          there anything else we need to define?
  SimonSapin: If this is the behavior, it should be in the sizing
              spec.
  SimonSapin: I'm worried that this would prevent some layout.
  Rossen: Well, maybe.

  SimonSapin: Do you think we can still do parallel layout with
              this case?
  Rossen: Depends on what you would do and the type of inputs you
          would take.
  Rossen: From pure user standpoint, not having this dependency in
          orthogonal flows doesn't make sense. It's just going to
          produce wrong results, unfortunately.

  plinss: Any more on this?
Received on Thursday, 18 December 2014 01:44:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:27 UTC