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

[Adam Barth]

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

>
> On Mar 9, 2013, at 8:00 PM, Adam Barth <abarth at webkit.org> wrote:
>
> On Sat, Mar 9, 2013 at 5:02 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> 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.
>
>
> I very slightly prefer Plan A. The main downside is having a non-webkit
> prefix in the code with no migration path off of it. But it's a property
> that is not applicable to anything but Dashboard as designed[*]. So maybe
> lack of migration path is OK.
>
> I wasn't sure if anyone else would object to semi-permanently having code
> for a -apple- property, which is why I listed the alternative, which does
> have a migration path.
>

That doesn't seem like a big burden for the project, especially if it's
just one property and not exposed to the web.  The real risk here is web
sites becoming dependent on these prefixes to handle quirks between
CoreAnimation and the Chromium Compositor.

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