[webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Tony Chang]

Hi webkit-dev,

I wanted to let you know that Ojan and I plan to add flexbox layout support
to WebCore.  WebCore already supports an older flexbox implementation
(display: box), but the new spec is designed to be easier for developers to
understand and more powerful.  The old flexbox will still remain in WebCore
since none of the CSS properties overlap with the new flexbox spec.  The
spec can be found at: http://www.w3.org/TR/css3-flexbox/ (
http://dev.w3.org/csswg/css3-flexbox/
)

This support will be behind the ENABLE_FLEXBOX feature define (
https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug
tracking the feature's development (
https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to
eventually be enabled by all ports.

I am ready to setup a buildbot for tracking the compile and flexbox related
layout tests.  Should I go ahead and get this added to build.webkit.org's
waterfall?

Thanks,
Tony
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Adam Barth]

Can't we just define ENABLE_FLEXBOX on one or more of the commonly
used ports and use the regular bots?

Adam


On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang  wrote:
> Hi webkit-dev,
> I wanted to let you know that Ojan and I plan to add flexbox layout support
> to WebCore.  WebCore already supports an older flexbox implementation
> (display: box), but the new spec is designed to be easier for developers to
> understand and more powerful.  The old flexbox will still remain in WebCore
> since none of the CSS properties overlap with the new flexbox spec.  The
> spec can be found
> at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/)
> This support will be behind the ENABLE_FLEXBOX feature define
> (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug
> tracking the feature's development
> (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to
> eventually be enabled by all ports.
> I am ready to setup a buildbot for tracking the compile and flexbox related
> layout tests.  Should I go ahead and get this added to build.webkit.org's
> waterfall?
> Thanks,
> Tony
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Ojan Vafai]

I don't think we want to ship this until we have a reasonably feature
complete implementation of the spec and that we're convinced the spec is
stable. I expect that in implementing this we'll find areas of the spec that
need reworking, but at this point it's mainly blocked on implementation
experience.

I'm not sure it's worth setting a bot up just for this, although I'm not
opposed to it. I expect we should have this shippable within a couple
months.

Ojan

On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth  wrote:

> Can't we just define ENABLE_FLEXBOX on one or more of the commonly
> used ports and use the regular bots?
>
> Adam
>
>
> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang  wrote:
> > Hi webkit-dev,
> > I wanted to let you know that Ojan and I plan to add flexbox layout
> support
> > to WebCore.  WebCore already supports an older flexbox implementation
> > (display: box), but the new spec is designed to be easier for developers
> to
> > understand and more powerful.  The old flexbox will still remain in
> WebCore
> > since none of the CSS properties overlap with the new flexbox spec.  The
> > spec can be found
> > at: http://www.w3.org/TR/css3-flexbox/ (
> http://dev.w3.org/csswg/css3-flexbox/)
> > This support will be behind the ENABLE_FLEXBOX feature define
> > (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug
> > tracking the feature's development
> > (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature
> to
> > eventually be enabled by all ports.
> > I am ready to setup a buildbot for tracking the compile and flexbox
> related
> > layout tests.  Should I go ahead and get this added to build.webkit.org
> 's
> > waterfall?
> > Thanks,
> > Tony
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Adam Barth]

New features should be tested incrementally as they are developed.
That means running them on build.webkit.org.  The decision to ship a
feature is separate.

Adam


On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai  wrote:
> I don't think we want to ship this until we have a reasonably feature
> complete implementation of the spec and that we're convinced the spec is
> stable. I expect that in implementing this we'll find areas of the spec that
> need reworking, but at this point it's mainly blocked on implementation
> experience.
> I'm not sure it's worth setting a bot up just for this, although I'm not
> opposed to it. I expect we should have this shippable within a couple
> months.
>
> Ojan
> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth  wrote:
>>
>> Can't we just define ENABLE_FLEXBOX on one or more of the commonly
>> used ports and use the regular bots?
>>
>> Adam
>>
>>
>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang  wrote:
>> > Hi webkit-dev,
>> > I wanted to let you know that Ojan and I plan to add flexbox layout
>> > support
>> > to WebCore.  WebCore already supports an older flexbox implementation
>> > (display: box), but the new spec is designed to be easier for developers
>> > to
>> > understand and more powerful.  The old flexbox will still remain in
>> > WebCore
>> > since none of the CSS properties overlap with the new flexbox spec.  The
>> > spec can be found
>> >
>> > at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/)
>> > This support will be behind the ENABLE_FLEXBOX feature define
>> > (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug
>> > tracking the feature's development
>> > (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature
>> > to
>> > eventually be enabled by all ports.
>> > I am ready to setup a buildbot for tracking the compile and flexbox
>> > related
>> > layout tests.  Should I go ahead and get this added to
>> > build.webkit.org's
>> > waterfall?
>> > Thanks,
>> > Tony
>> >
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>> >
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

Is it possible for this feature to be enabled at runtime?
On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
> New features should be tested incrementally as they are developed.
> That means running them on build.webkit.org. The decision to ship a
> feature is separate.
>
> Adam
>
>
> On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai  wrote:
>> I don't think we want to ship this until we have a reasonably feature
>> complete implementation of the spec and that we're convinced the spec is
>> stable. I expect that in implementing this we'll find areas of the spec
that
>> need reworking, but at this point it's mainly blocked on implementation
>> experience.
>> I'm not sure it's worth setting a bot up just for this, although I'm not
>> opposed to it. I expect we should have this shippable within a couple
>> months.
>>
>> Ojan
>> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth  wrote:
>>>
>>> Can't we just define ENABLE_FLEXBOX on one or more of the commonly
>>> used ports and use the regular bots?
>>>
>>> Adam
>>>
>>>
>>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang  wrote:
>>> > Hi webkit-dev,
>>> > I wanted to let you know that Ojan and I plan to add flexbox layout
>>> > support
>>> > to WebCore.  WebCore already supports an older flexbox implementation
>>> > (display: box), but the new spec is designed to be easier for
developers
>>> > to
>>> > understand and more powerful.  The old flexbox will still remain in
>>> > WebCore
>>> > since none of the CSS properties overlap with the new flexbox spec.
 The
>>> > spec can be found
>>> >
>>> > at: http://www.w3.org/TR/css3-flexbox/ (
http://dev.w3.org/csswg/css3-flexbox/)
>>> > This support will be behind the ENABLE_FLEXBOX feature define
>>> > (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta
bug
>>> > tracking the feature's development
>>> > (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this
feature
>>> > to
>>> > eventually be enabled by all ports.
>>> > I am ready to setup a buildbot for tracking the compile and flexbox
>>> > related
>>> > layout tests.  Should I go ahead and get this added to
>>> > build.webkit.org's
>>> > waterfall?
>>> > Thanks,
>>> > Tony
>>> >
>>> > ___
>>> > webkit-dev mailing list
>>> > webkit-dev@lists.webkit.org
>>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> >
>>> >
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Tony Chang]

Maybe, it would involve disabling CSS parser rules at runtime.  I don't
think we have any code that currently tries to do this.

On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher  wrote:

> Is it possible for this feature to be enabled at runtime?
> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
> > New features should be tested incrementally as they are developed.
> > That means running them on build.webkit.org. The decision to ship a
> > feature is separate.
> >
> > Adam
> >
> >
> > On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai  wrote:
> >> I don't think we want to ship this until we have a reasonably feature
> >> complete implementation of the spec and that we're convinced the spec is
> >> stable. I expect that in implementing this we'll find areas of the spec
> that
> >> need reworking, but at this point it's mainly blocked on implementation
> >> experience.
> >> I'm not sure it's worth setting a bot up just for this, although I'm not
> >> opposed to it. I expect we should have this shippable within a couple
> >> months.
> >>
> >> Ojan
> >> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth  wrote:
> >>>
> >>> Can't we just define ENABLE_FLEXBOX on one or more of the commonly
> >>> used ports and use the regular bots?
> >>>
> >>> Adam
> >>>
> >>>
> >>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang  wrote:
> >>> > Hi webkit-dev,
> >>> > I wanted to let you know that Ojan and I plan to add flexbox layout
> >>> > support
> >>> > to WebCore.  WebCore already supports an older flexbox implementation
> >>> > (display: box), but the new spec is designed to be easier for
> developers
> >>> > to
> >>> > understand and more powerful.  The old flexbox will still remain in
> >>> > WebCore
> >>> > since none of the CSS properties overlap with the new flexbox spec.
>  The
> >>> > spec can be found
> >>> >
> >>> > at: http://www.w3.org/TR/css3-flexbox/ (
> http://dev.w3.org/csswg/css3-flexbox/)
> >>> > This support will be behind the ENABLE_FLEXBOX feature define
> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta
> bug
> >>> > tracking the feature's development
> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this
> feature
> >>> > to
> >>> > eventually be enabled by all ports.
> >>> > I am ready to setup a buildbot for tracking the compile and flexbox
> >>> > related
> >>> > layout tests.  Should I go ahead and get this added to
> >>> > build.webkit.org's
> >>> > waterfall?
> >>> > Thanks,
> >>> > Tony
> >>> >
> >>> > ___
> >>> > webkit-dev mailing list
> >>> > webkit-dev@lists.webkit.org
> >>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>> >
> >>> >
> >>> ___
> >>> webkit-dev mailing list
> >>> webkit-dev@lists.webkit.org
> >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>
> >>
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Ojan Vafai]

Kind of. We could make the functionality only work at runtime, but adding
the properties to the CSS parser would be difficult to make runtime
configurable. So, the CSS properties would parse correctly but do nothing.
That's especially problematic for properties like "display" that would then
get an invalid value.

My current plan was still to test this incrementally. We'd include tests as
we went, but skip the flexbox subdirectory. We would just run the tests
locally during development. This has the downside that other changes might
break the flexbox tests, but thats a pain I'm willing to live with.

I'm fine doing this differently if people have strong opinions.

Ojan

On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher  wrote:

> Is it possible for this feature to be enabled at runtime?
> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
> > New features should be tested incrementally as they are developed.
> > That means running them on build.webkit.org. The decision to ship a
> > feature is separate.
> >
> > Adam
> >
> >
> > On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai  wrote:
> >> I don't think we want to ship this until we have a reasonably feature
> >> complete implementation of the spec and that we're convinced the spec is
> >> stable. I expect that in implementing this we'll find areas of the spec
> that
> >> need reworking, but at this point it's mainly blocked on implementation
> >> experience.
> >> I'm not sure it's worth setting a bot up just for this, although I'm not
> >> opposed to it. I expect we should have this shippable within a couple
> >> months.
> >>
> >> Ojan
> >> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth  wrote:
> >>>
> >>> Can't we just define ENABLE_FLEXBOX on one or more of the commonly
> >>> used ports and use the regular bots?
> >>>
> >>> Adam
> >>>
> >>>
> >>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang  wrote:
> >>> > Hi webkit-dev,
> >>> > I wanted to let you know that Ojan and I plan to add flexbox layout
> >>> > support
> >>> > to WebCore.  WebCore already supports an older flexbox implementation
> >>> > (display: box), but the new spec is designed to be easier for
> developers
> >>> > to
> >>> > understand and more powerful.  The old flexbox will still remain in
> >>> > WebCore
> >>> > since none of the CSS properties overlap with the new flexbox spec.
>  The
> >>> > spec can be found
> >>> >
> >>> > at: http://www.w3.org/TR/css3-flexbox/ (
> http://dev.w3.org/csswg/css3-flexbox/)
> >>> > This support will be behind the ENABLE_FLEXBOX feature define
> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta
> bug
> >>> > tracking the feature's development
> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this
> feature
> >>> > to
> >>> > eventually be enabled by all ports.
> >>> > I am ready to setup a buildbot for tracking the compile and flexbox
> >>> > related
> >>> > layout tests.  Should I go ahead and get this added to
> >>> > build.webkit.org's
> >>> > waterfall?
> >>> > Thanks,
> >>> > Tony
> >>> >
> >>> > ___
> >>> > webkit-dev mailing list
> >>> > webkit-dev@lists.webkit.org
> >>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>> >
> >>> >
> >>> ___
> >>> webkit-dev mailing list
> >>> webkit-dev@lists.webkit.org
> >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>
> >>
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Adam Barth]

It seems like the simplest thing is to have an ENABLE macro that's
turned on and to use the normal bots.  If you're really worried about
folks shipping the feature half-done by accident, you can use a goofy
name like -webkit-goofybox (or whatever) and rename it to the final
name when you're ready.

Adam


On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai  wrote:
> Kind of. We could make the functionality only work at runtime, but adding
> the properties to the CSS parser would be difficult to make runtime
> configurable. So, the CSS properties would parse correctly but do nothing.
> That's especially problematic for properties like "display" that would then
> get an invalid value.
> My current plan was still to test this incrementally. We'd include tests as
> we went, but skip the flexbox subdirectory. We would just run the tests
> locally during development. This has the downside that other changes might
> break the flexbox tests, but thats a pain I'm willing to live with.
> I'm fine doing this differently if people have strong opinions.
> Ojan
>
> On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher  wrote:
>>
>> Is it possible for this feature to be enabled at runtime?
>>
>> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
>> > New features should be tested incrementally as they are developed.
>> > That means running them on build.webkit.org. The decision to ship a
>> > feature is separate.
>> >
>> > Adam
>> >
>> >
>> > On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai  wrote:
>> >> I don't think we want to ship this until we have a reasonably feature
>> >> complete implementation of the spec and that we're convinced the spec
>> >> is
>> >> stable. I expect that in implementing this we'll find areas of the spec
>> >> that
>> >> need reworking, but at this point it's mainly blocked on implementation
>> >> experience.
>> >> I'm not sure it's worth setting a bot up just for this, although I'm
>> >> not
>> >> opposed to it. I expect we should have this shippable within a couple
>> >> months.
>> >>
>> >> Ojan
>> >> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth  wrote:
>> >>>
>> >>> Can't we just define ENABLE_FLEXBOX on one or more of the commonly
>> >>> used ports and use the regular bots?
>> >>>
>> >>> Adam
>> >>>
>> >>>
>> >>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang  wrote:
>> >>> > Hi webkit-dev,
>> >>> > I wanted to let you know that Ojan and I plan to add flexbox layout
>> >>> > support
>> >>> > to WebCore.  WebCore already supports an older flexbox
>> >>> > implementation
>> >>> > (display: box), but the new spec is designed to be easier for
>> >>> > developers
>> >>> > to
>> >>> > understand and more powerful.  The old flexbox will still remain in
>> >>> > WebCore
>> >>> > since none of the CSS properties overlap with the new flexbox spec.
>> >>> >  The
>> >>> > spec can be found
>> >>> >
>> >>> >
>> >>> > at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/)
>> >>> > This support will be behind the ENABLE_FLEXBOX feature define
>> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta
>> >>> > bug
>> >>> > tracking the feature's development
>> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this
>> >>> > feature
>> >>> > to
>> >>> > eventually be enabled by all ports.
>> >>> > I am ready to setup a buildbot for tracking the compile and flexbox
>> >>> > related
>> >>> > layout tests.  Should I go ahead and get this added to
>> >>> > build.webkit.org's
>> >>> > waterfall?
>> >>> > Thanks,
>> >>> > Tony
>> >>> >
>> >>> > ___
>> >>> > webkit-dev mailing list
>> >>> > webkit-dev@lists.webkit.org
>> >>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >>> >
>> >>> >
>> >>> ___
>> >>> webkit-dev mailing list
>> >>> webkit-dev@lists.webkit.org
>> >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >>
>> >>
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Tony Chang]

I don't understand how changing the name prevents the feature from being
shipped half-done.  If we're going to ship a half-done feature, we may as
well use the vendor prefixed name so sites don't depend on the goofy name.

However, I'm willing to run a buildbot for this and that seems better than
shipping a half-done feature.  I don't expect it to be a core builder and
Ojan and I will be the ones keeping it green.  Isn't this what we're doing
for other features like CSS Regions and Exclusions?

On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth  wrote:

> It seems like the simplest thing is to have an ENABLE macro that's
> turned on and to use the normal bots.  If you're really worried about
> folks shipping the feature half-done by accident, you can use a goofy
> name like -webkit-goofybox (or whatever) and rename it to the final
> name when you're ready.
>
> Adam
>
>
> On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai  wrote:
> > Kind of. We could make the functionality only work at runtime, but adding
> > the properties to the CSS parser would be difficult to make runtime
> > configurable. So, the CSS properties would parse correctly but do
> nothing.
> > That's especially problematic for properties like "display" that would
> then
> > get an invalid value.
> > My current plan was still to test this incrementally. We'd include tests
> as
> > we went, but skip the flexbox subdirectory. We would just run the tests
> > locally during development. This has the downside that other changes
> might
> > break the flexbox tests, but thats a pain I'm willing to live with.
> > I'm fine doing this differently if people have strong opinions.
> > Ojan
> >
> > On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher 
> wrote:
> >>
> >> Is it possible for this feature to be enabled at runtime?
> >>
> >> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
> >> > New features should be tested incrementally as they are developed.
> >> > That means running them on build.webkit.org. The decision to ship a
> >> > feature is separate.
> >> >
> >> > Adam
> >> >
> >> >
> >> > On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai 
> wrote:
> >> >> I don't think we want to ship this until we have a reasonably feature
> >> >> complete implementation of the spec and that we're convinced the spec
> >> >> is
> >> >> stable. I expect that in implementing this we'll find areas of the
> spec
> >> >> that
> >> >> need reworking, but at this point it's mainly blocked on
> implementation
> >> >> experience.
> >> >> I'm not sure it's worth setting a bot up just for this, although I'm
> >> >> not
> >> >> opposed to it. I expect we should have this shippable within a couple
> >> >> months.
> >> >>
> >> >> Ojan
> >> >> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth 
> wrote:
> >> >>>
> >> >>> Can't we just define ENABLE_FLEXBOX on one or more of the commonly
> >> >>> used ports and use the regular bots?
> >> >>>
> >> >>> Adam
> >> >>>
> >> >>>
> >> >>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang 
> wrote:
> >> >>> > Hi webkit-dev,
> >> >>> > I wanted to let you know that Ojan and I plan to add flexbox
> layout
> >> >>> > support
> >> >>> > to WebCore.  WebCore already supports an older flexbox
> >> >>> > implementation
> >> >>> > (display: box), but the new spec is designed to be easier for
> >> >>> > developers
> >> >>> > to
> >> >>> > understand and more powerful.  The old flexbox will still remain
> in
> >> >>> > WebCore
> >> >>> > since none of the CSS properties overlap with the new flexbox
> spec.
> >> >>> >  The
> >> >>> > spec can be found
> >> >>> >
> >> >>> >
> >> >>> > at: http://www.w3.org/TR/css3-flexbox/ (
> http://dev.w3.org/csswg/css3-flexbox/)
> >> >>> > This support will be behind the ENABLE_FLEXBOX feature define
> >> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a
> meta
> >> >>> > bug
> >> >>> > tracking the feature's development
> >> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this
> >> >>> > feature
> >> >>> > to
> >> >>> > eventually be enabled by all ports.
> >> >>> > I am ready to setup a buildbot for tracking the compile and
> flexbox
> >> >>> > related
> >> >>> > layout tests.  Should I go ahead and get this added to
> >> >>> > build.webkit.org's
> >> >>> > waterfall?
> >> >>> > Thanks,
> >> >>> > Tony
> >> >>> >
> >> >>> > ___
> >> >>> > webkit-dev mailing list
> >> >>> > webkit-dev@lists.webkit.org
> >> >>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >> >>> >
> >> >>> >
> >> >>> ___
> >> >>> webkit-dev mailing list
> >> >>> webkit-dev@lists.webkit.org
> >> >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >> >>
> >> >>
> >> > ___
> >> > webkit-dev mailing list
> >> > webkit-dev@lists.webkit.org
> >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Adam Barth]

If you're super worried about folks shipping the feature before it's
ready, then that approach can make sense.  I'm not sure how well it
scales, but we can worry about that problem when we have N such
configurations.

Adam


On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang  wrote:
> I don't understand how changing the name prevents the feature from being
> shipped half-done.  If we're going to ship a half-done feature, we may as
> well use the vendor prefixed name so sites don't depend on the goofy name.
>
> However, I'm willing to run a buildbot for this and that seems better than
> shipping a half-done feature.  I don't expect it to be a core builder and
> Ojan and I will be the ones keeping it green.  Isn't this what we're doing
> for other features like CSS Regions and Exclusions?
>
> On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth  wrote:
>>
>> It seems like the simplest thing is to have an ENABLE macro that's
>> turned on and to use the normal bots.  If you're really worried about
>> folks shipping the feature half-done by accident, you can use a goofy
>> name like -webkit-goofybox (or whatever) and rename it to the final
>> name when you're ready.
>>
>> Adam
>>
>>
>> On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai  wrote:
>> > Kind of. We could make the functionality only work at runtime, but
>> > adding
>> > the properties to the CSS parser would be difficult to make runtime
>> > configurable. So, the CSS properties would parse correctly but do
>> > nothing.
>> > That's especially problematic for properties like "display" that would
>> > then
>> > get an invalid value.
>> > My current plan was still to test this incrementally. We'd include tests
>> > as
>> > we went, but skip the flexbox subdirectory. We would just run the tests
>> > locally during development. This has the downside that other changes
>> > might
>> > break the flexbox tests, but thats a pain I'm willing to live with.
>> > I'm fine doing this differently if people have strong opinions.
>> > Ojan
>> >
>> > On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher 
>> > wrote:
>> >>
>> >> Is it possible for this feature to be enabled at runtime?
>> >>
>> >> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
>> >> > New features should be tested incrementally as they are developed.
>> >> > That means running them on build.webkit.org. The decision to ship a
>> >> > feature is separate.
>> >> >
>> >> > Adam
>> >> >
>> >> >
>> >> > On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai 
>> >> > wrote:
>> >> >> I don't think we want to ship this until we have a reasonably
>> >> >> feature
>> >> >> complete implementation of the spec and that we're convinced the
>> >> >> spec
>> >> >> is
>> >> >> stable. I expect that in implementing this we'll find areas of the
>> >> >> spec
>> >> >> that
>> >> >> need reworking, but at this point it's mainly blocked on
>> >> >> implementation
>> >> >> experience.
>> >> >> I'm not sure it's worth setting a bot up just for this, although I'm
>> >> >> not
>> >> >> opposed to it. I expect we should have this shippable within a
>> >> >> couple
>> >> >> months.
>> >> >>
>> >> >> Ojan
>> >> >> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth 
>> >> >> wrote:
>> >> >>>
>> >> >>> Can't we just define ENABLE_FLEXBOX on one or more of the commonly
>> >> >>> used ports and use the regular bots?
>> >> >>>
>> >> >>> Adam
>> >> >>>
>> >> >>>
>> >> >>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang 
>> >> >>> wrote:
>> >> >>> > Hi webkit-dev,
>> >> >>> > I wanted to let you know that Ojan and I plan to add flexbox
>> >> >>> > layout
>> >> >>> > support
>> >> >>> > to WebCore.  WebCore already supports an older flexbox
>> >> >>> > implementation
>> >> >>> > (display: box), but the new spec is designed to be easier for
>> >> >>> > developers
>> >> >>> > to
>> >> >>> > understand and more powerful.  The old flexbox will still remain
>> >> >>> > in
>> >> >>> > WebCore
>> >> >>> > since none of the CSS properties overlap with the new flexbox
>> >> >>> > spec.
>> >> >>> >  The
>> >> >>> > spec can be found
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/)
>> >> >>> > This support will be behind the ENABLE_FLEXBOX feature define
>> >> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a
>> >> >>> > meta
>> >> >>> > bug
>> >> >>> > tracking the feature's development
>> >> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this
>> >> >>> > feature
>> >> >>> > to
>> >> >>> > eventually be enabled by all ports.
>> >> >>> > I am ready to setup a buildbot for tracking the compile and
>> >> >>> > flexbox
>> >> >>> > related
>> >> >>> > layout tests.  Should I go ahead and get this added to
>> >> >>> > build.webkit.org's
>> >> >>> > waterfall?
>> >> >>> > Thanks,
>> >> >>> > Tony
>> >> >>> >
>> >> >>> > ___
>> >> >>> > webkit-dev mailing list
>> >> >>> > webkit-dev@lists.webkit.org
>> >> >>> > http://lists.webkit.org/mailman/listinfo.cg

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

It seems like it doesn't scale very well to have to stand-up new buildbots
for each
new feature.  At least in the Chromium port, it is possible for the Chromium
repo
to override ENABLE_ flags so that only DRT gets built with a prototype
feature,
making it easy to test a prototype feature using existing buildbots.

-Darin


On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth  wrote:

> If you're super worried about folks shipping the feature before it's
> ready, then that approach can make sense.  I'm not sure how well it
> scales, but we can worry about that problem when we have N such
> configurations.
>
> Adam
>
>
> On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang  wrote:
> > I don't understand how changing the name prevents the feature from being
> > shipped half-done.  If we're going to ship a half-done feature, we may as
> > well use the vendor prefixed name so sites don't depend on the goofy
> name.
> >
> > However, I'm willing to run a buildbot for this and that seems better
> than
> > shipping a half-done feature.  I don't expect it to be a core builder and
> > Ojan and I will be the ones keeping it green.  Isn't this what we're
> doing
> > for other features like CSS Regions and Exclusions?
> >
> > On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth  wrote:
> >>
> >> It seems like the simplest thing is to have an ENABLE macro that's
> >> turned on and to use the normal bots.  If you're really worried about
> >> folks shipping the feature half-done by accident, you can use a goofy
> >> name like -webkit-goofybox (or whatever) and rename it to the final
> >> name when you're ready.
> >>
> >> Adam
> >>
> >>
> >> On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai  wrote:
> >> > Kind of. We could make the functionality only work at runtime, but
> >> > adding
> >> > the properties to the CSS parser would be difficult to make runtime
> >> > configurable. So, the CSS properties would parse correctly but do
> >> > nothing.
> >> > That's especially problematic for properties like "display" that would
> >> > then
> >> > get an invalid value.
> >> > My current plan was still to test this incrementally. We'd include
> tests
> >> > as
> >> > we went, but skip the flexbox subdirectory. We would just run the
> tests
> >> > locally during development. This has the downside that other changes
> >> > might
> >> > break the flexbox tests, but thats a pain I'm willing to live with.
> >> > I'm fine doing this differently if people have strong opinions.
> >> > Ojan
> >> >
> >> > On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher 
> >> > wrote:
> >> >>
> >> >> Is it possible for this feature to be enabled at runtime?
> >> >>
> >> >> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
> >> >> > New features should be tested incrementally as they are developed.
> >> >> > That means running them on build.webkit.org. The decision to ship
> a
> >> >> > feature is separate.
> >> >> >
> >> >> > Adam
> >> >> >
> >> >> >
> >> >> > On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai 
> >> >> > wrote:
> >> >> >> I don't think we want to ship this until we have a reasonably
> >> >> >> feature
> >> >> >> complete implementation of the spec and that we're convinced the
> >> >> >> spec
> >> >> >> is
> >> >> >> stable. I expect that in implementing this we'll find areas of the
> >> >> >> spec
> >> >> >> that
> >> >> >> need reworking, but at this point it's mainly blocked on
> >> >> >> implementation
> >> >> >> experience.
> >> >> >> I'm not sure it's worth setting a bot up just for this, although
> I'm
> >> >> >> not
> >> >> >> opposed to it. I expect we should have this shippable within a
> >> >> >> couple
> >> >> >> months.
> >> >> >>
> >> >> >> Ojan
> >> >> >> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth 
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> Can't we just define ENABLE_FLEXBOX on one or more of the
> commonly
> >> >> >>> used ports and use the regular bots?
> >> >> >>>
> >> >> >>> Adam
> >> >> >>>
> >> >> >>>
> >> >> >>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang 
> >> >> >>> wrote:
> >> >> >>> > Hi webkit-dev,
> >> >> >>> > I wanted to let you know that Ojan and I plan to add flexbox
> >> >> >>> > layout
> >> >> >>> > support
> >> >> >>> > to WebCore.  WebCore already supports an older flexbox
> >> >> >>> > implementation
> >> >> >>> > (display: box), but the new spec is designed to be easier for
> >> >> >>> > developers
> >> >> >>> > to
> >> >> >>> > understand and more powerful.  The old flexbox will still
> remain
> >> >> >>> > in
> >> >> >>> > WebCore
> >> >> >>> > since none of the CSS properties overlap with the new flexbox
> >> >> >>> > spec.
> >> >> >>> >  The
> >> >> >>> > spec can be found
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > at: http://www.w3.org/TR/css3-flexbox/ (
> http://dev.w3.org/csswg/css3-flexbox/)
> >> >> >>> > This support will be behind the ENABLE_FLEXBOX feature define
> >> >> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a
> >> >> >>> > meta
> >> >> >>> > bug
> >> >> >>> > tracking the feature's development
> >> 

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[James Robinson]

On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher  wrote:

> It seems like it doesn't scale very well to have to stand-up new buildbots
> for each
> new feature.  At least in the Chromium port, it is possible for the
> Chromium repo
> to override ENABLE_ flags so that only DRT gets built with a prototype
> feature,
> making it easy to test a prototype feature using existing buildbots.
>
>
If you mean by using feature_overrides.gypi to overwrite features.gypi, that
mechanism doesn't actually work and people have attempted to remove it.  The
bots that we actually pay attention to all use feature_overrides.gypi.  I
would not encourage that pattern.

- James

-Darin
>
>
> On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth  wrote:
>
>> If you're super worried about folks shipping the feature before it's
>> ready, then that approach can make sense.  I'm not sure how well it
>> scales, but we can worry about that problem when we have N such
>> configurations.
>>
>> Adam
>>
>>
>> On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang  wrote:
>> > I don't understand how changing the name prevents the feature from being
>> > shipped half-done.  If we're going to ship a half-done feature, we may
>> as
>> > well use the vendor prefixed name so sites don't depend on the goofy
>> name.
>> >
>> > However, I'm willing to run a buildbot for this and that seems better
>> than
>> > shipping a half-done feature.  I don't expect it to be a core builder
>> and
>> > Ojan and I will be the ones keeping it green.  Isn't this what we're
>> doing
>> > for other features like CSS Regions and Exclusions?
>> >
>> > On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth  wrote:
>> >>
>> >> It seems like the simplest thing is to have an ENABLE macro that's
>> >> turned on and to use the normal bots.  If you're really worried about
>> >> folks shipping the feature half-done by accident, you can use a goofy
>> >> name like -webkit-goofybox (or whatever) and rename it to the final
>> >> name when you're ready.
>> >>
>> >> Adam
>> >>
>> >>
>> >> On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai  wrote:
>> >> > Kind of. We could make the functionality only work at runtime, but
>> >> > adding
>> >> > the properties to the CSS parser would be difficult to make runtime
>> >> > configurable. So, the CSS properties would parse correctly but do
>> >> > nothing.
>> >> > That's especially problematic for properties like "display" that
>> would
>> >> > then
>> >> > get an invalid value.
>> >> > My current plan was still to test this incrementally. We'd include
>> tests
>> >> > as
>> >> > we went, but skip the flexbox subdirectory. We would just run the
>> tests
>> >> > locally during development. This has the downside that other changes
>> >> > might
>> >> > break the flexbox tests, but thats a pain I'm willing to live with.
>> >> > I'm fine doing this differently if people have strong opinions.
>> >> > Ojan
>> >> >
>> >> > On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher 
>> >> > wrote:
>> >> >>
>> >> >> Is it possible for this feature to be enabled at runtime?
>> >> >>
>> >> >> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
>> >> >> > New features should be tested incrementally as they are developed.
>> >> >> > That means running them on build.webkit.org. The decision to ship
>> a
>> >> >> > feature is separate.
>> >> >> >
>> >> >> > Adam
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai 
>> >> >> > wrote:
>> >> >> >> I don't think we want to ship this until we have a reasonably
>> >> >> >> feature
>> >> >> >> complete implementation of the spec and that we're convinced the
>> >> >> >> spec
>> >> >> >> is
>> >> >> >> stable. I expect that in implementing this we'll find areas of
>> the
>> >> >> >> spec
>> >> >> >> that
>> >> >> >> need reworking, but at this point it's mainly blocked on
>> >> >> >> implementation
>> >> >> >> experience.
>> >> >> >> I'm not sure it's worth setting a bot up just for this, although
>> I'm
>> >> >> >> not
>> >> >> >> opposed to it. I expect we should have this shippable within a
>> >> >> >> couple
>> >> >> >> months.
>> >> >> >>
>> >> >> >> Ojan
>> >> >> >> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth 
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> Can't we just define ENABLE_FLEXBOX on one or more of the
>> commonly
>> >> >> >>> used ports and use the regular bots?
>> >> >> >>>
>> >> >> >>> Adam
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang 
>> >> >> >>> wrote:
>> >> >> >>> > Hi webkit-dev,
>> >> >> >>> > I wanted to let you know that Ojan and I plan to add flexbox
>> >> >> >>> > layout
>> >> >> >>> > support
>> >> >> >>> > to WebCore.  WebCore already supports an older flexbox
>> >> >> >>> > implementation
>> >> >> >>> > (display: box), but the new spec is designed to be easier for
>> >> >> >>> > developers
>> >> >> >>> > to
>> >> >> >>> > understand and more powerful.  The old flexbox will still
>> remain
>> >> >> >>> > in
>> >> >> >>> > WebCore
>> >> >> >>> > since none of the CSS properties overlap w

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

Oh, okay.  Why do we have override_features.gypi then?

Regardless, it seems like we could create a mechanism so that the result of
build-webkit
uses different ENABLE_ options than a stock Chromium build.  There's a
trivial way to switch
b/w the two in the GYP files.

-Darin


On Wed, Jun 8, 2011 at 4:29 PM, James Robinson  wrote:

> On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher  wrote:
>
>> It seems like it doesn't scale very well to have to stand-up new buildbots
>> for each
>> new feature.  At least in the Chromium port, it is possible for the
>> Chromium repo
>> to override ENABLE_ flags so that only DRT gets built with a prototype
>> feature,
>> making it easy to test a prototype feature using existing buildbots.
>>
>>
> If you mean by using feature_overrides.gypi to overwrite features.gypi,
> that mechanism doesn't actually work and people have attempted to remove it.
>  The bots that we actually pay attention to all use feature_overrides.gypi.
>  I would not encourage that pattern.
>
> - James
>
> -Darin
>>
>>
>> On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth  wrote:
>>
>>> If you're super worried about folks shipping the feature before it's
>>> ready, then that approach can make sense.  I'm not sure how well it
>>> scales, but we can worry about that problem when we have N such
>>> configurations.
>>>
>>> Adam
>>>
>>>
>>> On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang  wrote:
>>> > I don't understand how changing the name prevents the feature from
>>> being
>>> > shipped half-done.  If we're going to ship a half-done feature, we may
>>> as
>>> > well use the vendor prefixed name so sites don't depend on the goofy
>>> name.
>>> >
>>> > However, I'm willing to run a buildbot for this and that seems better
>>> than
>>> > shipping a half-done feature.  I don't expect it to be a core builder
>>> and
>>> > Ojan and I will be the ones keeping it green.  Isn't this what we're
>>> doing
>>> > for other features like CSS Regions and Exclusions?
>>> >
>>> > On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth  wrote:
>>> >>
>>> >> It seems like the simplest thing is to have an ENABLE macro that's
>>> >> turned on and to use the normal bots.  If you're really worried about
>>> >> folks shipping the feature half-done by accident, you can use a goofy
>>> >> name like -webkit-goofybox (or whatever) and rename it to the final
>>> >> name when you're ready.
>>> >>
>>> >> Adam
>>> >>
>>> >>
>>> >> On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai 
>>> wrote:
>>> >> > Kind of. We could make the functionality only work at runtime, but
>>> >> > adding
>>> >> > the properties to the CSS parser would be difficult to make runtime
>>> >> > configurable. So, the CSS properties would parse correctly but do
>>> >> > nothing.
>>> >> > That's especially problematic for properties like "display" that
>>> would
>>> >> > then
>>> >> > get an invalid value.
>>> >> > My current plan was still to test this incrementally. We'd include
>>> tests
>>> >> > as
>>> >> > we went, but skip the flexbox subdirectory. We would just run the
>>> tests
>>> >> > locally during development. This has the downside that other changes
>>> >> > might
>>> >> > break the flexbox tests, but thats a pain I'm willing to live with.
>>> >> > I'm fine doing this differently if people have strong opinions.
>>> >> > Ojan
>>> >> >
>>> >> > On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher 
>>> >> > wrote:
>>> >> >>
>>> >> >> Is it possible for this feature to be enabled at runtime?
>>> >> >>
>>> >> >> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
>>> >> >> > New features should be tested incrementally as they are
>>> developed.
>>> >> >> > That means running them on build.webkit.org. The decision to
>>> ship a
>>> >> >> > feature is separate.
>>> >> >> >
>>> >> >> > Adam
>>> >> >> >
>>> >> >> >
>>> >> >> > On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai 
>>> >> >> > wrote:
>>> >> >> >> I don't think we want to ship this until we have a reasonably
>>> >> >> >> feature
>>> >> >> >> complete implementation of the spec and that we're convinced the
>>> >> >> >> spec
>>> >> >> >> is
>>> >> >> >> stable. I expect that in implementing this we'll find areas of
>>> the
>>> >> >> >> spec
>>> >> >> >> that
>>> >> >> >> need reworking, but at this point it's mainly blocked on
>>> >> >> >> implementation
>>> >> >> >> experience.
>>> >> >> >> I'm not sure it's worth setting a bot up just for this, although
>>> I'm
>>> >> >> >> not
>>> >> >> >> opposed to it. I expect we should have this shippable within a
>>> >> >> >> couple
>>> >> >> >> months.
>>> >> >> >>
>>> >> >> >> Ojan
>>> >> >> >> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth 
>>> >> >> >> wrote:
>>> >> >> >>>
>>> >> >> >>> Can't we just define ENABLE_FLEXBOX on one or more of the
>>> commonly
>>> >> >> >>> used ports and use the regular bots?
>>> >> >> >>>
>>> >> >> >>> Adam
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang >> >
>>> >> >> >>> wrote:
>>> >> >> >>> > Hi webkit-dev,
>>> >> >> >>> > I wanted to let you kno

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[James Robinson]

On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher  wrote:

> Oh, okay.  Why do we have override_features.gypi then?
>

We don't, Adam tried to remove it earlier this week and was foiled by some
weird complex failure.  We should get rid of it ASAP.


> Regardless, it seems like we could create a mechanism so that the result of
> build-webkit
> uses different ENABLE_ options than a stock Chromium build.  There's a
> trivial way to switch
> b/w the two in the GYP files.
>

There's danger in testing a different set of ENABLE_s than we ship unless we
are really confident in understanding how the ENABLE_'d code interacts with
the rest of the codebase.

- James

>
> -Darin
>
>
> On Wed, Jun 8, 2011 at 4:29 PM, James Robinson  wrote:
>
>> On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher  wrote:
>>
>>> It seems like it doesn't scale very well to have to stand-up new
>>> buildbots for each
>>> new feature.  At least in the Chromium port, it is possible for the
>>> Chromium repo
>>> to override ENABLE_ flags so that only DRT gets built with a prototype
>>> feature,
>>> making it easy to test a prototype feature using existing buildbots.
>>>
>>>
>> If you mean by using feature_overrides.gypi to overwrite features.gypi,
>> that mechanism doesn't actually work and people have attempted to remove it.
>>  The bots that we actually pay attention to all use feature_overrides.gypi.
>>  I would not encourage that pattern.
>>
>> - James
>>
>> -Darin
>>>
>>>
>>> On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth  wrote:
>>>
 If you're super worried about folks shipping the feature before it's
 ready, then that approach can make sense.  I'm not sure how well it
 scales, but we can worry about that problem when we have N such
 configurations.

 Adam


 On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang  wrote:
 > I don't understand how changing the name prevents the feature from
 being
 > shipped half-done.  If we're going to ship a half-done feature, we may
 as
 > well use the vendor prefixed name so sites don't depend on the goofy
 name.
 >
 > However, I'm willing to run a buildbot for this and that seems better
 than
 > shipping a half-done feature.  I don't expect it to be a core builder
 and
 > Ojan and I will be the ones keeping it green.  Isn't this what we're
 doing
 > for other features like CSS Regions and Exclusions?
 >
 > On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth 
 wrote:
 >>
 >> It seems like the simplest thing is to have an ENABLE macro that's
 >> turned on and to use the normal bots.  If you're really worried about
 >> folks shipping the feature half-done by accident, you can use a goofy
 >> name like -webkit-goofybox (or whatever) and rename it to the final
 >> name when you're ready.
 >>
 >> Adam
 >>
 >>
 >> On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai 
 wrote:
 >> > Kind of. We could make the functionality only work at runtime, but
 >> > adding
 >> > the properties to the CSS parser would be difficult to make runtime
 >> > configurable. So, the CSS properties would parse correctly but do
 >> > nothing.
 >> > That's especially problematic for properties like "display" that
 would
 >> > then
 >> > get an invalid value.
 >> > My current plan was still to test this incrementally. We'd include
 tests
 >> > as
 >> > we went, but skip the flexbox subdirectory. We would just run the
 tests
 >> > locally during development. This has the downside that other
 changes
 >> > might
 >> > break the flexbox tests, but thats a pain I'm willing to live with.
 >> > I'm fine doing this differently if people have strong opinions.
 >> > Ojan
 >> >
 >> > On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher 
 >> > wrote:
 >> >>
 >> >> Is it possible for this feature to be enabled at runtime?
 >> >>
 >> >> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
 >> >> > New features should be tested incrementally as they are
 developed.
 >> >> > That means running them on build.webkit.org. The decision to
 ship a
 >> >> > feature is separate.
 >> >> >
 >> >> > Adam
 >> >> >
 >> >> >
 >> >> > On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai 
 >> >> > wrote:
 >> >> >> I don't think we want to ship this until we have a reasonably
 >> >> >> feature
 >> >> >> complete implementation of the spec and that we're convinced
 the
 >> >> >> spec
 >> >> >> is
 >> >> >> stable. I expect that in implementing this we'll find areas of
 the
 >> >> >> spec
 >> >> >> that
 >> >> >> need reworking, but at this point it's mainly blocked on
 >> >> >> implementation
 >> >> >> experience.
 >> >> >> I'm not sure it's worth setting a bot up just for this,
 although I'm
 >> >> >> not
 >> >> >> opposed to it. I expect we should have this shippab

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

On Wed, Jun 8, 2011 at 4:59 PM, James Robinson  wrote:

> On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher  wrote:
>
>> Oh, okay.  Why do we have override_features.gypi then?
>>
>
> We don't, Adam tried to remove it earlier this week and was foiled by some
> weird complex failure.  We should get rid of it ASAP.
>
>
OK ... I guess things have changed.



>
>> Regardless, it seems like we could create a mechanism so that the result
>> of build-webkit
>> uses different ENABLE_ options than a stock Chromium build.  There's a
>> trivial way to switch
>> b/w the two in the GYP files.
>>
>
> There's danger in testing a different set of ENABLE_s than we ship unless
> we are really confident in understanding how the ENABLE_'d code interacts
> with the rest of the codebase.
>
>

I'm not sure that is a big deal.  The Chromium build bots at
build.chromium.org run DRT built from a Chromium checkout.  The
build.webkit.org bots are intended to provide compile and DRT feedback for
the Chromium port that is visible to the rest of the WebKit community.  If
the configs between build.webkit.org and build.chromium.org differ, maybe
that is not so bad?

Anyways, all of this is just to avoid what would ultimately be a much better
solution:  it should be possible to develop runtime enabled CSS features.
 Then, we wouldn't worry about different build configs or having to stand-up
different build bots.  It would be easier for the next person wanting to
develop a new CSS feature.

-Darin




> - James
>
>>
>> -Darin
>>
>>
>> On Wed, Jun 8, 2011 at 4:29 PM, James Robinson  wrote:
>>
>>> On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher  wrote:
>>>
 It seems like it doesn't scale very well to have to stand-up new
 buildbots for each
 new feature.  At least in the Chromium port, it is possible for the
 Chromium repo
 to override ENABLE_ flags so that only DRT gets built with a prototype
 feature,
 making it easy to test a prototype feature using existing buildbots.


>>> If you mean by using feature_overrides.gypi to overwrite features.gypi,
>>> that mechanism doesn't actually work and people have attempted to remove it.
>>>  The bots that we actually pay attention to all use feature_overrides.gypi.
>>>  I would not encourage that pattern.
>>>
>>> - James
>>>
>>> -Darin


 On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth  wrote:

> If you're super worried about folks shipping the feature before it's
> ready, then that approach can make sense.  I'm not sure how well it
> scales, but we can worry about that problem when we have N such
> configurations.
>
> Adam
>
>
> On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang  wrote:
> > I don't understand how changing the name prevents the feature from
> being
> > shipped half-done.  If we're going to ship a half-done feature, we
> may as
> > well use the vendor prefixed name so sites don't depend on the goofy
> name.
> >
> > However, I'm willing to run a buildbot for this and that seems better
> than
> > shipping a half-done feature.  I don't expect it to be a core builder
> and
> > Ojan and I will be the ones keeping it green.  Isn't this what we're
> doing
> > for other features like CSS Regions and Exclusions?
> >
> > On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth 
> wrote:
> >>
> >> It seems like the simplest thing is to have an ENABLE macro that's
> >> turned on and to use the normal bots.  If you're really worried
> about
> >> folks shipping the feature half-done by accident, you can use a
> goofy
> >> name like -webkit-goofybox (or whatever) and rename it to the final
> >> name when you're ready.
> >>
> >> Adam
> >>
> >>
> >> On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai 
> wrote:
> >> > Kind of. We could make the functionality only work at runtime, but
> >> > adding
> >> > the properties to the CSS parser would be difficult to make
> runtime
> >> > configurable. So, the CSS properties would parse correctly but do
> >> > nothing.
> >> > That's especially problematic for properties like "display" that
> would
> >> > then
> >> > get an invalid value.
> >> > My current plan was still to test this incrementally. We'd include
> tests
> >> > as
> >> > we went, but skip the flexbox subdirectory. We would just run the
> tests
> >> > locally during development. This has the downside that other
> changes
> >> > might
> >> > break the flexbox tests, but thats a pain I'm willing to live
> with.
> >> > I'm fine doing this differently if people have strong opinions.
> >> > Ojan
> >> >
> >> > On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher  >
> >> > wrote:
> >> >>
> >> >> Is it possible for this feature to be enabled at runtime?
> >> >>
> >> >> On Jun 8, 2011 11:38 AM, "Adam Barth"  wrote:
> >> >> > Ne

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Dirk Pranke]

On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher  wrote:
>
>
> On Wed, Jun 8, 2011 at 4:59 PM, James Robinson  wrote:
>>
>> On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher  wrote:
>>>
>>> Oh, okay.  Why do we have override_features.gypi then?
>>
>> We don't, Adam tried to remove it earlier this week and was foiled by some
>> weird complex failure.  We should get rid of it ASAP.
>
> OK ... I guess things have changed.
>
>>>
>>> Regardless, it seems like we could create a mechanism so that the result
>>> of build-webkit
>>> uses different ENABLE_ options than a stock Chromium build.  There's a
>>> trivial way to switch
>>> b/w the two in the GYP files.
>>
>> There's danger in testing a different set of ENABLE_s than we ship unless
>> we are really confident in understanding how the ENABLE_'d code interacts
>> with the rest of the codebase.
>
>
> I'm not sure that is a big deal.  The Chromium build bots at
> build.chromium.org run DRT built from a Chromium checkout.  The
> build.webkit.org bots are intended to provide compile and DRT feedback for
> the Chromium port that is visible to the rest of the WebKit community.  If
> the configs between build.webkit.org and build.chromium.org differ, maybe
> that is not so bad?

Boy, that seems like a recipe for pain from my point of view. I'd be
against this unless there was a *big* win for some reason.

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

Are you referring to the additional cost of maintaining different test
expectations between the two configs?  Agreed, that would suck.

So, how painful would it be to add runtime enablement support for new CSS
features?
On Jun 8, 2011 5:16 PM, "Dirk Pranke"  wrote:
> On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher  wrote:
>>
>>
>> On Wed, Jun 8, 2011 at 4:59 PM, James Robinson  wrote:
>>>
>>> On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher  wrote:

 Oh, okay.  Why do we have override_features.gypi then?
>>>
>>> We don't, Adam tried to remove it earlier this week and was foiled by
some
>>> weird complex failure.  We should get rid of it ASAP.
>>
>> OK ... I guess things have changed.
>>

 Regardless, it seems like we could create a mechanism so that the
result
 of build-webkit
 uses different ENABLE_ options than a stock Chromium build.  There's a
 trivial way to switch
 b/w the two in the GYP files.
>>>
>>> There's danger in testing a different set of ENABLE_s than we ship
unless
>>> we are really confident in understanding how the ENABLE_'d code
interacts
>>> with the rest of the codebase.
>>
>>
>> I'm not sure that is a big deal.  The Chromium build bots at
>> build.chromium.org run DRT built from a Chromium checkout.  The
>> build.webkit.org bots are intended to provide compile and DRT feedback
for
>> the Chromium port that is visible to the rest of the WebKit community.
 If
>> the configs between build.webkit.org and build.chromium.org differ, maybe
>> that is not so bad?
>
> Boy, that seems like a recipe for pain from my point of view. I'd be
> against this unless there was a *big* win for some reason.
>
> -- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Dirk Pranke]

No, but I hadn't even thought of that ;)

Mostly I was thinking of the pain of developers having to keep track
of which configuration was which, testing in both configurations, etc.

-- Dirk

On Wed, Jun 8, 2011 at 5:24 PM, Darin Fisher  wrote:
> Are you referring to the additional cost of maintaining different test
> expectations between the two configs?  Agreed, that would suck.
>
> So, how painful would it be to add runtime enablement support for new CSS
> features?
>
> On Jun 8, 2011 5:16 PM, "Dirk Pranke"  wrote:
>> On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher  wrote:
>>>
>>>
>>> On Wed, Jun 8, 2011 at 4:59 PM, James Robinson  wrote:

 On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher  wrote:
>
> Oh, okay.  Why do we have override_features.gypi then?

 We don't, Adam tried to remove it earlier this week and was foiled by
 some
 weird complex failure.  We should get rid of it ASAP.
>>>
>>> OK ... I guess things have changed.
>>>
>
> Regardless, it seems like we could create a mechanism so that the
> result
> of build-webkit
> uses different ENABLE_ options than a stock Chromium build.  There's a
> trivial way to switch
> b/w the two in the GYP files.

 There's danger in testing a different set of ENABLE_s than we ship
 unless
 we are really confident in understanding how the ENABLE_'d code
 interacts
 with the rest of the codebase.
>>>
>>>
>>> I'm not sure that is a big deal.  The Chromium build bots at
>>> build.chromium.org run DRT built from a Chromium checkout.  The
>>> build.webkit.org bots are intended to provide compile and DRT feedback
>>> for
>>> the Chromium port that is visible to the rest of the WebKit community.
>>>  If
>>> the configs between build.webkit.org and build.chromium.org differ, maybe
>>> that is not so bad?
>>
>> Boy, that seems like a recipe for pain from my point of view. I'd be
>> against this unless there was a *big* win for some reason.
>>
>> -- Dirk
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Adam Barth]

The difference between runtime and compile time enabling seems like a red
herring.  The issue is more which configurations to test where and to ship
where, not how to do the configuring.

Adam
 On Jun 8, 2011 5:25 PM, "Darin Fisher"  wrote:
> Are you referring to the additional cost of maintaining different test
> expectations between the two configs? Agreed, that would suck.
>
> So, how painful would it be to add runtime enablement support for new CSS
> features?
> On Jun 8, 2011 5:16 PM, "Dirk Pranke"  wrote:
>> On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher  wrote:
>>>
>>>
>>> On Wed, Jun 8, 2011 at 4:59 PM, James Robinson 
wrote:

 On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher 
wrote:
>
> Oh, okay. Why do we have override_features.gypi then?

 We don't, Adam tried to remove it earlier this week and was foiled by
> some
 weird complex failure. We should get rid of it ASAP.
>>>
>>> OK ... I guess things have changed.
>>>
>
> Regardless, it seems like we could create a mechanism so that the
> result
> of build-webkit
> uses different ENABLE_ options than a stock Chromium build. There's a
> trivial way to switch
> b/w the two in the GYP files.

 There's danger in testing a different set of ENABLE_s than we ship
> unless
 we are really confident in understanding how the ENABLE_'d code
> interacts
 with the rest of the codebase.
>>>
>>>
>>> I'm not sure that is a big deal. The Chromium build bots at
>>> build.chromium.org run DRT built from a Chromium checkout. The
>>> build.webkit.org bots are intended to provide compile and DRT feedback
> for
>>> the Chromium port that is visible to the rest of the WebKit community.
> If
>>> the configs between build.webkit.org and build.chromium.org differ,
maybe
>>> that is not so bad?
>>
>> Boy, that seems like a recipe for pain from my point of view. I'd be
>> against this unless there was a *big* win for some reason.
>>
>> -- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

OK, but it is very nice to ship what you test (i.e., avoid the need to
create a separate build of WebCore for testing).  Continuous integration is
also nice (i.e., no branches).

Marrying those constraints leads to runtime enabling features.  This is
precisely the recipe Chromium uses to great avail for features exposed
through JS.  Why wouldn't we want the same for CSS features?

-Darin


On Wed, Jun 8, 2011 at 5:48 PM, Adam Barth  wrote:

> The difference between runtime and compile time enabling seems like a red
> herring.  The issue is more which configurations to test where and to ship
> where, not how to do the configuring.
>
> Adam
>  On Jun 8, 2011 5:25 PM, "Darin Fisher"  wrote:
> > Are you referring to the additional cost of maintaining different test
> > expectations between the two configs? Agreed, that would suck.
> >
> > So, how painful would it be to add runtime enablement support for new CSS
> > features?
> > On Jun 8, 2011 5:16 PM, "Dirk Pranke"  wrote:
> >> On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher 
> wrote:
> >>>
> >>>
> >>> On Wed, Jun 8, 2011 at 4:59 PM, James Robinson 
> wrote:
> 
>  On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher 
> wrote:
> >
> > Oh, okay. Why do we have override_features.gypi then?
> 
>  We don't, Adam tried to remove it earlier this week and was foiled by
> > some
>  weird complex failure. We should get rid of it ASAP.
> >>>
> >>> OK ... I guess things have changed.
> >>>
> >
> > Regardless, it seems like we could create a mechanism so that the
> > result
> > of build-webkit
> > uses different ENABLE_ options than a stock Chromium build. There's a
> > trivial way to switch
> > b/w the two in the GYP files.
> 
>  There's danger in testing a different set of ENABLE_s than we ship
> > unless
>  we are really confident in understanding how the ENABLE_'d code
> > interacts
>  with the rest of the codebase.
> >>>
> >>>
> >>> I'm not sure that is a big deal. The Chromium build bots at
> >>> build.chromium.org run DRT built from a Chromium checkout. The
> >>> build.webkit.org bots are intended to provide compile and DRT feedback
> > for
> >>> the Chromium port that is visible to the rest of the WebKit community.
> > If
> >>> the configs between build.webkit.org and build.chromium.org differ,
> maybe
> >>> that is not so bad?
> >>
> >> Boy, that seems like a recipe for pain from my point of view. I'd be
> >> against this unless there was a *big* win for some reason.
> >>
> >> -- Dirk
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Hajime Morita]

+1 for runtime configuration.

Keeping code runnable is nice, and hard if it's disabled on many
developers' working copies.
We don't need to use traditional flag-holder like Settings class
and can use simple global-ish variables instead,
because We don't need to configure it per-Page basis.

I personally prefer compilation ENABLE flag only for possible
"optional" features,
and most of CSS functionalities aren't that case.
(This claim might be controversial though.)

--
morrita

On Thu, Jun 9, 2011 at 1:29 PM, Darin Fisher  wrote:
> OK, but it is very nice to ship what you test (i.e., avoid the need to
> create a separate build of WebCore for testing).  Continuous integration is
> also nice (i.e., no branches).
> Marrying those constraints leads to runtime enabling features.  This is
> precisely the recipe Chromium uses to great avail for features exposed
> through JS.  Why wouldn't we want the same for CSS features?
> -Darin
>
> On Wed, Jun 8, 2011 at 5:48 PM, Adam Barth  wrote:
>>
>> The difference between runtime and compile time enabling seems like a red
>> herring.  The issue is more which configurations to test where and to ship
>> where, not how to do the configuring.
>>
>> Adam
>>
>> On Jun 8, 2011 5:25 PM, "Darin Fisher"  wrote:
>> > Are you referring to the additional cost of maintaining different test
>> > expectations between the two configs? Agreed, that would suck.
>> >
>> > So, how painful would it be to add runtime enablement support for new
>> > CSS
>> > features?
>> > On Jun 8, 2011 5:16 PM, "Dirk Pranke"  wrote:
>> >> On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher 
>> >> wrote:
>> >>>
>> >>>
>> >>> On Wed, Jun 8, 2011 at 4:59 PM, James Robinson 
>> >>> wrote:
>> 
>>  On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher 
>>  wrote:
>> >
>> > Oh, okay. Why do we have override_features.gypi then?
>> 
>>  We don't, Adam tried to remove it earlier this week and was foiled by
>> > some
>>  weird complex failure. We should get rid of it ASAP.
>> >>>
>> >>> OK ... I guess things have changed.
>> >>>
>> >
>> > Regardless, it seems like we could create a mechanism so that the
>> > result
>> > of build-webkit
>> > uses different ENABLE_ options than a stock Chromium build. There's
>> > a
>> > trivial way to switch
>> > b/w the two in the GYP files.
>> 
>>  There's danger in testing a different set of ENABLE_s than we ship
>> > unless
>>  we are really confident in understanding how the ENABLE_'d code
>> > interacts
>>  with the rest of the codebase.
>> >>>
>> >>>
>> >>> I'm not sure that is a big deal. The Chromium build bots at
>> >>> build.chromium.org run DRT built from a Chromium checkout. The
>> >>> build.webkit.org bots are intended to provide compile and DRT feedback
>> > for
>> >>> the Chromium port that is visible to the rest of the WebKit community.
>> > If
>> >>> the configs between build.webkit.org and build.chromium.org differ,
>> >>> maybe
>> >>> that is not so bad?
>> >>
>> >> Boy, that seems like a recipe for pain from my point of view. I'd be
>> >> against this unless there was a *big* win for some reason.
>> >>
>> >> -- Dirk
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>



-- 
morrita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Sam Weinig]

Why should we implement this spec? We already have one flex box implementation 
that we can never remove (and corresponds closely to Firefox's) so it seems to 
me that we should work on standardizing that model. Adding a large bunch of 
code that duplicates existing functionality seems foolish.

If the issue is the syntax for describing flexing, perhaps the spec should be 
written in a backwards compatible way, that supports both the new syntax and 
the old syntax, but the underlying implementation can remain.

-Sam

On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:

> Hi webkit-dev,
> 
> I wanted to let you know that Ojan and I plan to add flexbox layout support 
> to WebCore.  WebCore already supports an older flexbox implementation 
> (display: box), but the new spec is designed to be easier for developers to 
> understand and more powerful.  The old flexbox will still remain in WebCore 
> since none of the CSS properties overlap with the new flexbox spec.  The spec 
> can be found at: http://www.w3.org/TR/css3-flexbox/ 
> (http://dev.w3.org/csswg/css3-flexbox/)
> 
> This support will be behind the ENABLE_FLEXBOX feature define 
> (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug 
> tracking the feature's development 
> (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to 
> eventually be enabled by all ports.
> 
> I am ready to setup a buildbot for tracking the compile and flexbox related 
> layout tests.  Should I go ahead and get this added to build.webkit.org's 
> waterfall?
> 
> Thanks,
> Tony
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Tony Chang]

On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig  wrote:

> Why should we implement this spec? We already have one flex box
> implementation that we can never remove (and corresponds closely to
> Firefox's) so it seems to me that we should work on standardizing that
> model. Adding a large bunch of code that duplicates existing functionality
> seems foolish.
>

There was an attempt to standardize the old flexbox (
http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/), but that effort seems
to have fizzled.  I attempted to write some patches to make WebKit's old
flexbox implementation match that spec, but Hyatt recommended against that
because it can only break sites that are targetting WebKit's existing
flexbox implementation.  WebKit's implementation and Firefox's
implementation are different enough that the current uses of flexbox are
mostly browser specific (e.g., dashboard widgets).

If the issue is the syntax for describing flexing, perhaps the spec should
> be written in a backwards compatible way, that supports both the new syntax
> and the old syntax, but the underlying implementation can remain.
>

The new syntax describes a superset of features provided by the old syntax.
 I think it's possible to implement the old flexbox on top of the new
flexbox implementation and that seems like a worthwhile goal, but it'll
probably easier to see the similarities for refactoring after the code has
been written.





> On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
>
> Hi webkit-dev,
>
> I wanted to let you know that Ojan and I plan to add flexbox layout support
> to WebCore.  WebCore already supports an older flexbox implementation
> (display: box), but the new spec is designed to be easier for developers to
> understand and more powerful.  The old flexbox will still remain in WebCore
> since none of the CSS properties overlap with the new flexbox spec.  The
> spec can be found at: http://www.w3.org/TR/css3-flexbox/ (
> http://dev.w3.org/csswg/css3-flexbox/
> )
>
> This support will be behind the ENABLE_FLEXBOX feature define (
> https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug
> tracking the feature's development (
> https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to
> eventually be enabled by all ports.
>
> I am ready to setup a buildbot for tracking the compile and flexbox related
> layout tests.  Should I go ahead and get this added to build.webkit.org's
> waterfall?
>
> Thanks,
> Tony
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Maciej Stachowiak]

On Jun 9, 2011, at 3:00 PM, Tony Chang wrote:

> On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig  wrote:
> Why should we implement this spec? We already have one flex box 
> implementation that we can never remove (and corresponds closely to 
> Firefox's) so it seems to me that we should work on standardizing that model. 
> Adding a large bunch of code that duplicates existing functionality seems 
> foolish.
> 
> There was an attempt to standardize the old flexbox 
> (http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/), but that effort seems 
> to have fizzled.  I attempted to write some patches to make WebKit's old 
> flexbox implementation match that spec, but Hyatt recommended against that 
> because it can only break sites that are targetting WebKit's existing flexbox 
> implementation.  WebKit's implementation and Firefox's implementation are 
> different enough that the current uses of flexbox are mostly browser specific 
> (e.g., dashboard widgets).
> 
> If the issue is the syntax for describing flexing, perhaps the spec should be 
> written in a backwards compatible way, that supports both the new syntax and 
> the old syntax, but the underlying implementation can remain.
> 
> The new syntax describes a superset of features provided by the old syntax.  
> I think it's possible to implement the old flexbox on top of the new flexbox 
> implementation and that seems like a worthwhile goal, but it'll probably 
> easier to see the similarities for refactoring after the code has been 
> written.

If it's a superset then I would much prefer to see the old code incrementally 
enhanced to support the extended features and new syntax, then to first rewrite 
from scratch and merge. Maybe the right step 1 is refactoring and cleaning up 
the old code. Rewriting from scratch throws away accumulated knowledge, and in 
cases where we have to keep the old implementation too, bloats the code.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Tony Chang]

On Thu, Jun 9, 2011 at 3:55 PM, Maciej Stachowiak  wrote:
>
> On Jun 9, 2011, at 3:00 PM, Tony Chang wrote:
>
> On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig  wrote:
>
>> If the issue is the syntax for describing flexing, perhaps the spec should
>> be written in a backwards compatible way, that supports both the new syntax
>> and the old syntax, but the underlying implementation can remain.
>>
>
> The new syntax describes a superset of features provided by the old syntax.
>  I think it's possible to implement the old flexbox on top of the new
> flexbox implementation and that seems like a worthwhile goal, but it'll
> probably easier to see the similarities for refactoring after the code has
> been written.
>
> If it's a superset then I would much prefer to see the old code
> incrementally enhanced to support the extended features and new syntax, then
> to first rewrite from scratch and merge. Maybe the right step 1 is
> refactoring and cleaning up the old code. Rewriting from scratch throws away
> accumulated knowledge, and in cases where we have to keep the old
> implementation too, bloats the code.
>

The decision to start from scratch was based on a recommendation by Hyatt on
IRC to just rename the old implementation (to RenderDeprecatedFlexibleBox or
something) and make a new implementation of RenderFlexibleBox.

I can try to incrementally improve the existing code, but I think that'll
hinder the design of the new code.  For example, when writing the new code,
I plan on adding the CSS properties flex-direction, flex-order, and
flex-pack incrementally (separate patches for each, maybe multiple for
flex-direction).  Since the old flexbox code has slightly different
variations of these already implemented, I would have to run the code for
them on the old code path but not the new code path.  While I think this is
technically possible, I think it'll be tricky to get right.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Ojan Vafai]

On Fri, Jun 10, 2011 at 10:14 AM, Tony Chang  wrote:

> On Thu, Jun 9, 2011 at 3:55 PM, Maciej Stachowiak  wrote:
>
>> On Jun 9, 2011, at 3:00 PM, Tony Chang wrote:
>>
>> On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig  wrote:
>>
>>> If the issue is the syntax for describing flexing, perhaps the spec
>>> should be written in a backwards compatible way, that supports both the new
>>> syntax and the old syntax, but the underlying implementation can remain.
>>>
>>
>> The new syntax describes a superset of features provided by the old
>> syntax.  I think it's possible to implement the old flexbox on top of the
>> new flexbox implementation and that seems like a worthwhile goal, but it'll
>> probably easier to see the similarities for refactoring after the code has
>> been written.
>>
>> If it's a superset then I would much prefer to see the old code
>> incrementally enhanced to support the extended features and new syntax, then
>> to first rewrite from scratch and merge. Maybe the right step 1 is
>> refactoring and cleaning up the old code. Rewriting from scratch throws away
>> accumulated knowledge, and in cases where we have to keep the old
>> implementation too, bloats the code.
>>
>
> The decision to start from scratch was based on a recommendation by Hyatt
> on IRC to just rename the old implementation (to RenderDeprecatedFlexibleBox
> or something) and make a new implementation of RenderFlexibleBox.
>

Hyatt should probably chime in here, but on IRC he seemed to think that the
old RenderFlexibleBox was a bad design and needed a complete rewrite
anyways.

Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[David Hyatt]

Just so people know, it was my recommendation that they just start with a new 
renderer and implementation.

Some other recommendations I would make here (apologies if they have been 
implemented already):

(1) Rename the current RenderFlexibleBox to put "deprecated" into the name, 
e.g., RenderDeprecatedFlexibleBox.

(2) The old flexbox was never patched for vertical writing modes. Please make 
sure when you build the new renderer from the ground up that you take this into 
account.

(3) Please consult with rendering experts for any changes you have to make to 
base classes, especially RenderBlock and RenderBox. We may be able to help 
simplify some of that code, especially compared to the old flexbox.

(4) Use the old flexbox code as a rough guide, but be aware of its issues, 
e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I 
think some of the bugs you tried to fix already should inform this somewhat.

Definitely keep rendering experts in the loop on this and have fun implementing!

Dave


> On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
> 
>> Hi webkit-dev,
>> 
>> I wanted to let you know that Ojan and I plan to add flexbox layout support 
>> to WebCore.  WebCore already supports an older flexbox implementation 
>> (display: box), but the new spec is designed to be easier for developers to 
>> understand and more powerful.  The old flexbox will still remain in WebCore 
>> since none of the CSS properties overlap with the new flexbox spec.  The 
>> spec can be found at: http://www.w3.org/TR/css3-flexbox/ 
>> (http://dev.w3.org/csswg/css3-flexbox/)
>> 
>> This support will be behind the ENABLE_FLEXBOX feature define 
>> (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug 
>> tracking the feature's development 
>> (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to 
>> eventually be enabled by all ports.
>> 
>> I am ready to setup a buildbot for tracking the compile and flexbox related 
>> layout tests.  Should I go ahead and get this added to build.webkit.org's 
>> waterfall?
>> 
>> Thanks,
>> Tony
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Sam Weinig]

Since it is confusing to me (and may be to others), perhaps a different name 
than ENABLE_FLEXBOX should be used, given that we already have flexbox. Maybe, 
ENABLE_NEW_FLEXBOX?

-Sam
  
On Jun 10, 2011, at 2:42 PM, David Hyatt wrote:

> Just so people know, it was my recommendation that they just start with a new 
> renderer and implementation.
> 
> Some other recommendations I would make here (apologies if they have been 
> implemented already):
> 
> (1) Rename the current RenderFlexibleBox to put "deprecated" into the name, 
> e.g., RenderDeprecatedFlexibleBox.
> 
> (2) The old flexbox was never patched for vertical writing modes. Please make 
> sure when you build the new renderer from the ground up that you take this 
> into account.
> 
> (3) Please consult with rendering experts for any changes you have to make to 
> base classes, especially RenderBlock and RenderBox. We may be able to help 
> simplify some of that code, especially compared to the old flexbox.
> 
> (4) Use the old flexbox code as a rough guide, but be aware of its issues, 
> e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I 
> think some of the bugs you tried to fix already should inform this somewhat.
> 
> Definitely keep rendering experts in the loop on this and have fun 
> implementing!
> 
> Dave
> 
> 
>> On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
>> 
>>> Hi webkit-dev,
>>> 
>>> I wanted to let you know that Ojan and I plan to add flexbox layout support 
>>> to WebCore.  WebCore already supports an older flexbox implementation 
>>> (display: box), but the new spec is designed to be easier for developers to 
>>> understand and more powerful.  The old flexbox will still remain in WebCore 
>>> since none of the CSS properties overlap with the new flexbox spec.  The 
>>> spec can be found at: http://www.w3.org/TR/css3-flexbox/ 
>>> (http://dev.w3.org/csswg/css3-flexbox/)
>>> 
>>> This support will be behind the ENABLE_FLEXBOX feature define 
>>> (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug 
>>> tracking the feature's development 
>>> (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to 
>>> eventually be enabled by all ports.
>>> 
>>> I am ready to setup a buildbot for tracking the compile and flexbox related 
>>> layout tests.  Should I go ahead and get this added to build.webkit.org's 
>>> waterfall?
>>> 
>>> Thanks,
>>> Tony
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Tony Chang]

Sure, no problem.  I'll rename it to ENALBE_NEW_FLEXBOX.

On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig  wrote:

> Since it is confusing to me (and may be to others), perhaps a different
> name than ENABLE_FLEXBOX should be used, given that we already have flexbox.
> Maybe, ENABLE_NEW_FLEXBOX?
>
> -Sam
>
> On Jun 10, 2011, at 2:42 PM, David Hyatt wrote:
>
> Just so people know, it was my recommendation that they just start with a
> new renderer and implementation.
>
> Some other recommendations I would make here (apologies if they have been
> implemented already):
>
> (1) Rename the current RenderFlexibleBox to put "deprecated" into the name,
> e.g., RenderDeprecatedFlexibleBox.
>
> (2) The old flexbox was never patched for vertical writing modes. Please
> make sure when you build the new renderer from the ground up that you take
> this into account.
>
> (3) Please consult with rendering experts for any changes you have to make
> to base classes, especially RenderBlock and RenderBox. We may be able to
> help simplify some of that code, especially compared to the old flexbox.
>
> (4) Use the old flexbox code as a rough guide, but be aware of its issues,
> e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I
> think some of the bugs you tried to fix already should inform this somewhat.
>
> Definitely keep rendering experts in the loop on this and have fun
> implementing!
>
> Dave
>
>
> On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
>
> Hi webkit-dev,
>
> I wanted to let you know that Ojan and I plan to add flexbox layout support
> to WebCore.  WebCore already supports an older flexbox implementation
> (display: box), but the new spec is designed to be easier for developers to
> understand and more powerful.  The old flexbox will still remain in WebCore
> since none of the CSS properties overlap with the new flexbox spec.  The
> spec can be found at: http://www.w3.org/TR/css3-flexbox/ (
> http://dev.w3.org/csswg/css3-flexbox/
> )
>
> This support will be behind the ENABLE_FLEXBOX feature define (
> https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug
> tracking the feature's development (
> https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to
> eventually be enabled by all ports.
>
> I am ready to setup a buildbot for tracking the compile and flexbox related
> layout tests.  Should I go ahead and get this added to build.webkit.org's
> waterfall?
>
> Thanks,
> Tony
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Tony Chang]

Err, ENABLE_NEW_FLEXBOX.

On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang  wrote:

> Sure, no problem.  I'll rename it to ENALBE_NEW_FLEXBOX.
>
>
> On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig  wrote:
>
>> Since it is confusing to me (and may be to others), perhaps a different
>> name than ENABLE_FLEXBOX should be used, given that we already have flexbox.
>> Maybe, ENABLE_NEW_FLEXBOX?
>>
>> -Sam
>>
>> On Jun 10, 2011, at 2:42 PM, David Hyatt wrote:
>>
>> Just so people know, it was my recommendation that they just start with a
>> new renderer and implementation.
>>
>> Some other recommendations I would make here (apologies if they have been
>> implemented already):
>>
>> (1) Rename the current RenderFlexibleBox to put "deprecated" into the
>> name, e.g., RenderDeprecatedFlexibleBox.
>>
>> (2) The old flexbox was never patched for vertical writing modes. Please
>> make sure when you build the new renderer from the ground up that you take
>> this into account.
>>
>> (3) Please consult with rendering experts for any changes you have to make
>> to base classes, especially RenderBlock and RenderBox. We may be able to
>> help simplify some of that code, especially compared to the old flexbox.
>>
>> (4) Use the old flexbox code as a rough guide, but be aware of its issues,
>> e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I
>> think some of the bugs you tried to fix already should inform this somewhat.
>>
>> Definitely keep rendering experts in the loop on this and have fun
>> implementing!
>>
>> Dave
>>
>>
>> On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
>>
>> Hi webkit-dev,
>>
>> I wanted to let you know that Ojan and I plan to add flexbox layout
>> support to WebCore.  WebCore already supports an older flexbox
>> implementation (display: box), but the new spec is designed to be easier for
>> developers to understand and more powerful.  The old flexbox will still
>> remain in WebCore since none of the CSS properties overlap with the new
>> flexbox spec.  The spec can be found at:
>> http://www.w3.org/TR/css3-flexbox/ 
>> (http://dev.w3.org/csswg/css3-flexbox/
>> )
>>
>> This support will be behind the ENABLE_FLEXBOX feature define (
>> https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug
>> tracking the feature's development (
>> https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to
>> eventually be enabled by all ports.
>>
>> I am ready to setup a buildbot for tracking the compile and flexbox
>> related layout tests.  Should I go ahead and get this added to
>> build.webkit.org's waterfall?
>>
>> Thanks,
>> Tony
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Sam Weinig]

Great!

-Sam

On Jun 13, 2011, at 9:37 AM, Tony Chang wrote:

> Sure, no problem.  I'll rename it to ENALBE_NEW_FLEXBOX.
> 
> On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig  wrote:
> Since it is confusing to me (and may be to others), perhaps a different name 
> than ENABLE_FLEXBOX should be used, given that we already have flexbox. 
> Maybe, ENABLE_NEW_FLEXBOX?
> 
> -Sam
>   
> On Jun 10, 2011, at 2:42 PM, David Hyatt wrote:
> 
>> Just so people know, it was my recommendation that they just start with a 
>> new renderer and implementation.
>> 
>> Some other recommendations I would make here (apologies if they have been 
>> implemented already):
>> 
>> (1) Rename the current RenderFlexibleBox to put "deprecated" into the name, 
>> e.g., RenderDeprecatedFlexibleBox.
>> 
>> (2) The old flexbox was never patched for vertical writing modes. Please 
>> make sure when you build the new renderer from the ground up that you take 
>> this into account.
>> 
>> (3) Please consult with rendering experts for any changes you have to make 
>> to base classes, especially RenderBlock and RenderBox. We may be able to 
>> help simplify some of that code, especially compared to the old flexbox.
>> 
>> (4) Use the old flexbox code as a rough guide, but be aware of its issues, 
>> e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I 
>> think some of the bugs you tried to fix already should inform this somewhat.
>> 
>> Definitely keep rendering experts in the loop on this and have fun 
>> implementing!
>> 
>> Dave
>> 
>> 
>>> On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
>>> 
 Hi webkit-dev,
 
 I wanted to let you know that Ojan and I plan to add flexbox layout 
 support to WebCore.  WebCore already supports an older flexbox 
 implementation (display: box), but the new spec is designed to be easier 
 for developers to understand and more powerful.  The old flexbox will 
 still remain in WebCore since none of the CSS properties overlap with the 
 new flexbox spec.  The spec can be found at: 
 http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/)
 
 This support will be behind the ENABLE_FLEXBOX feature define 
 (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug 
 tracking the feature's development 
 (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to 
 eventually be enabled by all ports.
 
 I am ready to setup a buildbot for tracking the compile and flexbox 
 related layout tests.  Should I go ahead and get this added to 
 build.webkit.org's waterfall?
 
 Thanks,
 Tony
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Simon Fraser]

Using terms like 'new' in code is rarely a good idea. In a year, the context 
has gone, and 'new' no longer means anything.

Simon

On Jun 13, 2011, at 9:38 AM, Tony Chang wrote:

> Err, ENABLE_NEW_FLEXBOX.
> 
> On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang  wrote:
> Sure, no problem.  I'll rename it to ENALBE_NEW_FLEXBOX.
> 
> 
> On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig  wrote:
> Since it is confusing to me (and may be to others), perhaps a different name 
> than ENABLE_FLEXBOX should be used, given that we already have flexbox. 
> Maybe, ENABLE_NEW_FLEXBOX?
> 
> -Sam
>   
> On Jun 10, 2011, at 2:42 PM, David Hyatt wrote:
> 
>> Just so people know, it was my recommendation that they just start with a 
>> new renderer and implementation.
>> 
>> Some other recommendations I would make here (apologies if they have been 
>> implemented already):
>> 
>> (1) Rename the current RenderFlexibleBox to put "deprecated" into the name, 
>> e.g., RenderDeprecatedFlexibleBox.
>> 
>> (2) The old flexbox was never patched for vertical writing modes. Please 
>> make sure when you build the new renderer from the ground up that you take 
>> this into account.
>> 
>> (3) Please consult with rendering experts for any changes you have to make 
>> to base classes, especially RenderBlock and RenderBox. We may be able to 
>> help simplify some of that code, especially compared to the old flexbox.
>> 
>> (4) Use the old flexbox code as a rough guide, but be aware of its issues, 
>> e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I 
>> think some of the bugs you tried to fix already should inform this somewhat.
>> 
>> Definitely keep rendering experts in the loop on this and have fun 
>> implementing!
>> 
>> Dave
>> 
>> 
>>> On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
>>> 
 Hi webkit-dev,
 
 I wanted to let you know that Ojan and I plan to add flexbox layout 
 support to WebCore.  WebCore already supports an older flexbox 
 implementation (display: box), but the new spec is designed to be easier 
 for developers to understand and more powerful.  The old flexbox will 
 still remain in WebCore since none of the CSS properties overlap with the 
 new flexbox spec.  The spec can be found at: 
 http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/)
 
 This support will be behind the ENABLE_FLEXBOX feature define 
 (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug 
 tracking the feature's development 
 (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to 
 eventually be enabled by all ports.
 
 I am ready to setup a buildbot for tracking the compile and flexbox 
 related layout tests.  Should I go ahead and get this added to 
 build.webkit.org's waterfall?
 
 Thanks,
 Tony
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Fisher]

Good point!  Maybe we can use a term that is derived from the name of the
spec?  ENABLE_CSS3_FLEXBOX?

-Darin

On Mon, Jun 13, 2011 at 10:50 AM, Simon Fraser wrote:

> Using terms like 'new' in code is rarely a good idea. In a year, the
> context has gone, and 'new' no longer means anything.
>
> Simon
>
>
> On Jun 13, 2011, at 9:38 AM, Tony Chang wrote:
>
> Err, ENABLE_NEW_FLEXBOX.
>
> On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang  wrote:
>
>> Sure, no problem.  I'll rename it to ENALBE_NEW_FLEXBOX.
>>
>>
>> On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig  wrote:
>>
>>> Since it is confusing to me (and may be to others), perhaps a different
>>> name than ENABLE_FLEXBOX should be used, given that we already have flexbox.
>>> Maybe, ENABLE_NEW_FLEXBOX?
>>>
>>> -Sam
>>>
>>> On Jun 10, 2011, at 2:42 PM, David Hyatt wrote:
>>>
>>> Just so people know, it was my recommendation that they just start with a
>>> new renderer and implementation.
>>>
>>> Some other recommendations I would make here (apologies if they have been
>>> implemented already):
>>>
>>> (1) Rename the current RenderFlexibleBox to put "deprecated" into the
>>> name, e.g., RenderDeprecatedFlexibleBox.
>>>
>>> (2) The old flexbox was never patched for vertical writing modes. Please
>>> make sure when you build the new renderer from the ground up that you take
>>> this into account.
>>>
>>> (3) Please consult with rendering experts for any changes you have to
>>> make to base classes, especially RenderBlock and RenderBox. We may be able
>>> to help simplify some of that code, especially compared to the old flexbox.
>>>
>>> (4) Use the old flexbox code as a rough guide, but be aware of its
>>> issues, e.g., too much layout when flexing, box-ordinal stuff is very slow,
>>> etc. I think some of the bugs you tried to fix already should inform this
>>> somewhat.
>>>
>>> Definitely keep rendering experts in the loop on this and have fun
>>> implementing!
>>>
>>> Dave
>>>
>>>
>>> On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
>>>
>>> Hi webkit-dev,
>>>
>>> I wanted to let you know that Ojan and I plan to add flexbox layout
>>> support to WebCore.  WebCore already supports an older flexbox
>>> implementation (display: box), but the new spec is designed to be easier for
>>> developers to understand and more powerful.  The old flexbox will still
>>> remain in WebCore since none of the CSS properties overlap with the new
>>> flexbox spec.  The spec can be found at:
>>> http://www.w3.org/TR/css3-flexbox/ (
>>> http://dev.w3.org/csswg/css3-flexbox/
>>> )
>>>
>>> This support will be behind the ENABLE_FLEXBOX feature define (
>>> https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug
>>> tracking the feature's development (
>>> https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature
>>> to eventually be enabled by all ports.
>>>
>>> I am ready to setup a buildbot for tracking the compile and flexbox
>>> related layout tests.  Should I go ahead and get this added to
>>> build.webkit.org's waterfall?
>>>
>>> Thanks,
>>> Tony
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Sam Weinig]

I think in this case it makes sense, since it is a temporary #define.  But if 
you feel strongly, what would you propose?  Is there a more distinctive name 
than FLEXBOX that identifies this as different from the existing code?

-Sam

On Jun 13, 2011, at 10:50 AM, Simon Fraser wrote:

> Using terms like 'new' in code is rarely a good idea. In a year, the context 
> has gone, and 'new' no longer means anything.
> 
> Simon
> 
> On Jun 13, 2011, at 9:38 AM, Tony Chang wrote:
> 
>> Err, ENABLE_NEW_FLEXBOX.
>> 
>> On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang  wrote:
>> Sure, no problem.  I'll rename it to ENALBE_NEW_FLEXBOX.
>> 
>> 
>> On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig  wrote:
>> Since it is confusing to me (and may be to others), perhaps a different name 
>> than ENABLE_FLEXBOX should be used, given that we already have flexbox. 
>> Maybe, ENABLE_NEW_FLEXBOX?
>> 
>> -Sam
>>   
>> On Jun 10, 2011, at 2:42 PM, David Hyatt wrote:
>> 
>>> Just so people know, it was my recommendation that they just start with a 
>>> new renderer and implementation.
>>> 
>>> Some other recommendations I would make here (apologies if they have been 
>>> implemented already):
>>> 
>>> (1) Rename the current RenderFlexibleBox to put "deprecated" into the name, 
>>> e.g., RenderDeprecatedFlexibleBox.
>>> 
>>> (2) The old flexbox was never patched for vertical writing modes. Please 
>>> make sure when you build the new renderer from the ground up that you take 
>>> this into account.
>>> 
>>> (3) Please consult with rendering experts for any changes you have to make 
>>> to base classes, especially RenderBlock and RenderBox. We may be able to 
>>> help simplify some of that code, especially compared to the old flexbox.
>>> 
>>> (4) Use the old flexbox code as a rough guide, but be aware of its issues, 
>>> e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I 
>>> think some of the bugs you tried to fix already should inform this somewhat.
>>> 
>>> Definitely keep rendering experts in the loop on this and have fun 
>>> implementing!
>>> 
>>> Dave
>>> 
>>> 
 On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
 
> Hi webkit-dev,
> 
> I wanted to let you know that Ojan and I plan to add flexbox layout 
> support to WebCore.  WebCore already supports an older flexbox 
> implementation (display: box), but the new spec is designed to be easier 
> for developers to understand and more powerful.  The old flexbox will 
> still remain in WebCore since none of the CSS properties overlap with the 
> new flexbox spec.  The spec can be found at: 
> http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/)
> 
> This support will be behind the ENABLE_FLEXBOX feature define 
> (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug 
> tracking the feature's development 
> (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature 
> to eventually be enabled by all ports.
> 
> I am ready to setup a buildbot for tracking the compile and flexbox 
> related layout tests.  Should I go ahead and get this added to 
> build.webkit.org's waterfall?
> 
> Thanks,
> Tony
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Simon Fraser]

On Jun 13, 2011, at 10:52 AM, Darin Fisher wrote:

> Good point!  Maybe we can use a term that is derived from the name of the 
> spec?  ENABLE_CSS3_FLEXBOX?

Yep, I like that.

Simon

> 
> -Darin
> 
> On Mon, Jun 13, 2011 at 10:50 AM, Simon Fraser  wrote:
> Using terms like 'new' in code is rarely a good idea. In a year, the context 
> has gone, and 'new' no longer means anything.
> 
> Simon
> 
> 
> On Jun 13, 2011, at 9:38 AM, Tony Chang wrote:
> 
>> Err, ENABLE_NEW_FLEXBOX.
>> 
>> On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang  wrote:
>> Sure, no problem.  I'll rename it to ENALBE_NEW_FLEXBOX.
>> 
>> 
>> On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig  wrote:
>> Since it is confusing to me (and may be to others), perhaps a different name 
>> than ENABLE_FLEXBOX should be used, given that we already have flexbox. 
>> Maybe, ENABLE_NEW_FLEXBOX?
>> 
>> -Sam
>>   
>> On Jun 10, 2011, at 2:42 PM, David Hyatt wrote:
>> 
>>> Just so people know, it was my recommendation that they just start with a 
>>> new renderer and implementation.
>>> 
>>> Some other recommendations I would make here (apologies if they have been 
>>> implemented already):
>>> 
>>> (1) Rename the current RenderFlexibleBox to put "deprecated" into the name, 
>>> e.g., RenderDeprecatedFlexibleBox.
>>> 
>>> (2) The old flexbox was never patched for vertical writing modes. Please 
>>> make sure when you build the new renderer from the ground up that you take 
>>> this into account.
>>> 
>>> (3) Please consult with rendering experts for any changes you have to make 
>>> to base classes, especially RenderBlock and RenderBox. We may be able to 
>>> help simplify some of that code, especially compared to the old flexbox.
>>> 
>>> (4) Use the old flexbox code as a rough guide, but be aware of its issues, 
>>> e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I 
>>> think some of the bugs you tried to fix already should inform this somewhat.
>>> 
>>> Definitely keep rendering experts in the loop on this and have fun 
>>> implementing!
>>> 
>>> Dave
>>> 
>>> 
 On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
 
> Hi webkit-dev,
> 
> I wanted to let you know that Ojan and I plan to add flexbox layout 
> support to WebCore.  WebCore already supports an older flexbox 
> implementation (display: box), but the new spec is designed to be easier 
> for developers to understand and more powerful.  The old flexbox will 
> still remain in WebCore since none of the CSS properties overlap with the 
> new flexbox spec.  The spec can be found at: 
> http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/)
> 
> This support will be behind the ENABLE_FLEXBOX feature define 
> (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug 
> tracking the feature's development 
> (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature 
> to eventually be enabled by all ports.
> 
> I am ready to setup a buildbot for tracking the compile and flexbox 
> related layout tests.  Should I go ahead and get this added to 
> build.webkit.org's waterfall?
> 
> Thanks,
> Tony
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Darin Adler]

On Jun 13, 2011, at 10:52 AM, Darin Fisher wrote:

> On Mon, Jun 13, 2011 at 10:50 AM, Simon Fraser  wrote:
> 
>> Using terms like 'new' in code is rarely a good idea. In a year, the context 
>> has gone, and 'new' no longer means anything.
> 
> Good point! Maybe we can use a term that is derived from the name of the 
> spec?  ENABLE_CSS3_FLEXBOX?

Yes, I think that’s a better name to use.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Sam Weinig]

That totally works for me.

-Sam

On Jun 13, 2011, at 10:52 AM, Darin Fisher wrote:

> Good point!  Maybe we can use a term that is derived from the name of the 
> spec?  ENABLE_CSS3_FLEXBOX?
> 
> -Darin
> 
> On Mon, Jun 13, 2011 at 10:50 AM, Simon Fraser  wrote:
> Using terms like 'new' in code is rarely a good idea. In a year, the context 
> has gone, and 'new' no longer means anything.
> 
> Simon
> 
> 
> On Jun 13, 2011, at 9:38 AM, Tony Chang wrote:
> 
>> Err, ENABLE_NEW_FLEXBOX.
>> 
>> On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang  wrote:
>> Sure, no problem.  I'll rename it to ENALBE_NEW_FLEXBOX.
>> 
>> 
>> On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig  wrote:
>> Since it is confusing to me (and may be to others), perhaps a different name 
>> than ENABLE_FLEXBOX should be used, given that we already have flexbox. 
>> Maybe, ENABLE_NEW_FLEXBOX?
>> 
>> -Sam
>>   
>> On Jun 10, 2011, at 2:42 PM, David Hyatt wrote:
>> 
>>> Just so people know, it was my recommendation that they just start with a 
>>> new renderer and implementation.
>>> 
>>> Some other recommendations I would make here (apologies if they have been 
>>> implemented already):
>>> 
>>> (1) Rename the current RenderFlexibleBox to put "deprecated" into the name, 
>>> e.g., RenderDeprecatedFlexibleBox.
>>> 
>>> (2) The old flexbox was never patched for vertical writing modes. Please 
>>> make sure when you build the new renderer from the ground up that you take 
>>> this into account.
>>> 
>>> (3) Please consult with rendering experts for any changes you have to make 
>>> to base classes, especially RenderBlock and RenderBox. We may be able to 
>>> help simplify some of that code, especially compared to the old flexbox.
>>> 
>>> (4) Use the old flexbox code as a rough guide, but be aware of its issues, 
>>> e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I 
>>> think some of the bugs you tried to fix already should inform this somewhat.
>>> 
>>> Definitely keep rendering experts in the loop on this and have fun 
>>> implementing!
>>> 
>>> Dave
>>> 
>>> 
 On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
 
> Hi webkit-dev,
> 
> I wanted to let you know that Ojan and I plan to add flexbox layout 
> support to WebCore.  WebCore already supports an older flexbox 
> implementation (display: box), but the new spec is designed to be easier 
> for developers to understand and more powerful.  The old flexbox will 
> still remain in WebCore since none of the CSS properties overlap with the 
> new flexbox spec.  The spec can be found at: 
> http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/)
> 
> This support will be behind the ENABLE_FLEXBOX feature define 
> (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug 
> tracking the feature's development 
> (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature 
> to eventually be enabled by all ports.
> 
> I am ready to setup a buildbot for tracking the compile and flexbox 
> related layout tests.  Should I go ahead and get this added to 
> build.webkit.org's waterfall?
> 
> Thanks,
> Tony
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev