Daniel Holbert [:dholbert] Assignee
	Description • 9 years ago

Filing this bug on supporting properties related to "display:-webkit-box", as approximately-equivalent aliases for modern CSS flexbox.

(As noted in bug 1208344 comment 6, we can treat -webkit-box-[align|pack] as simple aliases for align-items & justify-content, once we support the 'start' & 'end' values for these properties, which are missing in the flexbox spec but have been added in css-align.  But -webkit-box-orient may require a bit more custom aliasing infrastructure, which I'm tentatively planning to provide in bug 1208344.)

	Daniel Holbert [:dholbert] Assignee
	Comment 1 • 9 years ago

(This bug is about supporting these properties natively in CSS, as opposed to using CSSUnprefixingService.js like we do right now for a whitelist of sites.)

	Jean-Yves Perrier [:teoli]
	Comment 2 • 9 years ago

Daniel, does that mean that, when the work for align-items and justify-content 'start' and 'end' lands, we could make a prominent notice in a MDN page about -webkit-box-align and -webkit-box-pack advising authors to replace these by these both standard properties? 

If so, do you have a bug # for tracking the implementation of the start/end values? (My bugzilla abilities failed me to find this bug)

	Daniel Holbert [:dholbert] Assignee
	Comment 3 • 9 years ago

(Essentially, "no".  Stepping back, we should be encouraging authors to use modern flexbox (and its suite of properties, including align-content/justify-content) instead of, or as fallback for, -webkit-box/-moz-box.  That's already true. But we shouldn't specifically ask authors to swap out only those 2 properties, regardless of "start"/"end" support.  In true webkit-based browsers, -webkit-box-align and -webkit-box-pack *only* have an effect on elements with display:-webkit-box, whereas align-items and justify-content have *no* effect on those elements.  So if authors swapped out *just* those two properties, it'd break their -webkit-box elements in webkit-based browsers.  It'd still work in Firefox, but that's only because our plan is to hackily support -webkit-box-* by mapping them under the hood to approximately-equivalent modern flexbox properties.

Bug 1176782 is where we're adding support for those justify-content/align-content values, though.)

	Jean-Yves Perrier [:teoli]
	Comment 4 • 9 years ago

Thanks! Sounds logical.

	Daniel Holbert [:dholbert] Assignee
	Comment 5 • 9 years ago

(In reply to Daniel Holbert [:dholbert] from comment #0 & #3)
> (As noted in bug 1208344 comment 6, we can treat -webkit-box-[align|pack] as
> simple aliases for align-items & justify-content, once we support the
> 'start' & 'end' values for these properties [...]
> Bug 1176782 is where we're adding support for those [...] values

Bug 1176782 has now landed (on inbound), BTW.

	Daniel Holbert [:dholbert] Assignee
	Comment 6 • 9 years ago

This patch adds support for several prefixed CSS properties associated with -webkit-box, as aliases for modern flexbox properties (and behind the pref "layout.css.prefixes.webkit").

Specifically, this adds the following alias mappings:
  -webkit-box-flex          --> flex-grow
  -webkit-box-ordinal-group --> order
  -webkit-box-align         --> align-items
  -webkit-box-pack          --> justify-content

Notable things *not* covered in this patch:
 - This patch does not add support for "-webkit-box-direction". That'll be a bit trickier, and that's covered in bug 1208344.
 - This patch does not add support for "display: -webkit-box". That'll be in a separate patch here.

	Daniel Holbert [:dholbert] Assignee
	Comment 7 • 9 years ago

This patch just extends some existing C++ code to check for the new pref along with the CSSUnprefixingService pref, and dutifully treat "display:-webkit-box" as "display:flex" in either case.

	Daniel Holbert [:dholbert] Assignee
	Comment 8 • 9 years ago

This patch is just an optimization for the code touched by part 2 -- it makes "-webkit-box" a predefined nsCSSKeyword enum, so we can discover it in our nsCSSKeywords::LookupKeyword call, instead of needing to do a special-case string-comparison.

	Daniel Holbert [:dholbert] Assignee
	Comment 9 • 9 years ago

(Er, the comment-tweak in part 3 really belongs in part 2. I'll make that change locally, but won't bother re-posting to avoid bug-churn.)

	Daniel Holbert [:dholbert] Assignee
	Comment 10 • 9 years ago

(In reply to Daniel Holbert [:dholbert] from comment #6)
>  - This patch does not add support for "-webkit-box-direction". That'll be a
> bit trickier, and that's covered in bug 1208344.

(And of course I meant "-webkit-box-orient" there, not "-webkit-box-direction" [which is something completely different].)

	Daniel Holbert [:dholbert] Assignee
	Comment 11 • 9 years ago

Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=771d1fbfca70

	Pulsebot
	Comment 12 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/e0317d4a7a0d
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b1626ab504f
https://hg.mozilla.org/integration/mozilla-inbound/rev/073a8c4b51ef

	Carsten Book [:Tomcat]
	Comment 13 • 9 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/e0317d4a7a0d
https://hg.mozilla.org/mozilla-central/rev/8b1626ab504f
https://hg.mozilla.org/mozilla-central/rev/073a8c4b51ef

	Daniel Holbert [:dholbert] Assignee
	Comment 14 • 8 years ago

(Taking this off of the dependency list for bug 1170774, since it's already in the dependency tree via bug 1170789.)

	Daniel Holbert [:dholbert] Assignee
	Comment 16 • 8 years ago

Sorry, disregard comment 15; I mis-pasted the bug number into a patch for bug 1257661.

	Sebastian Zartner [:sebo]
	Comment 17 • 8 years ago

Added compatibility notes to the following pages:
https://developer.mozilla.org/en-US/docs/Web/CSS/box-flex
https://developer.mozilla.org/en-US/docs/Web/CSS/box-ordinal-group
https://developer.mozilla.org/en-US/docs/Web/CSS/box-align
https://developer.mozilla.org/en-US/docs/Web/CSS/box-pack

Also, added a description of the -webkit-box value to https://developer.mozilla.org/en-US/docs/Web/CSS/display#Values and listed the changes at https://developer.mozilla.org/en-US/Firefox/Releases/45.

Daniel, another thing to verify for you. Thanks in advance!

Sebastian

	Sebastian Zartner [:sebo]
	Comment 18 • 8 years ago

I just realized that these properties were changed later on in bug 1257688 to map to the -moz prefixed properties.
I need to update them accordingly.

Just to be clear, in Gecko 45 to 47 they mapped to the modern flexbox properties and from 48 on they map to the ones listed above, correct? And if so, should this circumstance actually be reflected in the modern flexbox properties pages?

Sebastian

	Daniel Holbert [:dholbert] Assignee
	Comment 19 • 8 years ago

(In reply to Sebastian Zartner [:sebo] from comment #18)
> Just to be clear, in Gecko 45 to 47 they mapped to the modern flexbox
> properties and from 48 on they map to the ones listed above, correct?

Correct.

> And if
> so, should this circumstance actually be reflected in the modern flexbox
> properties pages?

I don't think there's any compelling reason to document that subtlety.  (The 45-47 behavior is disabled-by-default, so not something anyone should be depending on [not that anyone should depend on these anyway, sigh].  And in practice, the two versions of the behavior basically behave the same.)

Anyway -- I think the language you added is appropriately vague about the details. :) (in the pages linked in comment 17) Looks good to me. Thanks again!

	Sebastian Zartner [:sebo]
	Comment 20 • 8 years ago

Thank you for the feedback!

(In reply to Daniel Holbert [:dholbert] (mostly OOTO until Aug 9th) from comment #19)
> (In reply to Sebastian Zartner [:sebo] from comment #18)
> > And if
> > so, should this circumstance actually be reflected in the modern flexbox
> > properties pages?
> 
> I don't think there's any compelling reason to document that subtlety.  (The
> 45-47 behavior is disabled-by-default, so not something anyone should be
> depending on [not that anyone should depend on these anyway, sigh].  And in
> practice, the two versions of the behavior basically behave the same.)
> 
> Anyway -- I think the language you added is appropriately vague about the
> details. :) (in the pages linked in comment 17) Looks good to me. Thanks
> again!

Ok, so I've updated them to say 48 instead of 45.

Sebastian