[webkit-dev] -khtml- and -apple- CSS prefixes

[Maciej Stachowiak]

On Mar 8, 2013, at 3:09 PM, Adam Barth <abarth at webkit.org> wrote:

> I've posted a patch to limit the -apple- and -khtml- CSS vendor
> prefixes to ENABLE(DASHBOARD_SUPPORT):
> 
> https://bugs.webkit.org/show_bug.cgi?id=111890
> 
> My understanding is that I also need to add a runtime flag in order to
> fully hide these prefixes from the web because Safari and Dashboard
> share the same WebCore binary on Mac OS X.
> 
> I found the following entry in Settings.in:
> 
> usesDashboardBackwardCompatibilityMode initial=false,
> conditional=DASHBOARD_SUPPORT
> 
> However, some of the paces we need to check this flag do not have easy
> access to the Page and therefore have trouble finding the Settings
> object.
> 
> Would it be possible to use a global static flag to hide these
> prefixes from the web?  I don't understand the details of how Safari
> and Dashboard share WebCore to know if a global static flag would work
> correctly.

Safari and DashboardClient (the executable that actually renders widgets) link the same copy of WebCore on disk, but are separate executables at runtime. Dashboard backwards compatibility mode is triggered by the per-WebView _setDashboardBehavior: call which then sets the usesDashboardBackwardCompatibilityMode setting. It appears that any app using this SPI either sets it on all WebViews or none. So it's probably workable to make usesDashboardBackwardCompatibilityMode be effectively a global setting.


Reviewing the pre-installed widgets and a random sampling of other widgets, I found:

- The only -apple prefixed property used is -apple-dashboard-region. This property is seemingly always used with a -apple prefix and never with -khtml or -webkit.
- The builtin widgets use a -khtml prefix for -khtml-user-select and -khtml-user-modify. I filed a bug to fix this. Some third-party widgets use the -khtml prefix on random other properties.

My recommendation would be:

* Do one of the following two options:
    -  Plan A: Rename -webkit-dashboard-region to -apple-dashboard-region in CSSPropertyNames.in (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway).
    -  Plan B: Support -apple- as a prefix alias only for -webkit-dashboard-region (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway).
* Remove all other support for the -apple- prefix as a synonym for -webkit-
* Make -khtml- prefix alias support only available if ENABLE_DASHBOARD_SUPPORT is on, and also runtime-conditional based on usesDashboardBackwardCompatibilityMode having ever been set for any Settings object.


Depending on whether Plan A or Plan B is preferred, I can file a bug to replace -apple-dashboard-region with -webkit-dashboard-region in the preinstalled Dashboard widgets.

Regards,
Maciej


> 
> Thanks,
> Adam
> 
> 
> On Fri, Mar 1, 2013 at 4:57 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> I think we'll want to take these out for Apple ports as soon as we can check
>> prevalence in older Apple-specific content (e.g. Dashboard widgets).
> 
> On Fri, Mar 1, 2013 at 9:11 AM, David Hyatt <hyatt at apple.com> wrote:
>> I agree with you that this would be pretty terrible. We definitely don't want developers doing that.
> 
>> On Feb 28, 2013, at 6:02 PM, Adam Barth <abarth at webkit.org> wrote:
>> I noticed this comment on the Hacker News thread about Paul Irish's
>> recent blog post:
>> 
>> ---8<---
>> "CSS parsing is the same, though. Slurping up your CSS and turning it
>> into CSSOM’s pretty standard. Yeah, though Chrome accepts just the
>> -webkit- prefix whereas Apple and other ports accept legacy prefixes
>> like -khtml- and -apple-."
>> 
>> Using this information, can you target Chrome with the webkit- prefix
>> and Safari with the apple- prefix? Specifying the apple- prefix after
>> webkit- will ensure that Safari uses that one, right?
>> --->8---
>> 
>> http://news.ycombinator.com/item?id=5302150
>> 
>> If developers start using this technique, it might be harder to remove
>> these prefixes in the future.  Chromium's experience removing these
>> prefixes has been quite positive.  We ran into one compatibility
>> problem on apple.com, which Apple was gracious enough to fix.
>> 
>> I'd recommend that the rest of the ports disable
>> ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml-
>> and -apple- CSS prefixes before it's too late.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130309/b6ca4d09/attachment.html>