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.
Created attachment 139960 [details] Patch
Why runtime and not build time? We rarely add runtime flags for stuff like this.
Fair question. I used exclusions (bug 83313), shaders (bug 76444) and regions (bug 78525) as currently exposed as my guide.
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.
Comment on attachment 139960 [details] Patch What adam said.
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.
Obsoleted by Bug 86338, use compile time flag instead.
(In reply to comment #7) > Obsoleted by Bug 86338, use compile time flag instead. I meant Bug 87685, oops.