Fwd: Use -webkit-flex instead of -webkit-box (in the Chrome UI and elsewhere)

[Christian Biesinger]

Hi,

I'm currently trying to eliminate all uses of -webkit-box in favor of
the newer, cross-browser and not deprecated -webkit-flex.

I've eliminated the uses inside of WebCore; I'll be working on Chrome
UI code next, although there's a lot of changes to be made there.

So, I would like to ask you to not use -webkit-box in new code.
-webkit-flex works very similar, but does use different CSS property
names. See https://developer.mozilla.org/en-US/docs/CSS/Tutorials/Using_CSS_flexible_boxes
for an introduction or http://dev.w3.org/csswg/css3-flexbox/ for the
spec.

Common changes:
display: -webkit-box -> display: -webkit-flex
-webkit-box-align: start -> -webkit-align-items: flex-start
-webkit-box-align: center -> -webkit-align-items: center
-webkit-box-pack: start -> -webkit-justify-content: flex-start
-webkit-box-pack: center -> -webkit-justify-content: center
-webkit-box-orient: vertical -> -webkit-flex-direction: column

If anyone wants to help with converting the existing code, that'd be
appreciated too!

-christian

[Adam Barth]

Do we have a linter or a presubmit hook that we run over Chrome UI?  If so, we might want it to check for -webkit-box and recommend -webkit-flex instead.

Adam

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

[Daniel Cheng]

Yes, you could probably add a check to PRESUBMIT.py for this.

Daniel

[Dan Beam]

On Fri, Mar 15, 2013 at 2:56 PM, Christian Biesinger <cbies...@chromium.org> wrote:

Hi,

I'm currently trying to eliminate all uses of -webkit-box in favor of
the newer, cross-browser and not deprecated -webkit-flex.

Have you emailed webkit-dev@ about removing it from the platform?  If it's going to be supported indefinitely in the platform I don't why we'd convert existing code... all 776 occurrences [1]

--

Dan Beam

db...@chromium.org

[1]

$ git grep '\-webkit\-box' chrome/browser/resources | wc -l

776

 

I've eliminated the uses inside of WebCore; I'll be working on Chrome
UI code next, although there's a lot of changes to be made there.

So, I would like to ask you to not use -webkit-box in new code.
-webkit-flex works very similar, but does use different CSS property
names. See https://developer.mozilla.org/en-US/docs/CSS/Tutorials/Using_CSS_flexible_boxes
for an introduction or http://dev.w3.org/csswg/css3-flexbox/ for the
spec.

Common changes:
display: -webkit-box -> display: -webkit-flex
-webkit-box-align: start -> -webkit-align-items: flex-start
-webkit-box-align: center -> -webkit-align-items: center
-webkit-box-pack: start -> -webkit-justify-content: flex-start
-webkit-box-pack: center -> -webkit-justify-content: center
-webkit-box-orient: vertical -> -webkit-flex-direction: column

If anyone wants to help with converting the existing code, that'd be
appreciated too!

-christian

--

[Christian Biesinger]

OK, created https://codereview.chromium.org/12837011 to add this to
the presubmit.

-christian

[Christian Biesinger]

On Fri, Mar 15, 2013 at 4:03 PM, Dan Beam <db...@chromium.org> wrote:
> On Fri, Mar 15, 2013 at 2:56 PM, Christian Biesinger
> <cbies...@chromium.org> wrote:
>>
>> I'm currently trying to eliminate all uses of -webkit-box in favor of
>> the newer, cross-browser and not deprecated -webkit-flex.
>
>
> Have you emailed webkit-dev@ about removing it from the platform? If it's
> going to be supported indefinitely in the platform I don't why we'd convert
> existing code... all 776 occurrences [1]

On Fri, Mar 15, 2013 at 4:03 PM, Dan Beam <db...@chromium.org> wrote:
> On Fri, Mar 15, 2013 at 2:56 PM, Christian Biesinger
> <cbies...@chromium.org> wrote:
>>
>> I'm currently trying to eliminate all uses of -webkit-box in favor of
>> the newer, cross-browser and not deprecated -webkit-flex.
>
>
> Have you emailed webkit-dev@ about removing it from the platform? If it's
> going to be supported indefinitely in the platform I don't why we'd convert
> existing code... all 776 occurrences [1]

Well part of the problem is that we can't even measure how popular
this property is right now, because our current feature observer code
would count the chrome UI together with the web. Knowing how popular
this would clearly be a prerequisite for removing it from the
platform.

That said, the flexbox developers (Ojan/Tony) do want to remove the
deprecated flexbox code (i.e. -webkit-box) if possible.

(Your git grep has a few problems, by the way... it will also match
-webkit-box-shadow and -webkit-box-reflect, which are unrelated. It
will match things like -webkit-box-flex which are related, but
arguably should not count as a separate usage. And it misses other
directories which use these properties too.)

-christian

[Dan Beam]

On Fri, Mar 15, 2013 at 4:25 PM, Christian Biesinger <cbies...@chromium.org> wrote:

On Fri, Mar 15, 2013 at 4:03 PM, Dan Beam <db...@chromium.org> wrote:

> On Fri, Mar 15, 2013 at 2:56 PM, Christian Biesinger
> <cbies...@chromium.org> wrote:
>>

>> I'm currently trying to eliminate all uses of -webkit-box in favor of
>> the newer, cross-browser and not deprecated -webkit-flex.
>
>
> Have you emailed webkit-dev@ about removing it from the platform?  If it's
> going to be supported indefinitely in the platform I don't why we'd convert
> existing code... all 776 occurrences [1]

On Fri, Mar 15, 2013 at 4:03 PM, Dan Beam <db...@chromium.org> wrote:

> On Fri, Mar 15, 2013 at 2:56 PM, Christian Biesinger
> <cbies...@chromium.org> wrote:
>>

>> I'm currently trying to eliminate all uses of -webkit-box in favor of
>> the newer, cross-browser and not deprecated -webkit-flex.
>
>
> Have you emailed webkit-dev@ about removing it from the platform?  If it's
> going to be supported indefinitely in the platform I don't why we'd convert
> existing code... all 776 occurrences [1]

Well part of the problem is that we can't even measure how popular
this property is right now, because our current feature observer code
would count the chrome UI together with the web. Knowing how popular
this would clearly be a prerequisite for removing it from the
platform.

That said, the flexbox developers (Ojan/Tony) do want to remove the
deprecated flexbox code (i.e. -webkit-box) if possible.

Unless we're removing it from the platform itself, in my experience (refactoring all of chrome's WebUI CSS) this just adds extra code churn and reviewing effort and causes regressions that are hard to catch automatically (i.e. layout looking different is hard to test).  What are the significant benefits you hope to accomplish from this refactor (of existing code) if this code will always work as is?

(Your git grep has a few problems, by the way... it will also match
-webkit-box-shadow and -webkit-box-reflect, which are unrelated. It
will match things like -webkit-box-flex which are related, but
arguably should not count as a separate usage. And it misses other
directories which use these properties too.)

That's the only directory I'm an OWNER of and your presubmit is checking for -webkit-box-shadow as well.

--
Dan Beam

db...@chromium.org

 

-christian

[Christian Biesinger]

I don't expect this code to always work as-is. But even if it did,
-webkit-box is old, unmaintained code which does have bugs. Better to
switch to code where bugs actually get fixed.

In any case, why the objection to the presubmit? That one only catches new code.

-christian

[Dan Beam]

On Fri, Mar 15, 2013 at 4:49 PM, Christian Biesinger <cbies...@chromium.org> wrote:

I don't expect this code to always work as-is. But even if it did,
-webkit-box is old, unmaintained code which does have bugs. Better to
switch to code where bugs actually get fixed.

One's old is another's stable.  The NTP (and others) adopted -webkit-flex too early and had to fix multiple regressions because of property renames (our fault).  I've been told it wont change much any more.

 

In any case, why the objection to the presubmit? That one only catches new code.

The way we check for new code is not particularly 1) fast (svn diff is slow, especially on Windows), 2) accurate (i.e. change in indent, moving around code).  That said, my main objection is with refactoring existing code.  If -webkit-flex is the supported way forward, then let's check "new" code.

[Ojan Vafai]

On Fri, Mar 15, 2013 at 5:09 PM, Dan Beam <db...@chromium.org> wrote:

On Fri, Mar 15, 2013 at 4:49 PM, Christian Biesinger <cbies...@chromium.org> wrote:

I don't expect this code to always work as-is. But even if it did,
-webkit-box is old, unmaintained code which does have bugs. Better to
switch to code where bugs actually get fixed.

One's old is another's stable.  The NTP (and others) adopted -webkit-flex too early and had to fix multiple regressions because of property renames (our fault).  I've been told it wont change much any more.

With the exception of https://bugs.webkit.org/show_bug.cgi?id=111790, there really shouldn't be any API changes at this point. We'll only be doing bug fixes. At some point, we'll remove the -webkit prefix, but that will be staged with a period where we support both and will not involve any API changes other than the mechanical rename.

In any case, why the objection to the presubmit? That one only catches new code.

The way we check for new code is not particularly 1) fast (svn diff is slow, especially on Windows), 2) accurate (i.e. change in indent, moving around code).  That said, my main objection is with refactoring existing code.  If -webkit-flex is the supported way forward, then let's check "new" code.

Our hope is to remove the old API eventually. Christian is adding a histogram so we can get better data about the usage. Once we have some data, that can inform whether it's worth converting the rest of our uses of the old API. Would be nice to make sure we don't add new uses though. If nothing else, the old API is more buggy and often much slower.

[Andreas Korb]

This thread is one year old now and this isn't even implemented in the latest Chromium version.

What's the current progress? Did I miss anything?

[Christian Biesinger]

What do you mean? display:flex; is supported just fine in latest
Chromium, and has been for a long time.

http://caniuse.com/flexbox

It doesn't need the -webkit- prefix anymore either.

-christian

[Andreas Korb]

I did not talk about the Chromium support. I'm talking about the Chromium settings page which uses 'display: -webkit-box' instead of 'display: flex' till today.

Btw thanks for the fast reply.

[Christian Biesinger]

On Tue, Mar 18, 2014 at 4:16 PM, Andreas Korb <andreas...@gmail.com> wrote:
> I did not talk about the Chromium support. I'm talking about the Chromium
> settings page which uses 'display: -webkit-box' instead of 'display: flex'
> till today.
>
> Btw thanks for the fast reply.

Yeah, true. It turned out that there were technical reasons why that
is hard/impossible to remove :/ Maybe some of those emails did not go
to this thread.

-christian

[Andreas Korb]

Are these technical reasons still valid for current versions?

I would be interested in the problems with the implementation, so far it's no big deal for you to write it down.

[PhistucK]

I guess the code of the settings page relies on quirks and non standard behaviors that only come with display: -webkit-box and not with display: flex.

You can try it by yourself. Replace the values using the Developer Tools feature and see if anything seems wrong.

☆PhistucK

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Stuart Morgan]

On Tue, Mar 18, 2014 at 1:46 PM, Andreas Korb <andreas...@gmail.com> wrote:

Are these technical reasons still valid for current versions?

Yes. Chrome for iOS shares some WebUI pages with the other platforms, which means that unconditionally switching to things that are only available in ToT Blink isn't alway the best option (since it would require forking for iOS and maintaining two copies).

-Stuart

[PhistucK]

Why not use duplicate CSS properties (display: -webkit-box; display: flex;) instead, like normal pages that must maintain cross browser compatibility do? Join the real world. ;)
While it takes (a bit) more space, it makes Chrome not rely on non standard features. Also, when -webkit-box is removed, it will be one less place about which you would have to worry.

☆PhistucK

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Stuart Morgan]

If you have working patches that don't regress any platform and aren't going to be significantly harder to maintain than what is there now, I doubt anyone would object.

-Stuart

[Andreas Korb]

I tried it.

First I didn't see any difference but when shrinking down the browser to smaller size than the box, I see a different behavior.

This and the fact that iOS Chrome version doesn't support it are big stones in the way of the flexboxes.

Is the flex support in the iOS Chrome version planned? 

I like the idea of the fallback method.

[Christian Biesinger]

On Wed, Mar 19, 2014 at 3:12 AM, Andreas Korb <andreas...@gmail.com> wrote:
> I tried it.
> First I didn't see any difference but when shrinking down the browser to
> smaller size than the box, I see a different behavior.

You may need to add a flex property (or other properties?) with the right value?

> This and the fact that iOS Chrome version doesn't support it are big stones
> in the way of the flexboxes.
> Is the flex support in the iOS Chrome version planned?

You'll have to ask Apple...

-christian