[webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Tony Chang]

On Thu, Jun 9, 2011 at 3:55 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Jun 9, 2011, at 3:00 PM, Tony Chang wrote:
>
> On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig <weinig at apple.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110610/777f7c57/attachment.html>