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

On 11/03/2014 12:43 PM, Rossen Atanassov wrote:
>> -----Original Message-----
>> From: Daniel Holbert [mailto:dholbert@mozilla.com]
>> Sent: Wednesday, September 24, 2014 2:01 PM
>>
>> FWIW, I've got a metabug to track back-compat issues (broken web content),
>> discovered by this implementation-change in Firefox:
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=1057162
>>
>> So far, I'm only aware of 3 instances of breakage (and all have been fixed
[...]
> Have you seen any further reports.

I've just seen one more report since sending that email -- for a MLB
(baseball) live-game-tracking webapp:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1089039

I haven't reached out to the web devs in that instance, since it was
only reported recently, and this chunk of spec text seems like it might
conceivably change soon.

The "main-size" rename has only made it as far as Firefox's "beta"
release -- it hasn't made it to an official release yet. It's possible
we'd discover more breakage on the release channel.

> Our current crawl data suggests a much higher number of
> instances where this will result in breakage
> (note that this is true for mobile content only).

I don't believe we've gotten reports of mobile-specific issues, but that
may be because we have fewer mobile users on our pre-release channels.

Can you elaborate on the crawl data? (numbers of broken sites, and/or
examples of broken sites)  How does your crawl determine that this
change *will* result in breakage? (Does it account for the fact that
"flex: auto" won't be broken, and also that e.g. explicitly-specified
"flex: 1 1 auto" will still do the same thing it used to, as long as the
main-size-property happens to have the value "auto"?)

> I still believe that we should adopt the second
> proposal of this issue ('auto' / 'content').
> It is safer from back-compat POV as well as
> arguably easier to teach/use.

Personally, I find it easier to reason about what's in the spec
currently. I like the simplicity of having flex-basis reliably treat
values consistently, regardless of whether they're specified directly or
whether they're channeled in from width/height via 'main-size'.

In the original spec-text (before 'main-size' was added), the default
style ("flex-basis:auto; width:auto") felt very broken to me, since
flex-basis's "auto" would pull in the main-size property's "auto", which
then would give us a different flavor of "flex-basis:auto"
(conceptually). (I brought this up at
http://lists.w3.org/Archives/Public/www-style/2012Jun/0029.html -- it
was addressed in the spec by making the width/height-cloning happen in
the used value, not the computed value. But, still weird.)

The second proposal would restore this oddness from the original
spec-text ("auto" being able to pull in "auto"), though it's a bit
better now that we have a non-"auto" keyword that we can use to describe
the sizing behavior when this happens ("content").

> Are you at a point where changing your implementations is not an option?

I believe it's still an option, but probably not for too much longer.
We've been shipping this change in pre-release builds since August 8th;
it's currently scheduled to ship to our release users (with Firefox 34)
in 3 weeks.

I'll file a bug to look into perhaps backing out this change on that
branch, though that might be too risky of a change for that branch at
this point. If it's too risky to back out, and the spec changes to the
second proposal, we'd just have a back-and-forth in terms of the syntax
that we support, which is not-great but doable.

Also: I think someone (fantasai?) said webkit had implemented (or was
implementing) "main-size" as well, though I don't know the details there.

Received on Monday, 3 November 2014 21:46:01 UTC