さよなら -apple- に -khtml-
3月半ばに書いてそのままになってた下書きを発見。
なんで放置してたんだっけ……引用多すぎるからかな。まあいい。
WebKitにこんな変更が加わった。
先日Paulが公開した “WebKit for Developers” （日本語訳）を読んだHacker Newsの読者があることに気がついた。
"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?
「Chromeでは -apple-, -khtml- が無効にされてる（って書いてある）から、これでChromeとそれ以外のWebKitブラウザを振り分けられるんじゃないか」と。
たいへん賢くていらっしゃる。
これを見たAdam Barthがwebkit-devに共有。
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.
テクニックとして広まったらどうにもならんと。Chromeで無効にしているけどほとんど問題ないし、他のportでも LEGACY_CSS_VENDOR_PREFIXES を無効にしようと。
これにAppleのDavid Hyatt, Maciej Stachowiakも賛同して、実装に関する議論をちょっと踏まえてパッチがチェックインされましたというお話。
まだ他にもすることがあるようだけれど、これで、たぶん次期バージョンのSafariから -apple-, -khtml- 接頭辞がWebで使えなくなる。Webも感謝するってさ。
さて、これ、息の長いプロジェクトだったりする。始まりは2010年7月、当時まだGooglerでなかったPeter Beverlooがwebkit-devに投げたメールから。
While going through WebCore for some CSS research I'm currently doing, I came across a piece of code[1] which translates all "-khtml-" and "-apple-" vendor-prefixes to "-webkit-". This effectively means "-apple-transform" and "-khtml-transform" can both be used instead of "-webkit-transform". I am unaware of the rationales behind the apple vendor-prefix, but I'd like to propose removing support for the KHTML-prefix.
My main argument for this is that WebKit and KHTML are, in my opinion, two separate engines by two separate vendors. The port occurred eight years ago, and code in both projects has changed significantly ever since. [...]
I understand the history of supporting -khtml-, and have heard from the KHTML project that they implement the -webkit- prefix as well. However, considering that WebKit has grown significantly in the past few years and that all code changes basically made KHTML and WebKit two individual rendering engines, with individual CSS support, I believe it would be appropriate for support to be dropped.
当時の実装では、-khtml-, -apple- がついたプロパティが -webkit- の同名プロパティにマップされていたらしい。BeverlooはWebKitの経緯はわかるが、KHTMLとWebKitはもはや別のエンジンなので -khtml- の削除を提案している。
これに対するMaciejの返答は消極的だった。
The reason for these is historical. Originally, we didn't use a separate vendor prefix for WebKit, just -khtml. Later we changed to -apple. Eventually we realized WebKit would not be an Apple-specific project forever, so we switched to -webkit. The main risk to removing the old prefixes is that some older WebKit-specific content authored against them will break. I'm not sure the code cleanup benefits outweigh the risk of breaking content.
If we want to phase out support for these older prefixes, what I'd propose as a first step is supporting the legacy prefixes for old properties but not for any new ones.
もともとWebKitでは -khtml- を使っていて、その後 -apple- を使い出した。ただその後Apple以外の手も加わり始めたので -webkit- になったと。古い接頭辞を削除すると、古いWebKitに依存したコンテンツが壊れてしまうリスクがあるので、クリーンアップがそれに勝る益を得られるかはわからないと。
ただ、BeverlooはWebKitには接頭辞ついたものがただでさえ多いのに、さらにエイリアスもあると3倍になってしまうことを懸念していると返答。そのうえで、-khtml-, -apple- をマップするプロパティを特定の者に限定すればと再提案。
Right now WebKit has by far the most prefixed elements[1], a significant part of which have not been standardized/drafted yet. Keeping the translation for all properties active practically triples the amount of supported vendor-specific CSS extensions, which cannot be desirable. I'm not opposed to the idea of limiting the supported properties for these prefixes to a certain subset, but my preference would be to only support behavioral properties as "-webkit-binding", "-webkit-font-smoothing", "-webkit-highlight" and "-webkit-user-(drag|modify|select)". In the same piece of code, prefixed versions of border-radixes and opacity are still supported as well. Although I think the latter of which could be removed as well, considering Safari 1.1 got released in 2003.
そこへDavid HyattがMaciejの発言を一部訂正する形で登場。
> The reason for these is historical. Originally, we didn't use a separate vendor prefix for WebKit, just -khtml. Later we changed to -apple.
That's not quite right. Originally we just had -khtml- for CSS extensions, and then we used -apple- for features that we were Apple-specific, i.e., that we knew nobody else would care about. Those features include Dashboard regions and Safari RSS line clamping). Eventually we just decided to merge both into a common prefix, but we wanted to keep the old property names working for compatibility. It was convenient to just map both to -webkit- rather than actually checking the specific property names and only supporting either -khtml- or -apple-.
My recommendation would be as follows:
-apple- な機能は、DashboardやSafari RSSなどApple固有の機能に使う機能に用いていたけれど、後にそれが -webkit- に一本化したときに互換性のため古いものを残したと。そのときに、どのプロパティかをチェックするよりもエイリアスにしたほうが楽だったとのこと。
で、Hyattは-khtml- の削除と -apple- を -apple-dashboard-region, -apple-line-clampのみに限定しようと提案。
これによりパッチが作られたのだけれど、残念なことにDashboardウィジェットに影響がありすぎたのでダメだった。
それから2年弱経った2012年4月、Adam BarthがDashboardウィジェットにだけ古い接頭辞を有効にするようパッチを携えwebkit-devに登場。
In July 2010, there was a thread on webkit-dev about removing support for the -khtml- and -apple- vendor prefixes:
https://lists.webkit.org/pipermail/webkit-dev/2010-July/013519.html
At the time, we tried an approach recommended by David Hyatt
<https://lists.webkit.org/pipermail/webkit-dev/2010-July/013536.html>,
but that approach appears to have been too agressive in that it broke a number of Dashboard widgets:https://bugs.webkit.org/show_bug.cgi?id=42093#c29
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.
I welcome any thoughts the list has on this topic.
互換性について軽く心配する声があったので、AdamはChromeで無効にしてみて問題がないか試してみようと提案。
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 release blocking bugs.
結果、Chromium portでのみ -khtml-, -apple- が無効にされた。
それから半年近く経った2012年9月、Adamが進捗報告をwebkit-devに。まめだ。Adam何にでも関わってるしほんとすごい。
As discussed in
<http://lists.webkit.org/pipermail/webkit-dev/2012-April/020183.html>,
Chromium experimented with removing the -khtml- and -apple- vendor prefixes from CSS properties. We broke one Apple web page, which Apple was kind enough to fix. Other than that, we have encountered no problems.
曰く、AppleのWebサイト1ページに影響があったものの、それ以外に問題はなかったと。よかったよかった。
ただその後webkit-devでは特になく、先日のメールにて復活、ようやく動いたと。
接頭辞が無効にされるのは時間がかかるねえ。ただ、以前よりは「そんなの無理だ」感はなくなってきている（CSS TTAやGradientsは無理だろうけれど）。調査ができるようになって、それによって削ってもいいだろうという判断基準ができたというのが大きい。あまりにhalf-bakedな機能はビルドフラグやランタイムフラグに隠れていたりもするし、接頭辞問題への取り組みはだいぶ前進したんじゃないだろうか。解決するかは、また別の問題だけれど。
