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 <aba...@webkit.org> wrote: > On Thu, May 3, 2012 at 7:57 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > > Resent from the right email address. > > > > ---------- Forwarded message ---------- > > From: Ryosuke Niwa <rn...@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 <aba...@webkit.org> > > Cc: Alexey Proskuryakov <a...@webkit.org>, webkit-dev@lists.webkit.org > > > > > > On Fri, Apr 6, 2012 at 4:27 PM, Adam Barth <aba...@webkit.org> wrote: > >> > >> 2012/4/5 Alexey Proskuryakov <a...@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 >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
