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

[CSSWG] Minutes Telecon 2015-12-16 [css-align] [css-grid] [css-flexbox]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 16 Dec 2015 19:33:45 -0500
Message-ID: <CADhPm3trOENX81iwvTU47jG7ZeR==_pZ0Qmov9Y=gPAyEvRo3Q@mail.gmail.com>
To: www-style@w3.org
Meetings on 23 and 30 December
------------------------------

  - These meetings will not be held on 23 and 30 December unless
      someone requests them on the internal mailing list.

Multiple Changes to CSS Align
-----------------------------

  - RESOLVED: Accept all the changes:
              1) justify-content: auto -> start / stretch (on grid /
                    flex items)
              2) justify-content: stretch -> flex-start (on flex
                    items)
              3) 'left' and 'right' -> 'start' (when operating in
                    the wrong axis)
              4) 'flex-start' and 'flex-end' -> 'start' and 'end'
                    (on non-flex-items)
              5) align/justify-items: auto -> start/stretch
                    (depending on 'display')

Flexbox
-------

  - RESOLVED: Spec that the flex container must wrap around its
              content in all cases, both the min-content and max-
              content case.
  - RESOLVED: Specify the heuristic as the behavior for multi-line
              flex in min-content.
  - RESOLVED: Spec both behaviors, put a note explaining
              implementations are inconsistent, this can't be relied
              on, the WG isn't happy on this and plans to drop one,
              but can't decide which.
  - RESOLVED: Change the spec to say you don't have to fit all the
              flex items on the page, you have to just fit one in
              regards to pagination.
  - RESOLVED: Take Flexbox to CR

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2015Dec/0207.html

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Elika Etemad
  Tony Graham
  Jihye Hong
  Dael Jackson
  Philippe Le Hégaret
  Chris Lilley
  Peter Linss
  Simon Pieters
  Anton Prowse
  Florian Rivoal
  Lea Verou
  Greg Whitworth

Regrets:
  Angelo Cano
  Tantek Çelik
  Simon Fraser
  Daniel Glazman
  Brad Kemper
  Alan Stearns
  Ian Vollick
  Zheng Xu

Scribe: dael

Meetings on 23 and 30 December
==============================

  Rossen: Okay, it's about 5 past the hour. Let's get going.
  Rossen: Any additional topics?
  Florian: I was wondering if we could shuffle the agenda.
  Rossen: No, it's arranged in that way for a purpose. I'm aware of
          the time difference.
  Rossen: Any additional items?

  fantasai: I wanted to include all the open flexbox issues. There's
            only 3.
  Rossen: We have 5 items for flexbox on the agenda. If there's
          additional we'll get through them. But flexbox is #1, then
          grid, then round display.

  Rossen: A quick reminder. There will be a lot of people traveling
          in the next weeks. The current poll shows weak attendance
          where we have 5 people for one meeting and 6 for the next
          one.
  Rossen: As stands we'll cancel those two meetings. If you really
          want to have discussions, e-mail the private list and
          we'll go from there.

Multiple Changes to CSS Align
=============================

  Rossen: [read next few items]
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Sep/0097.html
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Nov/0327.html
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Nov/0280.html
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Dec/0061.html

  fantasai: I think these are all a group. As we discussed last week
            there was concerns about having values compute from one
            to another so we went and made them not compute. So this
            was asking for review and approval of those changes.
  Rossen: We reviewed them on our end. We don't believe we'll have a
          problem with the dependency changing. It would be great to
          hear from dbaron or someone from Mozilla who raised
          concerns.
  Rossen: Do we have anyone from Mozilla?
  dbaron: I'm here. I'm fine with the changes in general, though I
          didn't review the actual edits.
  Rossen: If that's the case, we can proceed with rubber stamping
          all. dbaron if you find issues please raise them. Ideally
          these should be good to go.

  RESOLVED: Accept all the changes:
            1) justify-content: auto -> start / stretch (on grid /
                  flex items)
            2) justify-content: stretch -> flex-start (on flex items)
            3) 'left' and 'right' -> 'start' (when operating in the
                  wrong axis)
            4) 'flex-start' and 'flex-end' -> 'start' and 'end' (on
                  non-flex-items)
            5) align/justify-items: auto -> start/stretch (depending
                  on 'display')

Flexbox
=======

Intrinsic Cross Size Definition Totally Wrong
---------------------------------------------

Heuristic for Shrink to Fit
- - - - - - - - - - - - - -

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Dec/0180.html
  <fantasai> https://drafts.csswg.org/css-flexbox/issues-lc-20150514#issue-12
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3773
  Rossen: I don't see resolution on the list for this so wanted to
          see if we can resolve this.
  Rossen: Do we have anyone from Blink?
  <TabAtkins> I'll be in the call shortly, catching a bus right now.

  fantasai: The first issue is how do you size each column in the
            flexbox and the second is how do you size the flex
            container.
  fantasai: We have interop on the column, it's a kind of heuristic.
            Basically for the minimum size you take the min-content
            size of all the items (you can look at the test case).
  Rossen: Is this min and max in the presence of a cross constraint,
          or with no constraint?
  fantasai: If no constraints are present you have a single column.
            This is one that wraps.
  Rossen: Okay. I wanted to make sure everyone was on the same page.

  fantasai: The min-content size people are doing a heuristic which
            makes sense.
  fantasai: You find the largest min-content for all the items. You
            lay out all the items into that as your column width.
  fantasai: Whatever your results are, you make the column as wide
            as the widest item.
  fantasai: In the example we did a fix for that amount of space. We
            didn't have more, so we have items in the first column
            in the max-content. If I made the min-content thing
            narrower, they might wrap. They won't get smaller than
            the min-content. Once the layout is done we take the
            largest of the sizes in that column.
  fantasai: So is that heuristic what we want to put in the spec? Or
            do we say you can do this or something more accurate? Or
            something else?
  <fantasai> 1. Spec this heuristic
  <fantasai> 2. Spec this heuristic, say you can do better
  <fantasai> 3. Something else
  <fantasai> This is just about sizing the items and the cross-sizes
             of the flex line s(columns)
  <fantasai> Not about flex container sizing around the columns --
             that's 2nd issue

  Rossen: My preference would be to have interoperability for this,
          regardless of what we arrive at. #2 opens the door for a
          lot of non-interop.
  Rossen: If I understand your proposed algorithm, you're saying
          that you're going to base the...are you suggesting we do a
          per column min-size as we go? Or that we assume there's
          one column, find the min in that context and use it for
          all the columns?
  fantasai: Neither, kind of. You're finding the min-content
            assuming everything is in a single column. You're just
            looking at min-content. You go through every single item
            and find the min-content. That's the available size for
            a shrink to fit. You shrink to fit all the items.
  fantasai: If an item is smaller, it won't wrap. If it's wider it
            will wrap. But any item could be smaller than the min or
            up to the min, but not larger.
  fantasai: Once you've laid out you break them into lines. You see
            in a line what is the widest. If it's smaller than the
            min-content it will be smaller or it will be that size.
            Not bigger. So you make it as small as possible.
  Rossen: So I think you're describing the algorithm we've had. Per
          line min-content based on the min-content of the line.
          What I'm trying to say is the difference from the
          multi-col algorithm where we distribute the size to be the
          same which is why we prefer the largest min-content, that
          would leave empty space in other columns.
  fantasai: The difference between this and multi-col is multi-col
            they all have to be the same size. Here if the max-
            content is smaller than the min-content, the column will
            be smaller than the min-content.
  fantasai: If you load the test case that's what you'll see.

  fantasai: So option 1, 2, or 3?
  gregwhitworth: I do prefer IE 11 implementation better. Edge,
                 Chrome, FF we all overflow
  fantasai: That's a separate issue.
  Rossen: That's the flex container.
  fantasai: There's two behaviors of concern. How do you find the
            size of the column and the other is size of flex
            container.

  Rossen: As an implementor I favor #1, but I want to hear from
          Mozilla and Blink.
  fantasai: Mozilla, do you have an opinion?
  dbaron: You'd have to ask dholbert.
  Rossen: And is TabAtkins on?
  fantasai: I don't know if he's on yet.
  <TabAtkins> calling in *right now*
  fantasai: Okay. Let's come back to this with TabAtkins

Size of Flex Container
- - - - - - - - - - -

  fantasai: So the size of the flex container. Once we've found the
            size of the columns, how big is the flex container? We
            don't have interop...or at least no good answer. Firefox
            and Blink size to the size of the largest min-content.
            So more than one column overflows your flex container.
            Which doesn't make sense.
  Rossen: I agree. That's what we did for interop some times during
          Windows 10 development. We did the min-content compromise
          and we have better behavior for the max-content where we
          wrap around the columns. I'll second gregwhitworth and
          favor the behavior where the flex container wraps all
          lines, not the widest. But that would be good to hear from
          other implementors.

  Rossen: Looks like TabAtkins is on.
  TabAtkins: I'm not sure what the behavior is.
  <Rossen> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3773

  fantasai: We're discussing right now the flex container sized
            around all the columns or an arbitrary size.
  TabAtkins: Obviously it's wrap all columns. Christian is against
             it, but Shane is for it.
  fantasai: So the flex container should contain all the columns in
            the spec.
  <dbaron> I'm concerned about speed of intrinsic width computations
           in flexbox, though, and also about having dependencies on
           layout.
  Rossen: So when we do shrink-to-fit we shrink around what we're
          fitting and not overflow by default.
  TabAtkins: The current Blink always overflows with +1 column and
             it's stupid.
  Rossen: That's what we did in min case, but we'd be happy to revert.

  gregwhitworth: Are you guys open to discussing what we do with
                 regular block?
  TabAtkins: It's not the problem, right?
  gregwhitworth: We brought it to TPAc 2 years ago.
  fantasai: That was different. That was a case of content could be
            bigger.
  <fantasai> but wasn't overflowing
  gregwhitworth: I'm happy with flex doing this. It's two sides of
                 the same coin.
  TabAtkins: I have vague memories of the issue, but it's not the
             same.
  Rossen: It's you can have load next to a non-BFC which is related
          to max-size.
  TabAtkins: But it's not directly related to what we're discussing.
             This is you can't float a multi-col flexbox because it
             will have wrong size.

  fantasai: So a flex container must fit all the columns in a shrink
            to fit in it. Objections?
  dbaron: Is this introducing more dependencies on layout?
  TabAtkins: It is. It's either layout dependency or wrong behavior.
  dbaron: I'm unhappy about more layout dependencies. Also, we need
          to stop fiddling with this at some point.
  fantasai: This wasn't specced.
  Rossen: We do want to keep flex same as soon as we can. That's why
          we front loaded these issues. But I'm in favor with
          TabAtkins where we want the same behavior with layout
          primitives. There aren't any presentation systems that
          would default to this weird behavior. We should strive not
          to allow this. I hear you and yes the is a dependency in
          layout, there's no way around it.
  <TabAtkins> <div style="display:flex; flex-flow: column wrap;
              float: left;"> will break *every single time* if you
              have >1 line. Absolutely, unarguably wrong behavior.
  <TabAtkins> (In Chrome's current behavior.)
  <TabAtkins> (Current chrome behavior is that it will overflow the
              float no matter what you do, if you're relying on auto
              sizing.)

  Rossen: Back to the call of objections...and dbaron if you have a
          different option to solve it, I'd like to hear it.
  dbaron: At some point some of the odd combo of features has to be
          use cases we're not concerned about.
  TabAtkins: Yes, but Shane yesterday brought this to me yesterday,
             this exact case. It's easy to run into.
  Rossen: We ran into this in early stages of Windows 8 when we were
          working on flexbox. At the time a lot of the paradigm
          dependencies were on overflow in the horizontal space for
          apps. So dependency on your cross size with the height
          expecting your content would fit into the horizontal
          stretch. Unless you have the same algorithm for wrapping,
          you have odd overflow by default.
  dbaron: So we're proposing to spec something that would change
          behavior for all engines.
  TabAtkins: Edge is correct.
  Rossen: And IE. IE is more correct because we don't have a quirk
          for min-size. We can back out the quirk happily.
  dbaron: I guess I'm okay with it then.

  Rossen: Okay, so the proposed is to spec that the flex container
          must wrap around its content in all cases, both the min
          constraining and no constraint case.
  Rossen: Any objections?

  RESOLVED: Spec that the flex container must wrap around its
            content in all cases, both the min-content and
            max-content case.

Heuristic for Shrink to Fit
- - - - - - - - - - - - - -

  fantasai: Back to the first half of the issue, sizing the columns
            in the box. Should we spec the heuristic which is
            interoperable?
  Rossen: So dbaron defers to dholbert and we wanted to hear from
          TabAtkins.
  TabAtkins: I'm fine with the heuristic.
  Rossen: The proposal is to spec the heuristic without allowing
          other interpretations.
  TabAtkins: I don't know why we'd request better because it's
             insanely expensive.
  Rossen: Can we resolve, wait for dholbert, resolve conditionally
          for dholbert?

  <dbaron> I'm lost on which message we're talking about
  <dbaron> We just resolved on
https://lists.w3.org/Archives/Public/www-style/2015Dec/0055.html ?
  Rossen: We're talking about the algorithm to resolve the min-size
          in a multi-line flex.
  Rossen: dbaron this was the topic where you said you'd defer to
          dholbert.
  dbaron: Still some part of 0055.html?
  fantasai: Yes, there's 2 issues. The first issue is how do you
            size the flex items and the flex columns.
  dbaron: I'm trying to convey these to dholbert. I don't see this
          in 0055.html
  <fantasai> Current browsers perform an approximation of this,
             finding the
  <fantasai> largest intrinsic cross-size among *all* items and then
  <fantasai> shrink-to-fit sizing each flex item into that much
             available space.
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Dec/0180.html
  Rossen: This should have the issue ^
  <TabAtkins> is also confused - he thought we were already done
              with the min-size stuff.
  dbaron: I guess don't worry about me. I won't understand this
          during the call.
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3773
  <fantasai> ^ this test case demonstrates what happens

  Rossen: Let me summarize. The idea is in the case of multi-line
          flex which has a constraint in the cross size, the min
          preferred size is calculated per line. So first we
          calculate the min-size across all the items in the flex.
          That gives you start of a line.
  dbaron: Is this specific to...
  Rossen: To flexbox and differs from multi-col where there we have
          to keep all columns same size. That's why we prefer taking
          the largest and distributing.
  dbaron: So the main issue was for one orientation and not the
          other, in the message. Is this the main size matching the
          block direction?
  Rossen: The issue is only when the cross size has a constraint.
          When you have to have multi-lines..
  dbaron: The main size has a constraint?
  Rossen: Yes.
  Rossen: When the main size is constrained, yes.
  Rossen: In this case the cross size is what is driving the minimum
          content.
  Rossen: So proposed heuristic is we will do a similar algorithm to
          multi-col but instead of leaving them the size of the
          largest, we shrink the ones without the maximum item.
  dbaron: So this is for intrinsic size computation. You're placing
          items into columns to give them different sizes.
  Rossen: Because the column height is constrained. Right.

  <fantasai> TabAtkins, we're discussing how flex items and flex
             lines are sized under a min-content constraint for a
             multi-line column flexbox
  <fantasai> TabAtkins, the question is, should we spec the
             heuristic that is what the impls do
  TabAtkins: Oh! Easier way to talk about this. You've got a height
             set, a column flex box, you have min-content. Figure
             out the largest min-content, assume that width. Layout
             and if they don't use all the space let the line shrink
             to that size.
  dbaron: So which implementation does this match?
  fantasai: All.
  TabAtkins: Everyone does this. It's just not specified.
  TabAtkins: There's a more correct way to do it that requires
             iterative layouts.
  dbaron: Okay. Then I'm okay with it.

  Rossen: Objections?
  Rossen: To specifying the heuristic as the behavior for multi-line
          flex in min-content?

  RESOLVED: Specify the heuristic as the behavior for multi-line
            flex in min-content.

Percent Margin Issue
--------------------

  fantasai: Two more flexbox issues.
  fantasai: First is the percent margin issue. We don't seem to be
            able to get consensus. I asked Ralph, who manages CR
            transition, what do we do and he says spec both and note
            that there is not interoperable or in agreement.
  fantasai: I think we should do that so we can get flex republished.
            So you resolve vertical percentages against whatever
            direction you feel like until we decide.
  Rossen: So we can have text that describes resolving against width
          or height or just say nothing?
  fantasai: We say you can resolve against width or height, but
            nothing else.
  Rossen: We'd be okay with specifying both in the spec.

  fantasai: Is that okay with everyone else?
  <Bert> +1 (if that gets the spec out...)

  dbaron: I'm worried it'll be permanent.
  TabAtkins: It won't get any faster by blocking flexbox spec.
  Rossen: I'd prefer to be as specific as possible, but I'd like to
          get flexbox out the door. After all this time talking back
          and forth and putting out arguments, it sounds like
          there's too many people on both sides. The proposed way
          out sounds sane.
  Rossen: If there's objections to this, please let us know a better
          proposal to get out of this.
  <gregwhitworth> that's the current state yes

  SteveZ: What I'm hearing sounds like you're going to leave the
          state where a user is not sure which context the
          percentage will be implemented in terms of. It seems to me
          over the long run if it persists no one can trust percent
          value. That seems a bad thing to bake in. Didn't we talk
          about adding a parameter allowing you to say which one you
          want?
  TabAtkins: We never agreed on anything. I don't want to block
             flexbox based on us having a solution. We want to get
             out a spec that describes these two options. It's not
             great. no one likes it, but it's better than what's out
             there.
  SteveZ: I don't disagree. I raised the question because if we
          don't decide we think percentages aren't useful.
  fantasai: We should continue working on this.
  TabAtkins: That is a fact. We're making sure they don't get worse
             with a third behavior.
  SteveZ: I think you should put that note in.
  TabAtkins: Yes.

  dbaron: Spec currently says percentage relative to the relevant
          size.
  fantasai: Yes.
  Rossen: That was before Blink re-opened the topic.
  dbaron: Can the spec say there's not consensus without changing
          that that's the current resolution?
  TabAtkins: I think it's more accurate to tell authors 'hey, either
             of these work'.
  TabAtkins: I want a strong note that this is bad and we should fix
             it. But I don't think it serves to pretend that we have
             one behavior with different details when it's two.

  Rossen: So Firefox, IE and Edge implement the spec as written.
          Blink implements the dependency on cross size. Speccing
          both would enable the spec to move forward. But as SteveZ
          points out it leaves the confusion and as dbaron says it
          might bake it in.
  TabAtkins: Specs aren't reality. The describe things...what is
             written is a guide to authors and implementors. Putting
             something in doesn't lock it in any more than not
             putting it does. We're describing reality.
  TabAtkins: If this is resolved next week we'll republish.

  Rossen: I would like to hear from anyone else. This sounds like a
          good way forward. I'm personally biased to the issue and
          don't want to tip the conversation.
  SteveZ: I think documenting what is happening is better than not
          saying anything. And IDing that this is not a good
          situation is good. So I agree with TabAtkins' assessment
          that we ought to document what is and say it's not
          wonderful.
  SteveZ: Rossen, you made the point it should be as specified as
          possible to avoid other interpretations.

  Rossen: And is anyone using this? The answer is pretty much no.
  Rossen: At least in the context of flexbox.
  Rossen: If we leave the spec in this situation, do you think it's
          a good idea to add a note saying what this means to
          authors?
  fantasai: I'm happy to add whatever notes people want to have. I
            want to give to Ralph something he can publish as CR
            without objections.
  <gregwhitworth> agreed, let's get this published :) +1

  Rossen: So do we have objections to the revised spec that will
          spec both behaviors with a note explaining what it means
          to authors?

  <Bert> (Need to mark the options "at risk", otherwise a later
         republication will be a substantive change.)
  Rossen: I don't think this is at risk, Bert
  Bert: I was wondering about what TabAtkins said about when we
        decide what it should be, the easiest to republish is to
        remove an at risk. Otherwise it requires more review.
  fantasai: I think that's fine.
  ChrisL: You don't have to do that anymore. It is possible to
          publish an updated CR if you show you got good review.
  Bert: Needs director approval?
  ChrisL: It doesn't need transition call.
  <ChrisL> the updated CR of css writing modes was done like that

  fantasai: Proposal: spec both behaviors, put a note explaining
           implementations are inconsistent, this can't be relied
           on, the WG isn't happy on this and plans to drop one, but
           can't decide which.
  fantasai: Can we resolve on that?
  Rossen: Objections?
  <ChrisL> +1

  RESOLVED: Spec both behaviors, put a note explaining
            implementations are inconsistent, this can't be relied
            on, the WG isn't happy on this and plans to drop one,
            but can't decide which.

Pagination
----------

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Dec/0163.html
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Dec/0165.html
  fantasai: This issue. There is an error in the Flexbox spec for
            fragmentation. We're causing the flexbox to have a break-
            inside: avoid behavior. I think it's wrong, Florian
            reviewed and agrees it's broken.
  fantasai: The specific rule says [reads].
  fantasai: It needs to say that you don't have to fit all the flex
            items on the page, you have to just fit one.
  Florian: And you can opt back into the current behavior by adding
           break-inside: avoid
  Rossen: How do you guarantee progress?
  fantasai: This is only if flex container is not at top of page.
  Rossen: Okay.
  Rossen: That sounds reasonable.

  Florian: As part of checking the current behavior, I looked at
           different browsers doing flex fragmentation and it's all
           over the place.
  Florian: I have a simple text case in the e-mail reply. If you
           look in different browsers you have different things.
           Firefox doesn't break, Webkit just does the border.
  fantasai: Can we focus on this issue and resolve on it? It's just
            an error.

  Rossen: Objections?

  RESOLVED: Change the spec to say you don't have to fit all the
            flex items on the page, you have to just fit one in
            regards to Pagination.

  Rossen: fantasai make the change and we can re-raise the issue.
  <Florian> Rossen: look at this in different browsers:
            http://output.jsbin.com/hezica/ it's all over the place

CR Publication
--------------

  <fantasai> https://drafts.csswg.org/css-flexbox/issues-lc-20150514
  fantasai: That's the whole DoC. Can we go to CR?
  <gregwhitworth> YES YES YES
  Rossen: Absolutely :)
  Rossen: Objections?

  RESOLVED: Take Flexbox to CR

  Rossen: We have 5 topics still on the list for the call. A few
          grid and round-display. Since we don't have enough
          participation for the next two weeks, those issues will
          need to continue on the ML. Or please start raising your
          hand on the private list and we'll go from there. As
          stands we'll cancel the next two weeks.
  Rossen: Happy holidays, safe travels, and if we don't hear from
          people on the list I'll talk to you in the new year.
  <gregwhitworth> Happy Holidays everyone!!
  <dauwhe> happy holidays!
  <jihye> happy holidays! : )

  <fantasai> Bert, ChrisL: Which one of you wants to handle the CR
             transition ? :)
  <Bert> I can, but I'm back from holiday only on the 11th.

  <Florian> dbaron, could you look into this mail thread
            https://lists.w3.org/Archives/Public/www-style/2015Dec/0096.html
            and particularly this reply I made
            https://lists.w3.org/Archives/Public/www-style/2015Dec/0106.html
  <dbaron> Florian, maybe sometime after 3pm
  <Florian> Thanks, that'd be great. I think we're one reply on the
            ML away from closing what was point 11 on the agenda
            today
  <dbaron> Florian, although I'd note that 'polar-angle: 0' isn't
           valid because the unitless 0 rule is only for lengths
  <dbaron> Florian, although we may well have to change that for Web
           compat if WebKit/blink don't fix it
  <Florian> Noted, I'll be more careful about that in the future.
            That's just a syntax error on my part though, orthogonal
            to the issue being discussed.
  <SimonSapin> unitless zero for angles doesn’t sound too bad
  <SimonSapin> if we manage interop
  <TabAtkins> linear-gradient() used to require distinguishing, but
              not anymore.
  <TabAtkins> But I'm unhappy with how ambiguous 'flex' gets just
              with zero lengths, and I'd prefer not spreading that
              crap further.
Received on Thursday, 17 December 2015 00:34:49 UTC

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