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,
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
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
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.
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
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
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'
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 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
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
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
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.,
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
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.
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
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
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
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
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
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
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,
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
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
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.
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
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
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
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
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
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
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
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
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
+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
34 matches
Mail list logo
