W3C home > Mailing lists > Public > www-style@w3.org > September 2015

[CSSWG] Minutes Paris F2F 2015-08-25 Part II: Flexbox, Grid/Flex Percentages, Testing [css-flexbox] [css-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 4 Sep 2015 17:22:23 -0400
Message-ID: <CADhPm3vfj66dgSi6tzLLPz-9-RR50UgHFK=huh=JR3QBQyqFeg@mail.gmail.com>
To: www-style@w3.org

  - RESOLVED: Don't include flex-basis in intrinsic size calculations
              because that most closely matches existing behavior
  - Issue #3 (Can percentages resolve given min-size: auto?) will be
      resolved by getting a few implementors to talk together and
      determine which solution they're converging toward.
  - RESOLVED: Just blockify the children of flex and grid containers.
              Don't do anonymous box fix-up. (issue #6)

Grid/Flex Percentages

  - The group tried to work through how vertical percentage margins
      and paddings are defined.
      - Note: Top and bottom margins in CSS have traditionally
          resolved against the containing block width instead of its
          height, which has some useful effects but is generally
          surprising. Existing layout modes must of course continue
          to do so.
      - Previous group resolution had been for option 2 (below), but
          Google felt they had new information regarding abspos
          behavior that merited reconsideration.
      - The discussion came down to three potential solutions:
          - Option 1: Always resolve percents against the width.
          - Option 2: Grid and flex resolve against height, and
                      abspos items always resolve against the width.
          - Option 3: Grid and flex, including their abspos items,
                      resolve against the height. Abspos elsewhere
                      continue to resolve against the width.
      - In a straw poll the group was pretty evenly divided between
          options 1 and 3.
      - Microsoft would object to option 1 and Google to option 3,
          so the discussion reached an impasse and will be continued
          privately during the F2F in hopes of reaching a conclusion.


  - RESOLVED: Down-level tests (e.g. CSS2.1 color tests) should be
              updated to not fail on higher-level implementations
              (e.g. CSS4 color implementations), but should also
              leave the old pass conditions intact so that down-
              level clients can still pass the tests for the older
  - It was noted that CSS reftests have a "match at least one of
    these references" feature, so this can be accommodated by
    linking two correct-rendering references instead of just one.

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

scribe: dael


  fantasai: Let me pull up the DoC
  <fantasai> https://drafts.csswg.org/css-flexbox/issues-lc-20150514
  fantasai: Okay. It's a long issues list since I updated it.
  fantasai: We've got a couple of open issues.

Issue #2 - Should min/max-content sizes of flex containers include

  fantasai: First one is if min/max-content size of flex containers
            should consider the flex-basis or just work off the max-
  fantasai: I think dholbert was leaning to what the spec currently
            says. So if I have a flex item whose flex-basis is 50px
            and the max content is 10px, when I shrink should it be
            50 or 10?
  TabAtkins: 50.
  fantasai: It's flex-basis so it can shrink or grow.
  fantasai: So if I have a flex container with one item and that
            item has "hi" and I give flex-basis of 10em and I shrink-
            wrap should it be 2em or 10em?

  dbaron: What do existing implementations do?
  dbaron: We've been shipping this for a while.
  gregwhitworth: I think this one we're all over the map.
  gregwhitworth: Flex is just shrink/grow?
  fantasai: Yeah.
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20*%20{%20border%3A%20solid%3B%20}%0A%3C%2Fstyle%3E%0A%3Cdiv%20style%3D%22display%3A%20flex%3B%20float%3A%20left%3B%22%3E%0A%3Cp%20style%3D%22flex%3A%201%201%2050px%22%3Eem%3C%2Fp%3E%3C%2Fdiv%3E
  dbaron: With flexbox it seems like the issues should have test
          cases and results when they come up for discussion. A year
          ago when we made an incompatible change, we had a lot of
          problems and we're not going to do that again.
  Rossen: You're not alone.
  fantasai: This test case (link above) uses max content size.
            That's fine with me.
  RESOLVED: Flex containers don't consider flexible flex-basis for
            min/max-content sizes.

Issue #3 - Can percentages resolve given min-size: auto?

  fantasai: There's an issue on percentages inside flex items with
            min-size: auto which we've discussed. There were 3
            options. 1 was technically impossible. 2nd was make
            percentages not resolvable. 3rd is two pass layout. It
            looks like implementors are converging on two pass with
  fantasai: Tab and I don't have a preference. We'd like implementors
            to get together and decide.
  fantasai: Does anyone else have anything? I plan to get
            gregwhitworth and dholbert and Christian on a call and
            have them figure it out.

  dbaron: I'm a bit concerned about performance characteristics of
          flexbox right now, but that's all.
  fantasai: I have no opinion. It's performance vs author

  ACTION fantasai to get people on a call to make a decision about
         percentages inside flex items with min-size: auto
  <trackbot> Created ACTION-704

Issues #6 - Do flex item determination before anonymous box fixup

  fantasai: Last one, if you have a flex container and you put two
            table cells in it, they won't become flex items
            independently. They'll wrap in an anonymous table and
            that will be flex.
  fantasai: However, Chrome had implemented it so that each item is
            independently a flex item.
  dbaron: They do anonymous box after?
  fantasai: Not at all.
  dbaron: So it turns the table cells into blocks.
  fantasai: I've seen at least one presentation at a conference
            where they took advantage of this to create fallback
            behavior for a flex.
  dbaron: But that only works in Chrome.
  fantasai: Yes.
  Rossen: Sounds like a terrible hack.
  fantasai: That indicates to me that there are people taking
            advantage of this and could be a useful behavior. Do we
            want to change the spec to use chrome's behavior?
  Rossen: They are doing fixup, but they're creating 2 anonymous
          tables instead of one according to your code.
  zcorpan: You could get table layout by overriding with the
           new 'display' value in flex implementations.
  fantasai: That won't work because flex-item isn't a value for
  [discussion that resolves in chrome not doing fixup]

  ojan: The conversion we do for position absolute, we're doing it
        for flex.
  dbaron: Some of this is a function of what the order of the fixup
          steps are.
  TabAtkins: The spec has been explicit for a long time about when
             you do fixup. It's not the Chrome behavior.
  ojan: We didn't violate the spec when we implemented that, the
        spec changed. We're open to fixing it. I think this is
        better and simpler; it's better for when we do custom layout.
  fantasai: I don't think there's a strong argument one way or the
            other. Web compat would swing it.
  fantasai: (I had brought up the point that 'people may want to do
            this backwards compat thing' when we discussed it
            originally, but it was dismissed as not useful.)

  <rachelandrew> slide 39 in this deck is an example of
                 display:table as a fallback


  dbaron: So it sounds like we should switch to coercing the block.
  fantasai: I don't know how much it's an issue, but it would be
            safer to switch to they webkit behavior. I can't think
            of a good use case of putting a table in a flex unless
            you're trying to do this fallback. If you're not trying
            to trigger fallback, I don't know why you'd put a bunch
            of table cells in flex and get it wrapped in anonymous
  ojan: It sounds like no one is opposed to changing.

  Rossen: So we'll want to do the same thing for grid.
  fantasai: So proposal is: Don't wrap an anonymous table around
            consecutive flex of a flex container.
  TabAtkins: In the paragraph that specifies the other behavior.

  fantasai: We'll have to dig into what about having a table row.
  ojan: I'll share with you the code Chrome uses. Somewhere the
        coercing behavior needs to be explained.

  <dbaron> https://drafts.csswg.org/css2/visuren.html#dis-pos-flo
  <ojan> Here's what chrome does:
  <ojan> And I believe that's what WebKit does as well.

  TabAtkins: If you have two siblings and one is position: absolute
             it shouldn't be a part of the table.
  dbaron: I think a bunch of the coercing behavior is in that link.
  fantasai: There's an equivalent section in the display spec.
  <fantasai> https://drafts.csswg.org/css-display/#transformations

  plinss: So everyone is okay with making the change.

  RESOLVED: Just blockify the children of flex and grid containers.
            Don't do anonymous box fix-up

  fantasai: There's a couple things where we need to edit. Last
            issue to discuss is the percentage margin stuff.
  TabAtkins: It's a good idea to do now.

Grid/Flex Percentage Resolution (aka Flexbox Issue #7)

  TabAtkins: Soooo....
  TabAtkins: At several previous meetings we've talked about how
             vertical percentage margins and paddings are defined.
             Last meeting I tried to convince people to making it
             resolve against width (as it historically has) instead
             of against height (as has been proposed for flex and
  TabAtkins: One of the stronger arguments that's come out is the
             behavior of an abspos element. Abspos currently uses
             the legacy behavior. But if you have an abspos block
             where the containing block is grid or flexbox, what do
             you do?
  TabAtkins: Currently the only thing an abspos cares about is its
             containing block's size. The only thing it cares about
             is that it's a rectangle and the things that make it a
             containing block.
  TabAtkins: Other than writing mode, abspos are ambivalent about
             the containing block.
  TabAtkins: If we make grid and flex resolve against the height,
             then either abspos are inconsistent with in-flow boxes,
             or their behavior changes based on what ancestor has
             position: relative.
  TabAtkins: Also, no one cares about this so we can keep it simple
             with the old legacy behavior.
  ojan: It's more that Mozilla has a number of bugs where web
        authors ask for legacy behavior.
  TabAtkins: We have no bugs asking for the new behavior.

  tantek: This is really going to hurt the kind of people that
          aren't filing bugs, it's going to hurt new people.
  TabAtkins: The aspect ratio hack is in tutorials.
  tantek: They're not beginners.

  gregwhitworth: I think that people do use percentage margins, not
                 just for the aspect ratio hack.
  ojan: I've asked for the list of sites where people use percentage
        margins not with the aspect ratio hack and I don't have it.
  gregwhitworth: I'll get it to you.
  shane: Is it inside flexbox or outside flexbox?
  gregwhitworth: I don't know.

  Rossen: I wanted to go back to your opening about how abspos is
          supposed to work in a way that's oblivious to the layout
          type of the containing block.
  Rossen: That is almost true, but it's a bit of a simplistic view.
          I would disagree with your statement because, by adding
          flexbox and grid and all their properties, you are taking
          dependency on that layout type. I agree in the ideal case
          abspos it should be simple canvas layout. It's the
          simplest layout.
  Rossen: If that's the only language I have to express my layout,
          then there is a layout type which the only thing it cares
          about is the 2D containing block. With the addition of
          flex and grid, these items are speaking a different
          language. Such as 'by the way when you're setting up this
          rectangle, I want to take up this number of columns.'
          You're starting to take some dependency on context.
  Rossen: At the end of the day you're saying you're still
          pretending to be only in the 2D space. You either have
          abspos which was nothing to do with grid and flex, but
          we're not there. We've made abspos items able to speak in
          terms of grid and flex and we are extending this simple
          layout to be more.
  <tantek> I tend to agree with Rossen's analysis

  TabAtkins: There's nothing in flex that makes abspos care. We have
             static defined, but that's not different. In Grid 2,
             abspos don't care unless they opt in with grid
             properties. Nothing else about abspos changes when you
             make a grid container the containing block. You don't
             have a property that changes to a different type of
  TabAtkins: So grid isn't a great example, flexbox isn't great.
  Rossen: It is because you are allowing properties of grid.
  TabAtkins: We are allowing grid properties to have an additional
             effect--we're not changing the behavior of any other
             properties. If you explicitly want an abspos to live
             in a grid, you can. But we don't make width act
             differently because it's in a grid. The rest of abspos
             works the same.
  TabAtkins: Whatever is used as the positioning block is arbitrary.
             That can change with simple page layout. You attach it
             to whatever positions as you need.
  * fantasai agrees mostly with Tab's analysis -- it's weirdly, and
             unexpectedly, inconsistent

  Rossen: How does aligning work?
  TabAtkins: It just cares about what the containing block is and
             aligns inside.
  Rossen: I don't believe this is what we talked about for flex
          items abspos whose containing isn't flex.
  TabAtkins: Every display mode defines static position.
  ojan: For the static position it's controlled by parent?
  TabAtkins: Yes.
  TabAtkins: Maintaining the property is nice because it means that
             the layout doesn't change because if you change from
             abspos to fixedpos nothing changes. But here it would.
  <tantek> There's no need to change abspos behavior here.

  Florian: If you're thinking in terms of encapsulation, you are
           trying to apply the same style to them that's different
           if you're in grid. That's not great. If you're in two
           types they're different and that's not good.
  TabAtkins: We very particularly made it so that if you're doing a
             flexbox it's similar to a block. They will change
             layout if you switch to abspos in a minor but random

  fantasai: I think the vertical-resolution behavior is more logical
            if we had started that way.
  TabAtkins: I don't necessarily agree. Having the ability to do
             consistent padding is nice too.
  fantasai: This is true.

  iank: I've been running a small script. 2% is using percentage
        margin/padding and they're all aspect ratios for iframes.
  gregwhitworth: I had something two weeks ago. I know there are
                 sites out there. I'm not going to claim the
                 percentage margin hack isn't the most common use,
                 but it's not the only use. I think we've all made
                 our points on this. I stand by it's the more
                 logical case and the reason we switched is it's a
                 more modern layout. I agree it's confusing, but I
                 guess in all honestly, I hear your argument, but I
                 don't think it's that strong.

  fantasai: I think a key point that's different is it also affects
            abspos elements, whether or not it should. If percentage
            resolution for grid items is against height, we can make
            abspos consistent across layout modes by continuing to
            resolve against width--but then an abspos contained by
            a grid won't be consistent with other items in the grid.
  fantasai: Or we can make abspos inconsistent to themselves and vary
            their behavior by containing block.
  dbaron: I would pick option 1
  TabAtkins: Where abspos always uses legacy?
  dbaron: Yes.
  tantek: The other option seems like a strawman.
  fantasai: People were seriously proposing that, though.
  TabAtkins: If they're always legacy your grid items will be having
             different layout if they're an abspos item than an
             in-flow one.
  fantasai: If an abspos item is positioned against the grid should
            it have the same percentage interpretation for margins
            and padding as if it was positioned against any other

  tantek: Rossen, why did you argue the other way?
  Rossen: Consistency in grid. So if you have two items, you want
  fantasai: Abspos can position in relation to grid lines. They
            don't effect the sizing, but they can position as a grid
            item in certain ways.
  tantek: So they're top/left bottom/right aligned.
  Rossen: Yes, plus grid properties.
  fantasai: So abspos positioned to a grid container can have some
            abilities of a grid item which is why Rossen argued they
            should have the same behavior. I think consistency is
            good here, but consistency across abspos is a good thing
  TabAtkins: We have only one self-consistent option.
  <tantek> we don't have any one self-consistent layout across all
           layout methods. e.g. table layout (in particular cells)
           is already very different

  TabAtkins: So you all intimated before there might be legacy grid
             problem with Microsoft using MS grid. Can we fix that
             without infecting standardized CSS?
  fantasai: One thing you could do is have boxes whose containing
            block is a grid container whose display value of MS-grid
            would have the percentage behavior you have, but ones
            with the standard prefix would follow standard rules.
            They would be separate values internally.
  Rossen: We'd prefer to drop the prefix if we can.
  fantasai: But the content out there that depends on this behavior
            depends on the prefix as well.
  TabAtkins: Insofar as people are going to update their content...
             we're well aware people don't update content.
  fantasai: A lot of the content they're depending on isn't web
            content. Those are less likely to be doing anything
            besides what's coded in a Microsoft environment.
  Florian: And it makes no sense to future-proof in that environment.

  fantasai: Anyone else have something to add?
  ojan: I haven't been here for the previous conversations. Has the
        possibility of adding a new property to control this been
  fantasai: Yeah, and we hate that idea.
  Rossen: I had a mock-up.
  gregwhitworth: I'm against it.
  tantek: So add a switch instead of a unit.
  TabAtkins: Unit doesn't let us retrofit old content.
  Rossen: And if you have the unit you have to deal with it
  fantasai: Let's not go there.

  Rossen: The two options on the table are, use top and bottom
          percentage margin and padding as they're specified for
          inline grid and flex and don't do for abspos.
  Rossen: That would be because we want to leave abspos as legacy
  Rossen: 2nd is make all the layout types to be legacy behavior
          including grid and flex items.
  Rossen: 3rd is where we are, everything is following inside of
          grid and flex, they resolve against height even for abspos.
  Rossen: So it's all new, all legacy, or mixed where inline flex
          and grid behave new and abspos behaves legacy.

  tantek: There's a strong argument for Rossen's 3rd option. This is
          the basis of the NY argument. New authors coming to CSS
          are then able to use not just flex and grid from the top
          down and have that consistent treatment, they can also
          reuse abspos elements in a way that is also consistent.
          That almost gives us an opportunity to continue repairing
          that mistake form the past.
  TabAtkins: You're assuming there's a population of authors that
             are fed up with the behavior.
  tantek: That was the minority. It was new authors. Every single
          new author.
  astearns: They're confused by how percentage of top and bottom
            resolve gainst the width.
  TabAtkins: There are a lot of parts of CSS that are confusing.
  Rossen: Which is what we're trying to repair.
  dbaron: One point is block layout has two directions that are
          fundamentally different whereas flex in more neutral.
  fantasai: So is abspos.
  dbaron: Not as much.
  dbaron: It does a bunch of stuff that is biased to top left or
  fantasai: We do lots of stuff that's biased start/start.

  [whiteboarding of options]
  fantasai: We have 3 options.
  fantasai: 1 is keep it all consistent. 2 is make the block inline
            calc as width. 3 is [missed]
  <iank> http://pastebin.com/5MZyq1gc [the whiteboard of the above
  Florian: I was convinced by tantek last time but TabAtkins's
           argument is strong. Neither sounds great to me.

  tantek: I'm talking about B. The method I'm trying to take is from
          the new author perspective. I like less the implementor
          way. We're solving for new authors.
  ojan: I think the new authors are doing the aspect ratio hack.
        They search for how to do it and copy/paste.
  tantek: I disagree on gregwhitworth's data and every time I teach
          CSS this confuses people.
  ojan: It's not 100% the aspect ratio hack, but the vast majority
        is. I'm not saying 100%. There are some sites that don't.

  fantasai: In regards to helping new authors, having 2 different
            behaviors depending on layout mode isn't helping authors
            either. It would be great if we could switch
  tantek: I disagree.
  tantek: New authors don't load the whole world into their head.
  TabAtkins: You have to teach a confusing behavior.
  TabAtkins: Are you trying to claim we can't teach block anymore?
  TabAtkins: Flexbox isn't replacing block.
  zcorpan: You have to learn that behavior.
  TabAtkins: They're not a legacy display type.
  tantek: For percentage margins they are.
  TabAtkins: I don't see why that's a flexbox thing.
  tantek: They're more useful.
  tantek: This author focus is important. You teach them the subset
          of stuff that is useful, not the crap before. We don't
          teach the spacers, we teach them the subset that works and
          is consistent and they can model. We want to cut stuff out
          over time if it's confusing, in terms of what we teach.
  ojan: I would cut percentage margin and padding from the model,
        though I agree with you we should work toward the future
        where we should cut the crap.
  tantek: It does because you either don't teach it or teach the
          piece that just works. Or you end up with the proposal to
  fantasai: I think you end up teaching them how it works on grid
            and flex and then they try and do it elsewhere.
  tantek: And then they realize that old CSS is broken.
  fantasai: It's not broken, it's used.

  dbaron: I guess I feel like we're over designing here. All this
          stuff ends up getting used in ways...we've gotten to the
          point where the major use case for percentage margins is a
          hack. Why are we adding more features that are designed in
          a WG meeting? Maybe we should try and make progress on
          houdini instead. I don't think grid is something we,
          Mozilla, should work on because I don't think flexbox went
  dbaron: I'd rather put in the resources to houdini and I think
          that we'll wait until grid is stable and do it then for
  fantasai: You're off topic.
  dbaron: I think this comes up because of grid, though. We have
          features, but they don't use them for the things we've

  esprehn: Is there more strategy beyond this...for example there's
           vertical-align. There's vertical-align where people go to
           that, but it doesn't do what they think. What things will
           we change the behavior of so that it makes more sense?
  tantek: I think for this there's just a strong reaction to "what,
          this doesn't make sense" meanwhile vertical-align doesn't
          make sense to anyone.
  fantasai: People have expectations of what top-center should do,
            but we can't fix it since its been in the language so
  tantek: If you ID other parts of the platform where you can alter
          in some way or a new property like box-sizing to better
          match...that's good. If 90% think that it should work a
          different way, we've screwed up.
  ojan: This is the notorious problem where you can't center on the
  tantek: I think vertical-align in general is confusing.

  esprehn: As we release do we plan to keep doing this?
  TabAtkins: My answer is no.
  esprehn: Do we switch the box-model...what fix ups do we change to
           meet author expectations?
  tantek: For a new authors it's not a switch.
  TabAtkins: People still use block layout.
  SimonSapin: You talk about legacy things that are wrong like
              blocks as things people don't use anymore?
  <TabAtkins> We're not adding `div { display: flex; }` to our
  tantek: I think that's right, I'd tell authors not to use
          percentage margins and padding because it's broken.
  Florian: So, based on your argument that we shouldn't teach
           authors the broken pieces...I don't think the situation
           where grid items are and aren't abspos behave
           differently, I don't think it makes anyone happy.
  tantek: My initial reaction to making abspos based on context is
          kind of odd. Rossen's argument is as soon as you start
          nesting abspos or putting them in a grid layout you're
          going to be using things that are gird specific.

  TabAtkins: Not necessarily. You'll often treat it as an ordinary
  fantasai: You might have a "New" banner. You want to put it on any
            top of the box, doesn't matter the type.

  fantasai: We have two authors in the room. Rachelandrew?
  rachelandrew: I think, I've done a lot of work with grid. When we
                talk about new authors, they're sitting down and
                learning bootstrap and working out how to do things
                in CSS from that framework. People will have a
                legacy understanding of CSS because those frameworks
                use it.
  rachelandrew: Being able to use a fragment anywhere is important.
                You don't want that position to change through any
                context. You don't want that to be different. It's
                going to take people a very long time to change how
                they have been thinking for years.
  rachelandrew: People's understanding is very much based around
                those frameworks.

  fantasai: leaverou?
  leaverou: I just got here.
  fantasai: So we have percentage top and bottom margins in CSS,
            which are measured against the containing block's width.
  fantasai: There was a proposal to have flex and grid interpret
            these differently--to resolve vertical margins against
            the height.
  fantasai: There was an argument for consistency across CSS or the
            argument about making flex and grid easy.
  fantasai: The new consideration is about abspos items. Abspos items
            follow the same layout rule as blocks--always resolving
            against width. The question is what if your abspos item's
            containing block is a grid container. Is it like a grid
            item or as an abspos everywhere else?
  fantasai: Before we could say there's one consistency break:
            between block/inline/table on one hand and grid/flex on
            the other.
  fantasai: But abspos creates a bridge between the layout modes.
  fantasai: An abspos parented to a block must behave like a block.
            But should it be different when the abspos is parented
            to a grid?
  fantasai: Is abspos internally consistent or consistent to the
            containing block?
  fantasai: Abspos have special properties when they are parented to
            a grid container. So some of the positioning will work
            the same as a grid item, but percentage margin and
            padding will behave differently. Somewhere there will
            have to be a break if we want flex and grid to be
  fantasai: So there could be consistency across all of CSS; or
            there's a break in how abspos behave (depending on its
            containing block's display type); or there's a break
            in how in-flow and out-of-flow grid items behave.
  fantasai: That's what's here on this chart.

                              1        2         3
  * in-flow block/etc.      width    width     width
  * abspos to block/etc.    width    width     width
  * abspos to grid/flex     width    width     height
  * in-flow grid/flex       width    height    height

  leaverou: As long as grid acts differently it will be inconsistent
            no matter what we pick. I do see why there should be an
            exception there.

  tantek: I think everything dbaron said and rachelandrew said was
  tantek: The point about frameworks is very important. New authors
          more and more have been switching toward using frameworks.
          I'm going to include Sass as a framework. I think we
          should ask why is that happening. I would hypothesize that
          part of why is that CSS has gotten too big and complex.
          Also, too many features that are handled in bizarro ways.
  tantek: Authors look at their options for the bizarre CSS rules or
          the framework that just has these simple features, they
          choice is obvious is that they go to the frameworks.
          Everyone needs to ask is do they care about making
          something authors can do directly or do you want to make
          more frameworks?
  tantek: I think that the second option is for houdini. I think we
          should make CSS able to do it's own thing.
  leaverou: I completely agree with tantek. We need to make the
            language easy to use.
  tantek: I am trying to fix that.
  fantasai: You argue for consistency, but you're arguing against
  tantek: You keep reframing this as something different from what
          I'm proposed.

  zcorpan: tantek, which option would a framework use?
  tantek: We don't have a framework author here. They have to build
          on top of whatever randomness we build and figure out what
          is the common use case.
  fantasai: Let's consider that someone is a framework author and
            they're building a grid layout framework. They're basing
            it off flexbox, but they have a lot of fallback
            behaviors. Let's say we release the grid spec and the
            author says they can use grid where it's supported,
            flexbox where it's not, and float layout as the last
  fantasai: If the author puts a percentage margin on their items,
            it will behave one way on flex and grid, but differently
            on floats.
  tantek: I think your example has too many assumptions.
  SteveZ: A framework is to hide the complexity. I don't think from
          a framework author point of view we can answer this.
          They'll figure out how to calculate it for percentages.
  ojan: Except they can't because the author will be specifying that
  tantek: The author will do it, it'll break, and they'll look in
          the framework community for an answer.

  fantasai: Let's do a strawpoll.
  tantek: I object to how you framed the answers.
  fantasai: How would you like this strawpoll framed?
  tantek: They're in the minutes.
  tantek: Rossen proposed how every person was advocating it.
  Rossen: Option 1: Keep everything consistent in terms of
          percentage resolution- that was aligned with your option A.
  Rossen: Option 2: Mixed where abspos items are an exception inside
          grid and flex in terms of percentage margin.
  Rossen: Option 3: Everything we did in grid and flex, including
          abspos is following the new model.
  Rossen: From the PoV of the layout type, not abspos.
  <tantek> Option 1: Keep vertical % margins/padding always
           dependent on horizontal metrics
  <tantek> "consistent" is an oversimplification in option 1
  fantasai: tantek are you happy?
  tantek: I think it's better to make clear that option 1 vertical
          percentage margins/padding always dependent on horizontal
  tantek: I think that's important to call out.
  <astearns> option 1: keep old mistakes everywhere, option 2: keep
             old mistakes in some places, option 3: fix old mistakes
             everywhere we can
  Rossen: One more point for implementors: as soon as you start
          adding logical properties you will find yourself wishing
          you had chosen the symmetry.
  Rossen: Especially for vertical mode in horizontal.
  fantasai: To be clear this chart is the logical width and height.

  * leaverou thinks one weird rule is better than 1 weird rule + a
             bunch of exceptions, so leaning towards option 1
  <tantek> leaverou: it's about do we want to try to keep making CSS
           more usable over time, or do we want to forever shackle
           ourselves with bad decisions of the past?
  <leaverou> tantek: but it's not about making CSS more usable, it's
             making it more internally inconsistent
  <leaverou> tantek: given that we are not going to change the past
  <leaverou> exceptions are hard to teach
  <TabAtkins> The idea that making the language inconsistent in tiny
              ways in successive waves, is "making the language more
              usable", is incorrect.
  <leaverou> TabAtkins++
  <TabAtkins> We should only be inconsistent with legacy when the
              new behavior is actually strongly good.
  <TabAtkins> Like switching to using Promises over callbacks.

  <tantek> leaverou: I disagree, it's about making the set of modern
           CSS more usable
  <tantek> which is a subset of making the platform as a whole more
           usable over time
  <tantek> which requires us to drop / obsolete / or even ignore bad
           things in the past - just don't teach them to authors
  <Ms2ger> Except that authors need to be able to edit existing code
  <leaverou> tantek: it's not universally a bad thing. Having it
             depend on horizontal metrics is useful sometimes for
             e.g. equal spacing between items (horizontally and
  <leaverou> tantek: it's confusing in many cases, sure, but
             exceptions are even more

  <tantek> leaverou: we avoid exceptions by dropping the past broken
  <leaverou> tantek: we are never going to drop the past broken
             thing here Tantek, it would break too many things.
             Unless you think we're gonna drop block altogether
  <tantek> leaverou: we always drop past broken things, like using
           tables+gifs for layout
  <tantek> by "drop" I mean what we teach authors
  <tantek> modern web practices
  <leaverou> tantek: in that case it's dropping a methodology, not
             the tech. The tech is still there to do layout by tables
  <tantek> leaverou: that's the author-centric point of view, that
           we drop things effectively by dropping them from how we
  <tantek> that's basically what frameworks do, they drop all of the
  <leaverou> tantek: so we're gonna stop teaching block?
  <tantek> no, we stop teaching % margins/padding on block
  <leaverou> tantek: people will try them anyway. IF anything, by
             changing something from grid to block and forgetting to
             change the margin
  <leaverou> tantek: but mostly because "they work here, why
             wouldn't they work there?"

  Florian: So what strawpoll do we take?
  fantasai: We do 1, 2, or 3, as stated by Rossen
  <shane> https://usercontent.irccloud-cdn.com/file/xkTN5ySI/IMG_20150825_122812.jpg
  <shane> https://usercontent.irccloud-cdn.com/file/1kuGPaOM/IMG_20150825_122940.jpg
  Bert: I prefer 1
  esprehn:  1
  Rossen: 3
  tantek: 3
  astearns: 3
  fantasai: 1
  jet: 1
  andrey-bloomberg: abstain
  SimonSapin: abstain
  TabAtkins: 1
  Florian: 1
  leaverou: 1
  ChrisL: 1
  zcorpan: 1
  hober: abstain
  weinig: abstain
  dauwhe: 1
  SteveZ: 3
  plinss: abstain
  hyojin: 3
  ojan: 1
  johanneswilm: 1
  gregwhitworth: 3
  matt: 3
  brian: abstain
  iank: 1
  shans: 1
  rachelandrew: 1
  dbaron: 2 or 3

  plinss: Is there anyone voting for 3 that objects to 1?
  tantek: Yes.
  Rossen: Yes.
  plinss: And the reverse?
  TabAtkins: Yes.

  tantek: We did have resolution consensus before.
  TabAtkins: Then we'll object to the current situation.
  fantasai: There's significant new information.
  ojan: The resolution from last time was option 2.
  dbaron: Did the discussion last time distinguish between 2 and 3?
  tantek: No.
  <tantek> The resolution from last time was effectively (2 or 3)
  <tantek> what we found out today is that 3 is a clarification of
           the past resolution
  * leaverou thinks the abspos issue makes it even more weird to
             have an exception there, so it makes sense that the
             consensus has changed

  <tantek> leaverou - I'd like to understand how you'd propose
           making CSS *better* for authors, not just consistent with
           all legacy
  <leaverou> tantek: I don't think you realize how hard exceptions
             make CSS to understand and teach.
  <tantek> leaverou: unfortunately I do realize how painful that is
           and hence want to avoid teaching authors the bad ways of
  <leaverou> tantek: Having one consistent but suboptimal rule is
             better than having that in most cases, but not in grid,
             but wait, it's different if you have abspos etc etc
  <tantek> leaverou: % margins and padding are *already*
           inconsistent with % height
  <tantek> this is trying to fix that
  <leaverou> tantek: yes, but you will have this inconsistency

  plinss: I'm open to suggestions on how to move forward.
  TabAtkins: If I understand, Microsoft's main objection is dealing
             with the legacy content. I'm looking for a solution
             that keeps your content working and lets this move
             forward. If we knock that out, does it remove enough
             objection that you're okay with it?
  Rossen: No.
  TabAtkins: We're at an impasse.

  Rossen: The abspos information doesn't bring anything new because
          we're already doing 3.
  Rossen: But it's a thing we needed to clarify.
  dbaron: I think one reality is that in a lack of consensus we go
          with implementor market share. Does safari match chrome?
  TabAtkins: Yeah.
  gregwhitworth: But they said they'd switch.
  Rossen: Hyatt said he would switch on the telecon.
  TabAtkins: It's easier to not switch.

  TabAtkins: We can make it officially undefined.
  fantasai: Either way we're closing this with a formal objection.
  Florian: Is leaving it undefined and let it converge work?
  tantek: I'd rather have that then an arbitrary top-down decision.
  shane: Is it possible to remove percentage margins from flexbox?
  TabAtkins: Taking out doesn't mean it's not unspecified.
  shane: It means there's no expectation on when it should be
  TabAtkins: We'll have to say percentage margins do not work in
             this context.
  tantek: Or ignored.
  fantasai: You can't ignore because you have to parse in.

  plinss: Earlier we rejected a user switch.
  fantasai: I disagree with switch.
  hober: I think it's a terrible idea.

  Florian: Can we consider the option of leaving it undefined? Let
           the market sort it out.
  SteveZ: But then you don't have interop.
  hober: You eventually do.
  gregwhitworth: With the rest of the CSS2.1 stuff we're dealing
                 with I'd rather not.
  <tantek> block-percentage ?

  gregwhitworth: We're stuck, I'd rather we circle back and talk
                 again later.
  gregwhitworth: I think we should move on to the next item.
  plinss: I agree. We're not getting anywhere.
  TabAtkins: So the spec if currently listing the behavior that
             we're not happy with. We can't push to CR as it is with
             and active objection from a major implementor. I will
             just undefine it if we leave it as it is.
  gregwhitworth: I was suggesting we go sit around a table and talk
                 about this.
  TabAtkins: Assuming nothing comes out of a conversation we
             undefine it.
  plinss: So a timeline?
  gregwhitworth: I was thinking tomorrow.
  TabAtkins: A day or two is fine. I don't want to hold up the spec.
  plinss: Let's do that.

  plinss: Other flexbox issues?
  fantasai: No, we've got some editing to do.


  Topic is old tests that are invalidated by new features
  SimonSapin: We've seen that happen in two cases. One is that for
              hex colors we have tests in 3 or 4 or 8 are not
              supported, but in color 4 they are supported so the
              old tests fail. What should we do about such tests?
  SimonSapin: Should tests be updated if a later version of the spec
              changes behavior?
  ChrisLilley: We usually remove the test or change to point to
               where ever the new spec is.
  SimonSapin: If that's okay for everyone, we should change the
  fantasai: For that test you have two permissible renderings. If
            you're a 2.1 agent you treat it one way, if you're level
            4 you render another way.
  ChrisLilley: I don't think CSS2.1 UA is a concept.
  fantasai: I think there's implementors that aren't caught up and
            they shouldn't be flagged as failing for that reason.

  fantasai: We tested for this case because there was a quirky method
            of parsing hex colors in HTML and we wanted to test for
            that to make sure UAs were rejecting those as invalid.
  fantasai: So this is an important test to make sure people that
            don't support Color Level 4 parse hex values correctly.

  fantasai: For reference tests we can have two references and you
            have to match either one.
  SimonSapin: Okay.
  fantasai: For a given UA they'll only have one reference, but for
            the test suite at w3c we should have two references.
  dbaron: It would be useful to have a resolution to fix old tests
          that fail due to new specs, so that they pass either way

  TabAtkins: Is anyone actioned to update?
  plinss: We have a pull request.
  gregwhitworth: How are the tests attached?
  fantasai: There's metadata that tags to a specific section in the
            spec. You'll have a tag to however many specs you're
  SimonSapin: So each test is in a separate test suite per spec
  <ChrisLilley> @ gregwhitworth
  <gregwhitworth> ChrisLilley: Thanks

  RESOLVED: We want to update old tests but leaving the old pass
            conditions in tact

  SimonSapin: And the other case is that we decide a declaration
              block could accept @rule like @page does. Even if
              there is nosuch @rule defined yet because it makes a
              difference inthe error recording.
  SimonSapin: There's a CSS2.1 test that fails there.
  dbaron: That's a case where we should fix CSS level 2.
  fantasai: That should be backported.
  SimonSapin: I sent an e-mail to the list asking to include an
  Bert: I missed that, but there is something strange about that. It
        allows @keywords inside declarations which is disallowed by
  TabAtkins: It's fine by syntax.
  Bert: We're breaking a promise that's explicit in a spec.
  SimonSapin: It's a declaration that contains @rules.
  Florian: It is a breaking change.
  fantasai: It won't break any implementation.
  SimonSapin: I made that change in Firefox a couple years ago, and
              the only bug report is that this test doesn't pass
  TabAtkins: Like dbaron said we should fix 2.1 to no longer say the
             opposite and then fix the test suite.
  SimonSapin: I wrote an errata and there was a resolution.
  <SimonSapin> Change proposed in
              resolved on in
  plinss: So we just need that reincorporated.
  Bert: I have the text. I'll put in the errata.
  plinss: That takes us to lunch.

  <lunch - return at 2pm>
  <dbaron> <br type="lunch" duration="calc(64*60s)">
Received on Friday, 4 September 2015 21:23:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:23 UTC