Bug 85457 – Add WebCore::InternalSettings::setCSSImageResolutionEnabled

• Component: Tools / Tests
• Status: RESOLVED WONTFIX

[David Barr]

The css3-images module is at candidate recommendation.
http://www.w3.org/TR/2012/CR-css3-images-20120417/#image-resolution

I propose to introduce image-resolution, initially behind a runtime feature flag.

Advertised on webkit-dev:
http://thread.gmane.org/gmane.os.opendarwin.webkit.devel/20505

Prior to changing behaviour, add WebCore::InternalSettings::setCSSImageResolutionEnabled
and WebCore::RuntimeEnabledFeatures::setCSSImageResolutionEnabled.

[David Barr]

Created attachment 139960 [details]
Patch

[Simon Fraser (smfr)]

Why runtime and not build time? We rarely add runtime flags for stuff like this.

[David Barr]

Fair question. I used exclusions (bug 83313), shaders (bug 76444) and regions (bug 78525) as currently exposed as my guide.

[Adam Barth]

David, we tend to use EnabledAtRuntime when Chrome wants to enable or disable the feature with a command line argument.  Typically for CSS features, we just use a compile switch.  Exclusions, Shaders, and Regions are the exception rather than the norm.

[Simon Fraser (smfr)]

Comment on attachment 139960 [details]
Patch

What adam said.

[David Barr]

The motivation for adding a runtime flag rather than build time is to enable testing on the bots of the feature prior to flipping the flag. This also assists incremental development until the feature is fully baked. With a runtime flag, it can be known the the feature compiles and passes tests on all ports without exposing it to the wild web. As the feature is part of a Candidate Recommendation, it is not a moving target.

In short, using a runtime flag rather than a build flag allows the cost of deciding to flip the flag to be amortized over the development period.

[David Barr]

Obsoleted by Bug 86338, use compile time flag instead.

[David Barr]

(In reply to comment #7)
> Obsoleted by Bug 86338, use compile time flag instead.

I meant Bug 87685, oops.