Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com 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/http://dev.w3.org/csswg/css3-flexbox/#negative-flexibility ) 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
Err, ENABLE_NEW_FLEXBOX. On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang t...@chromium.org wrote: Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com 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/http://dev.w3.org/csswg/css3-flexbox/#negative-flexibility ) 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
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 wei...@apple.com 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
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 t...@chromium.org wrote: Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com 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
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 simon.fra...@apple.comwrote: 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 t...@chromium.org wrote: Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com 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/http://dev.w3.org/csswg/css3-flexbox/#negative-flexibility ) 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
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 t...@chromium.org wrote: Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com 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
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 simon.fra...@apple.com 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 t...@chromium.org wrote: Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com 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
On Jun 13, 2011, at 10:52 AM, Darin Fisher wrote: On Mon, Jun 13, 2011 at 10:50 AM, Simon Fraser simon.fra...@apple.com 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
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 simon.fra...@apple.com 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 t...@chromium.org wrote: Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com 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
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
On Thu, Jun 9, 2011 at 3:55 PM, Maciej Stachowiak m...@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 wei...@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. ___ 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
On Fri, Jun 10, 2011 at 10:14 AM, Tony Chang t...@chromium.org wrote: On Thu, Jun 9, 2011 at 3:55 PM, Maciej Stachowiak m...@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 wei...@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. 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
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
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
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
On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig wei...@apple.com 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/http://dev.w3.org/csswg/css3-flexbox/#negative-flexibility ) 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
On Jun 9, 2011, at 3:00 PM, Tony Chang wrote: On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig wei...@apple.com 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
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 t...@chromium.org 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
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 aba...@webkit.org 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 t...@chromium.org 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
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 o...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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
Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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
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 da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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
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 da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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
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 o...@chromium.org 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 da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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
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 t...@chromium.org 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 aba...@webkit.org 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 o...@chromium.org 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 da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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
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 aba...@webkit.org 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 t...@chromium.org 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 aba...@webkit.org 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 o...@chromium.org 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 da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher da...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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 aba...@webkit.org 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 o...@chromium.org 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 da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org 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 jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher da...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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 aba...@webkit.org 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 o...@chromium.org 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 da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org 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 jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher da...@chromium.org 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 aba...@webkit.org 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 t...@chromium.org 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 aba...@webkit.org 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 o...@chromium.org 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 da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org 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 o...@chromium.org 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
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
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 dpra...@chromium.org wrote: On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org 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
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 da...@chromium.org 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 dpra...@chromium.org wrote: On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org 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
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 da...@chromium.org 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 dpra...@chromium.org wrote: On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org 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
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 aba...@webkit.org 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 da...@chromium.org 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 dpra...@chromium.org wrote: On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org 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
+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 da...@chromium.org 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 aba...@webkit.org 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 da...@chromium.org 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 dpra...@chromium.org wrote: On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org 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
