[webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes

Ryosuke Niwa rniwa at webkit.org
Thu May 3 20:08:20 PDT 2012


By the way, can we add a test for this? For example, we should make
sure document.body.style.khtmlTransform
and document.body.style.appleTransform are undefined on ports that do not
enable legacy prefixes. In fact, shouldn't we be able to override the value
of usesDashboardBackwardCompatibilityMode in DRT somehow?

- Ryosuke

On Thu, May 3, 2012 at 8:01 PM, Adam Barth <abarth at webkit.org> wrote:

> On Thu, May 3, 2012 at 7:57 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> > Resent from the right email address.
> >
> > ---------- Forwarded message ----------
> > From: Ryosuke Niwa <rniwa at berkeley.edu>
> > Date: Thu, May 3, 2012 at 7:49 PM
> > Subject: Re: [webkit-dev] Following up on removing -khtml- and -apple-
> CSS
> > vendor prefixes
> > To: Adam Barth <abarth at webkit.org>
> > Cc: Alexey Proskuryakov <ap at webkit.org>, webkit-dev at lists.webkit.org
> >
> >
> > On Fri, Apr 6, 2012 at 4:27 PM, Adam Barth <abarth at webkit.org> wrote:
> >>
> >> 2012/4/5 Alexey Proskuryakov <ap at webkit.org>:
> >> > 05.04.2012, в 01:08, Adam Barth написал(а):
> >> >
> >> >> Based on this information, I've posted a patch that limits the
> -apple-
> >> >> and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT):
> >> >>
> >> >> https://bugs.webkit.org/show_bug.cgi?id=83256
> >> >>
> >> >> This approach lets ports that wish to remain compatible with
> Dashboard
> >> >> widgets continue to support these prefixes while also letting ports
> >> >> that aren't constrained by dashboard widgets disable them, hopefully
> >> >> lessening their use on the broader web.
> >> >
> >> > Guarding on ENABLE(DASHBOARD_SUPPORT) will make it so that these names
> >> > will be available in Safari on Mac, in every Mac application that uses
> >> > WebKit, but not in Safari on Windows or iOS, and not in other WebKit
> based
> >> > browsers such as Chrome. I don't think that this level of
> fragmentation is
> >> > good.
> >> >
> >> > We normally guard Dashboard-only quirks with
> >> > settings->usesDashboardBackwardCompatibilityMode().
> >>
> >> I attempted to implement this approach in
> >> <https://bugs.webkit.org/attachment.cgi?id=136093&action=prettypatch>,
> >> but I ran into a problem because cssPropertyID is a free function.
> >> Requiring all the callers to pass in a Settings object seems
> >> undesirable.  Note: there are already a number of uses of
> >> ENABLE(DASHBOARD_SUPPORT) in CSSParser.cpp, and none of them check
> >> usesDashboardBackwardCompatibilityMode().
> >
> > I don't think you need to do that. Looking at your latest
> work-in-progress
> > patch, it's probably sufficient to add a guard in CSSParser.cpp. It's
> okay
> > to have those free functions (in fact we DO need them)
> > when ENABLE(DASHBOARD_SUPPORT) is true
> > and usesDashboardBackwardCompatibilityMode() is false since they will
> never
> > be called if the parser rejects values.
>
> Ok.  I'll update the patch.
>
> Thanks!
>
> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120503/671a7306/attachment.html>


More information about the webkit-dev mailing list