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

Re: [css-flexbox] Renaming flex-basis:auto for less confusion

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 11 Aug 2014 16:13:56 -0700
Message-ID: <CAAWBYDBy2n5P4dJFiqec46MWr2y4oLMVTQ3Be11A5S3yUMpR7Q@mail.gmail.com>
To: Daniel Holbert <dholbert@mozilla.com>
Cc: www-style list <www-style@w3.org>
On Mon, Aug 11, 2014 at 9:32 AM, Daniel Holbert <dholbert@mozilla.com> wrote:
> On 07/01/2014 09:01 AM, Tab Atkins Jr. wrote:
>> Minutes link: <http://lists.w3.org/Archives/Public/www-style/2014Jun/0107.html>
>> fantasai and I were to propose a new keyword for the "use
>> width/height" behavior, leaving ''auto'' to mean a flex-basis of auto.
>> To avoid breaking content, the 'flex: auto' shorthand declaration
>> would continue to mean what it does, expanding to 'flex: 1 1
>> main-size', and we're relying on the assumption that hardly anybody is
>> explicitly specifying the longhand 'flex-basis: auto' and relying on
>> it to pull in a non-auto width/height value.
>> We suggest ''main-size'' for the new keyword.
> [...]
>> This is also provisional based on whether there's too much
>> "flex-basis:auto" code in the world that's paired with a non-auto
>> 'width' value.
> Heads-up: I've implemented this "auto" --> "main-size" renaming in
> Firefox Nightly[1] builds since Friday, but it appears to break the
> sizing of the Google searchbar[2] at the top of various Google
> properties (Google search-results pages, gmail, calendar, news, etc).
> All of these pages have the following declarations for their searchbar,
> via ".gb_rb" selectors:
>     width: 650px;
>     flex:  0 2 auto
> So, this is an instance of "flex-basis:auto" code in the world, paired
> with a non-auto "width" value.  (The thing we were worried about when
> making this spec-change, quoted above.)
> There are other similar styles on the same pages, too -- e.g. the
> element with class "gbqff" is styled with:
>    width:100%;
>    flex: 1 1 auto
> ...though it doesn't look like that one ends up impacting the actual
> page rendering, possibly because the container is sized based on the
> child's auto-width, so that "100%" and "auto" end up being equivalent.
> Or something like that.
> Anyway -- we've contacted Google about this issue and I'm hopeful that
> they'll take action reasonably soon (adding a "main-size" version of the
> above-quoted "flex" decls).  But this might portend badly for this spec
> change being web-compatible.
> (Fortunately, I haven't heard of any other content that's been broken by
> this change, though it's only been a few days.)
> ~Daniel
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1032922
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1051511

I've reported this internally, so hopefully we'll get this changed soon.

Received on Monday, 11 August 2014 23:14:44 UTC

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