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

[Maciej Stachowiak]

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.

Regards,
Maciej

* - The problem it's trying to solve - determining what parts of the widget react to mouse events normally and which parts can be used to drag the whole widget around -- was solved for touch scrolling on iPhone without having to introduce any new CSS properties. So I wouldn't recommend anyone ever doing anything similar, even if they had a similar problem to solve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130309/46ac95c6/attachment.html>