1057162 - Tracking bug for web content that's broken by "flex-basis: main-size" rename

Status: RESOLVED INVALID

(Core Graveyard :: Tracking, defect)

Description

[Daniel Holbert [:dholbert]]

I'm filing this bug to track bugs that turn out to be caused by the renaming of "flex-basis: auto" to "flex-basis: main-size" in bug 1032922.

Comment 1

[Daniel Holbert [:dholbert]]

Karl Dubost posted a link (over in bug 1055888 comment 1) that may help to discover possibly-broken content on Github:
> Search about 'flex-basis: auto' in Github
> https://github.com/search?utf8=%E2%9C%93&q=%22flex-basis%3A+auto%22&type=Code&ref=searchresults

And as I noted in bug 1055888 comment 2:
> those are all candidates that *might* be (but aren't
> necessarily) broken by bug 1032922.
> 
> The reason they aren't *necessarily* broken is that "flex-basis:auto" and
> "flex-basis:main-size" may actually produce the same used value (of "auto"),
> if the main-size property's computed value is "auto". 
> 
> In particular, if an element has width:auto; height:auto (the initial
> values), then "flex-basis:main-size" and "flex-basis:auto" are essentially
> equivalent.  (Tab hinted at this in the last sentence of [1].)  And in fact,
> if the author's goal is really "start at the content's auto-width, and then
> flex from there", then flex-basis:auto is arguably the correct way to
> express that.  (And it's even more correct now that they can directly ask
> for "auto", instead of having to rely on flex-basis seeing "auto" and then
> looking over at width to discover "auto" there.)
> 
> So -- we can't necessarily say anything about the brokenness of the CSS in
> [that github link], without doing a bit more digging (to discover whether the
> elements have "width" or "height" set to something non-auto).  That sort of
> thing probably merits its own bug.
> 
> [1] http://lists.w3.org/Archives/Public/www-style/2014Jul/0008.html

Comment 2

[Daniel Holbert [:dholbert]]

I don't think this bug needs its own dev-doc-needed keyword; note that bug 1032922 (which did the renaming described here) already has that keyword.  This bug here is just a tracking bug for site breakage caused by that change.

Comment 3

[Daniel Holbert [:dholbert]]

Update: The CSSWG resolved to revert "flex-basis: main-size" and go with an alternative proposal to achieve the same goals with better backwards-compatibility. I'm removing "main-size" in bug 1093316.

So, there should no longer be site-compat issues here (and the site-compat changes that have been made for this bug may be obsolete, though in some cases (e.g. changing "flex: 0 0 auto" to "flex: none") the modified version will still be valid.)  Hence, resolving as ultimately INVALID.

Since we were the only browser that I'm aware of who implemented "flex-basis: main-size" (and it never made it to a firefox release -- only prerelease versions), I don't anticipate that its removal will cause site compat issues -- just some possibly-crufty extra CSS with "main-size" in it.