- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Mon, 03 Nov 2014 13:45:33 -0800
- To: Rossen Atanassov <Rossen.Atanassov@microsoft.com>, www-style <www-style@w3.org>
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