Subscribed unsubscribe Subscribe Subscribe

接頭辞が必要な場合とはなにか、また削除はできるのか

WebKit Contributor Meetingの機能廃止&接頭辞セッションから、接頭辞の削除について。

非ブラウザでの接頭辞つき機能

まずAppleのSam Weinigから、WebKitはブラウザ以外にも使われるけれど、ブラウザ以外のWebKit利用例で、接頭辞を省くことが話の通ることなのかと話がでている。

weinig: Mozilla has said that they would like to remove vendor prefixes; they're a browser, though. WebKit is used for browsers and other applications. It's not clear that some rule for when to remove prefixes makes sense for the non-browser case [i.e., you can't just break Mac apps].

WebView使うアプリだったりiBooksのコンテンツはロックイン前提だろうから、ってことだろうか。

MozillaもB2Gのためかデバイス関連のAPIの実装を進めているけれど、どう考えているのかな。今みたくアグレッシブにいくんだろうか。

接頭辞をつけるとき

GoogleのJames Robinsonからどういう時に接頭辞をつけるのか、そして、WebKitの接頭辞とは何を意味するかという話がでている。

jamesr: there's also a question about adding properties. when you're adding something, when do you add a -webkit- prefix? there's also a discussion about what the "webkit" prefix means. sometimes a feature is shipped without community discussion, and that seems possibly damaging.

WebKitコミュニティのなかでとくに議論もなく機能が追加されていることがあるらしい。WebKitは昨年5月から、新しい機能を追加するルールを定めて運用している。Bugzillaにバグを立てて、webkit-devでアナウンスする。そこから議論が始まることもあって、ENABLEフラグつけとこうとか、仕様もあんまりよくないしちょっと連絡取ってよみたいなやりとりが交わされていたりする。

Jamesが言っている、コミュニティでの議論なしに機能が追加されてしまうというのは、このルールに漏れたものなのか、それともこのルールができる前にWebKitに入った機能なのか、それともアナウンスしたけど特に反応ないからlandしちゃった系なのか。

いずれにせよ、どんな機能があって、どんな状態にあるのかが分からないということなのかも。

Jamesの話から、接頭辞の目的を再確認する流れになった。

fishd: is it a cover for an experimental feature, or is it just a way of shipping non-standard behavior.

weinig: traditionally, we've hoped that people would not depend on prefixed properties (not standardized, doesn't work in other browsers). as a second measure, we figured that we'd be able to ship the standardized thing with the proper behavior. a second chance to get the API right, basically. seems weirder in DOM than CSS (no fallback). sometimes we also do this for non-standardized properties that are needed for some particular application, when standards bodies don't seem to be interested or fast enough.

arv: vendor prefixes actually started out this way, when Mozilla wanted to expose things to XUL.

ひとつは、実験的なものにつかう。標準に従っているかをテストする目的で使う。

もうひとつは、標準にないけど、目的があって必要だから追加するものに使う。そもそもベンダー接頭辞が生まれた背景がこれで、もともとXULで使う目的でMozillaに追加されたのがはじまりという話がでている。

CSS2仕様書にもvendor-specific extensionsと、ベンダー固有拡張としての用途してしか書かれていなかったりする。これがどこからか、試験的な実装にもと応用されて、今に至っている。

APIは接頭辞なしで実装されることが多かった

さて、この試験実装に対して接頭辞をつけるというのは、どこで始まったんだろう。CSSは置いとくとして、実はいくつかのAPIは、最初から接頭辞なしで実装されていたりする。

fishd: sometimes we implement new stuff without vendor prefixing, maybe because they're small or uncontroversial.

weinig: querySelectorAll, for example. if all the parties are at the table, it's sometimes ideal.

querySelectorAllが例として挙げられている。なんで接頭辞がなかったのか。仕様が小さく、またベンダー間で議論になるようなものでもなかったからじゃないかという推測がある。

どうなんだろう。使用の大きさや合意形成に関係があるんだろうか。

HTML5系のAPIなんかは、仕様は大きいけれど接頭辞つきのもののほうが少ない(機能ごとで考えるとそうでもないかもしれないけど)。ベンダーの合意がとれてるかについては、WebSQLという例がある。接頭辞に関係あるんだろうか。小さくて合意は取れてても、接頭辞つきで実装されているものだってあるかもしれない。

むしろ、APIに接頭辞がつくっていうプラクティスは、最近になって始まったんじゃないだろうか。

Selectors APIを最初に実装したっぽいのはWebKitで、2007年末になる。こないだBlob.slice()について書いたけど、Blobslice()も、2010年1月に接頭辞なしで実装されている(slice()の問題がでたのでメソッドには接頭辞がつけられたけれど、インターフェースには接頭辞がついていない)。BlobBuilderも同じで2010年6月に接頭辞なしで実装された後、2011年4月に接頭辞がつけられている。

探していたらこんなのもあった。MozillaのJonas SickingがXHRのsendAsBinary(バイナリ送信のためのMozilla拡張メソッド)について、接頭辞つけるべきというバグが立てられたときに、次のように発言している。

Prefixing functions with 'moz' is something we've never done. I'd rather that this was raised with the work group and tried to standardize instead.

このバグは2007年夏に立てられたんだけど、その時点では接頭辞を関数につけるなんてしていなかったらしい。さらにはこれを標準化すればいいのではという立場をとっている。

ただ、すでにsend(ByteArray data)という方法がXHRのほうで提案されていたからか、EditorのAnneも接頭辞をつけるように要請している。ただ、Jonasはこうこう答えている。

I still contend that this is something that no vendor has ever done. The suggested name isn't going to collide with this one, but depends on ES4 features. If other browsers want to support this functionality, but does not yet have an ES4 implementation, they'll likely want to add a function like ours. If we prefix it with 'moz' no other vendor will want to choose the same name and so it'll just make it harder for web authors.

So I'm still going to argue that this is not something we want to do.

どのベンダーもバイナリ送信の仕組みを当時持っていなかったこと、sendAsBinarysendは名前が衝突しているわけではないこと。sendAsBinaryがES4の機能に依存していること。他のベンダーがES4の実装をせずバイナリ送信の機能をつけたい場合、もしMozillaが接頭辞をつけたら他のベンダーが"mozSendAsBinary"という名前で実装するとは考えにくく、Web開発者にも面倒がかかるとさえ述べている。

ES4の機能うんぬんというのはよく分からないけれど、接頭辞をつけると他のベンダーや開発者に面倒がかかるというのは、いま直面している問題だ。そして、名前が衝突しいるわけでもなく、それは既存機能に影響がないならそれでもいいというスタンスは、かなり理にかなっているように思える。

なんで、ここ最近増えてきただけなのかなと。仕様の安定度合い、標準化トラックの状況が不明で、とりあえずつけるようになったってだけではないかな。

試験実装と接頭辞

jamesr: what if no one's saying no, but people are saying "I'm not sure"? should we ship unprefixed and force others to match?

weinig: it's a balancing act

jamesr: there's a case where you have especially a big feature, and you're really not sure the API is right without getting developers to right real code against it. we need some way to ship things like this to developers.

weinig: isn't a custom build the right thing?

jamesr: [example from WebAudio, where we needed to get real feedback with all the features at trunk, not just a custom build with WebAudio enabled]

weinig: was that a success? Mozilla won't implement it as is.

jamesr: but we got feedback, that's the success.

Jamesが、提案している機能について反対はないけれど、よいか悪いかもよく分からないといった反応がある場合はどうするのかという質問をしている。結構おおきなfeature setで、ただAPIのデザインが開発者に受け入れられるかわからないとき、試験的に実装して開発者に試させたいということらしい。WebAudio APIがその例だったらしい。

それはカスタムビルドでやればという質問に、trunkで実装されているすべての機能でテストした結果が欲しかったと。ふうむ。なんでなのかよくわからないけど、まあいいか。

で、Chromeではカスタムビルドではなくて、chrome://flagsにAPIとかを有効にするフラグが追加されて、使う場合はそこをさわってというのが増えている気がする。これだと、明示的に有効にしない限りは使えないし、またBetaとかで無効にされたりすることもあるはずなので、依存したコンテンツが〜ということはあまり言えないだろう。

ただ、これってChromiumプロジェクトのさじ加減でいつ有効にされるかが決まるので、標準化の様子を見て有効にするとか、標準化トラックから外れたから省くとか、そういうことではない。

Web Audio APIChrome 14からStableにも入ったけれど、今のままではMozillaは実装しないと言っているようだ。それで成功なのかという問いに、フィードバックがあったことが成功と答えている。ここでの「フィードバック」は、APIの設計や、実装のバグについて開発者が寄せるもののことだろう。なので、標準化やら接頭辞やらはとくに関係ない気がするんだけどなあ。

WebKitが他ベンダーの接頭辞つき機能を実装する可能性はあるか

[discussion of whether webkit would start supporting, e.g., -ms- prefix; pointed out that it would depend on what happens in the marketplace]

fishd: well, webkit implemented window.external. if it had been called window.msExternal, we probably would have shipped it too.

たとえば -ms- な接頭辞を実装する可能性はという疑問がでて、それはマーケットがどうなるかで決まるのではないかというところで落ち着いたらしい。 window.externalがもしwindow.msExternalだったら、そういう名前でも実装していただろうと。

互換性対応の目的でこれまでも他ベンダーの拡張は実装されている。というかWebブラウザはずっとそうしてきている。

hober: XMLHttpRequest is another example.

XHRとかね。HTML5なんてそんなものが集まっているところだ。

weinig: the example that comes to mind is -moz-outline, which we decided not to implement.

ただすべての機能になるかというと、そうではないようだ。Samは-moz-outline(あったんだ)がWebKitで実装されなかったことを挙げている。接頭辞がついてたのがその理由なのかは、ここでは明らかになっていないけれど、検討されはしたらしい。

そういえば、OperaはSpeed Dialでmetaapple-touch-iconを解釈するようになっている。Web-facingというわけではないけれど、接頭辞ライクなものは既に取り込まれている。

jamesr: well, iOS has shipped webkit-prefixed things that aren't in upstream webkit, and other mobile webkits have had to implement them too.

さて、互換性への取り組みは、他ベンダーというだけではなく、同じエンジンについてもあるとJamesが述べている。AppleSafariに突っ込んだけどWebKitにupstreamしてない機能は、あとあとリバースエンジニアリングして実装するしかなかったと。metaviewportが最たる例かな。-webkit-maskとかも、まだ今はSafariだけだっけか。

これね。どうしたらいいんだろうね。viewportとかはなんでmetaにしたとか評判悪いし、orientationが変わった時にテキストが拡大したりするバグがあるけれど、広まってるからどうしようもない。それをなんとかするのがWebの性なんだろうけれど、「同じ」エンジンでもそうだなんて、やるせないよねえ。

接頭辞の削除に向けて

fishd: we [google] plan to collect data on the usage of CSS on the web, to see which prefixes we could get rid of, how prevalent they are.

fishd: it would be nice if different browsers could move all together, shipping the same set of prefixes, e.g., could we get rid of -webkit-opacity? what would Apple want to know?

weinig: it's hard to say what we would need to know.

hober: if it's used on the web, it's hard to argue that we should remove it and make those pages render worse.

GoogleのDarin Fisherが、Webで使われているCSSにどんなものかあるのかデータを集めるというプランがあると発表。おおお。ただいつやるんだろうね。あとは、Webだけの調査なので、WebViewつかったアプリとかのコードは調べないだろう(できないだろう)。

残さなければいけない機能は、全ベンダーがいっせいに動ければいいねと言っているけれど、無理だろうなあ。6週間のChrome/Firefoxに対して、1年に2回くらいのOpera、毎年6月のSafari、読めないけど1年以上はかかりそうなIEと、リリース間隔を合わせることはきついでしょう。それができるなら標準の実装のタイミングを同じにしてもらったほうが…という話だし。

で、接頭辞つき機能がもう使われているなら、それを削除できるのかという話に戻る。make those pages render worseとあるから、動かないとかそういうのよりも、角丸とかドロップシャドウ系のことを考えているのかな。

グラデーションは-webkit-だけに依存してもらうと困る(白 ― 白で見えなくなることがある)けど、角丸、ドロップシャドウくらいいは、「依存」といえるのかっていうレベルというのもある。

aklein/jamesr: is there any difference between the first and second parts of the discussion? is the vendor prefixed case different than other deprecation? Mozilla is willing to remove prefixed versions.

weinig: we don't want to break content.

jamesr: presumably Mozilla doesn't want to break content either.

fishd: although are clearly cases where they're more willing to break stuff.

Mozillaのポリシーとの違いについて。

dglazkov: over time, you end up with so many prefixes it becomes hard to build webapps.

weinig: but they could just use the non-prefixed version. it's just a burden on WebKit to support both versions.

jamesr: except that the behavior could be different, and developers have to think about it.

接頭辞だらけでWebアプリを作れなくなるんではというDimitri Glazkovの発言。すてき。Good Morning!

ただ、そういう場合は接頭辞なしの機能だけで組めばいいのではという発言も。えええ、ブーブー。でもたしかにそうでもある。けれどそれは、CR待って、テスト待って、実装待って…と、W3Cのプロセスにだいぶ弄ばれることになる。

結局、実装者 ― 開発者 ― 標準化団体間でのボールのぶつけあいになってしまう。それは避けたいよ。あとこうなると、接頭辞の有無やらベンダー拡張やら標準やら、試験実装やらちゃんとした実装やら、そういうものが吹っ飛んでしまうんだ。


接頭辞のついた機能が問題になっている認識はあるものの、じゃあ接頭辞をなくそうとか、接頭辞を省いていこうというアクションは、このミーティングでは見られなかった。

ただこれ書いて寝かせてる間(先週)にちょっと動きがあったので、それはまた別途書く。