On Sat, Mar 9, 2013 at 5:02 PM, Maciej Stachowiak <m...@apple.com> wrote:
> > On Mar 8, 2013, at 3:09 PM, Adam Barth <aba...@webkit.org> wrote: > > I've posted a patch to limit the -apple- and -khtml- CSS vendor > prefixes to ENABLE(DASHBOARD_SUPPORT): > > https://bugs.webkit.org/show_bug.cgi?id=111890 > > My understanding is that I also need to add a runtime flag in order to > fully hide these prefixes from the web because Safari and Dashboard > share the same WebCore binary on Mac OS X. > > I found the following entry in Settings.in: > > usesDashboardBackwardCompatibilityMode initial=false, > conditional=DASHBOARD_SUPPORT > > However, some of the paces we need to check this flag do not have easy > access to the Page and therefore have trouble finding the Settings > object. > > Would it be possible to use a global static flag to hide these > prefixes from the web? I don't understand the details of how Safari > and Dashboard share WebCore to know if a global static flag would work > correctly. > > > Safari and DashboardClient (the executable that actually renders widgets) > link the same copy of WebCore on disk, but are separate executables at > runtime. Dashboard backwards compatibility mode is triggered by the > per-WebView _setDashboardBehavior: call which then sets the > usesDashboardBackwardCompatibilityMode setting. It appears that any app > using this SPI either sets it on all WebViews or none. So it's probably > workable to make usesDashboardBackwardCompatibilityMode be effectively a > global setting. > > > Reviewing the pre-installed widgets and a random sampling of other > widgets, I found: > > - The only -apple prefixed property used is -apple-dashboard-region. This > property is seemingly always used with a -apple prefix and never with > -khtml or -webkit. > - The builtin widgets use a -khtml prefix for -khtml-user-select and > -khtml-user-modify. I filed a bug to fix this. Some third-party widgets use > the -khtml prefix on random other properties. > > 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. Adam > On Fri, Mar 1, 2013 at 4:57 PM, Maciej Stachowiak <m...@apple.com> wrote: > > I think we'll want to take these out for Apple ports as soon as we can > check > prevalence in older Apple-specific content (e.g. Dashboard widgets). > > > On Fri, Mar 1, 2013 at 9:11 AM, David Hyatt <hy...@apple.com> wrote: > > I agree with you that this would be pretty terrible. We definitely don't > want developers doing that. > > > On Feb 28, 2013, at 6:02 PM, Adam Barth <aba...@webkit.org> wrote: > I noticed this comment on the Hacker News thread about Paul Irish's > recent blog post: > > ---8<--- > "CSS parsing is the same, though. Slurping up your CSS and turning it > into CSSOM’s pretty standard. Yeah, though Chrome accepts just the > -webkit- prefix whereas Apple and other ports accept legacy prefixes > like -khtml- and -apple-." > > Using this information, can you target Chrome with the webkit- prefix > and Safari with the apple- prefix? Specifying the apple- prefix after > webkit- will ensure that Safari uses that one, right? > --->8--- > > http://news.ycombinator.com/item?id=5302150 > > If developers start using this technique, it might be harder to remove > these prefixes in the future. Chromium's experience removing these > prefixes has been quite positive. We ran into one compatibility > problem on apple.com, which Apple was gracious enough to fix. > > I'd recommend that the rest of the ports disable > ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml- > and -apple- CSS prefixes before it's too late. > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev