One option is to start evaluating the compat implications by disabling the prefixes in Chrome. If we have a positive experience we can disable them in more ports/configurations over time, hopefully arriving where you suggest while avoiding the stress of rel On Apr 5, 2012 10:14 AM, "Alexey Proskuryakov" <a...@webkit.org> wrote:
> > 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(). > > Due to high potential of site breakage, this seems worth a separate > setting with pre-made plumbing for site-specific quirks, so that ports > seeing release blocking regressions on important sites wouldn't have to > undo this change entirely. > > - WBR, Alexey Proskuryakov > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
