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

[Adam Barth]

On Sat, Mar 9, 2013 at 5:02 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> 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.
>

That sounds like a good plan.  Given that Plans A and B differ only builds
shipped by Apple, I'll leave that choice up to you.  I'm happy to write a
patch that executes the parts of this plan that involve the WebKit codebase.

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/abc94abe/attachment.html>