2012-05-16

HTMLのsrcset属性

HTML

まだfirst draftなので変わるかもしれないけれど、そういうのが入った。

-webkit-image-setと似たような感じ。URL＋デスクリプタのセット（image candidate stringと呼ぶらしい）を属性に書く。

今のところデスクリプタは3つ。viewportの最大幅を意味する w, 最大高を意味する h, 最高デバイスピクセル比を表す xだそう。wとhは-webkit-image-setにはなかったような。提案してもCSSWGは「メディアクエリーでやれ」って言いそうだけれど。

Retina display対応だけなら、たぶんこんな感じ。

<img src="image.png" srcset="image2x.png 2x" ...>

解像度やdpx比ごとにいろいろしたい場合は、wとかhを使う。

<img src="photo.jpg"
     srcset="photo-thumbnail.jpg 300w, photo2x.jpg 2x" ...>

幅が300px以下のときにはサムネイルが使われて、Retina displayのときはそれ用が出てくる。

眠いのであとで書きたそう。

2012-05-10

WebKitBlobBuilderが削除

Blobコンストラクタがあるから要らないよということで、deprecatedとされたBlobBuilder。MozillaもFirefox 14からMozBlobBuilderを使うとコンソールにwarningが出ることは、前に書いた。

さて、WebKitBlobBuilderはどうか。これまでの接頭辞の議論を考えるとちょっと難しいよね……とおもったら削除された。

このバグが投げられた時点でWebKitはまだBlobコンストラクタをサポートしていなかったので、まずコンストラクタが実装され、それで削除となった。ただ、WebKitBlobBuilderは既にChromeに載っているので、そのまま削除だとちょっとまずい。ということでENABLE_LEGACY_WEBKIT_BLOB_BUILDERなるフラグが用意された

このフラグ、Safari (Mac port)では有効にされないらしい。というのもSafariのリリースバージョンではWebKitBlobBuilderが実装されていなかったから（5.2のPreviewにはあるのかもしれないけれど）。他のportでは今のところ有効なので、Safariとそれ以外でWebKitBlobBuilderが使えたり使えなかったりということになる。Chromeが削除できるかは微妙な気はする。

IE10でもコンストラクタが実装される？

あまり気にしている人はいない気がして残念だけれど、MSBlobBuilderというのもある。来月にWindows 8のRelease PreviewなんてタイミングでBlobコンストラクタがサポートされて、MSBlobBuilderが削除されるのだろうか。難しいんじゃないかな。

と思ったら、MozillaのバグでJonas Sickingがこんな発言を。仕様でArrayBufferのかわりにArrayBufferViewをとるようになったので、その修正を促すバグなんだけど、IE10の話が。

Based on conversations with microsoft people, apparently IE10 is going ship with the Blob constructor taking ArrayBuffers (it's too late in their cycle to change).

Microsoftのひとによると、ArrayBufferViewへの修正は間に合わないらしいけれど、Blobコンストラクタはサポートされるらしい。MSBlobBuilderは削除されるんだろうか。いくつかのデモで使われているし、どうなのかね。

Blob()でOK

で、Operaなんだけど、BlobBuilderはまだサポートしてないので問題ない。コンストラクタの対応、slice()の変更も合わせてそのうち出してくるんじゃないかと予想。

となると、古いChromeやFirefoxをサポートしなくていいなら、今後はコンストラクタを使うようにすればよさそう。ただタイミングが悪いとwebkitSlice()の検出をしないといけなくなるという……

2012-05-08

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

WebKit Safari Chrome

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()について書いたけど、Blobもslice()も、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.

どのベンダーもバイナリ送信の仕組みを当時持っていなかったこと、sendAsBinaryとsendは名前が衝突しているわけではないこと。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 APIはChrome 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でmetaのapple-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が述べている。AppleがSafariに突っ込んだけどWebKitにupstreamしてない機能は、あとあとリバースエンジニアリングして実装するしかなかったと。metaのviewportが最たる例かな。-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のプロセスにだいぶ弄ばれることになる。

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

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

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

2012-04-28

-webkit-な機能を一部サポートしたOpera Mobile Emulatorの実験ビルドが公開

Opera WebKit

WebKit Contributor Meetingの後編書いてたら、Opera Mobile Emulatorの実験ビルドが公開された。このビルドでは試験的に、一部の-webkit-なCSSの機能をエイリアスとしてサポートしている。

エイリアスの仕方は、前回のF2Fで決定したものに沿っている。ざっくりとしたルールはこちら。

  • エイリアスは接頭辞の有無に関係なく利用できる。
  • ブラウザがひとつのプロパティに対し複数の構文をサポートするとき、それらは継承においてエイリアスとして扱われる。最後にきたものが適用される。
  • OMにおいては、どの構文が指定されたか、そして適用されたかにかかわらず、すべてのエイリアスが現れる。
  • このエイリアスはCSS WGが承認したプロパティに対し適用される。また、接頭辞つきの構文をエイリアスとしてブラウザが扱うこともできる。
  • 値に対してエイリアスがサポートされた時、OMが返すものは製作者が指定したものになる。
  • メディアクエリーの特性においても、製作者が指定したものを返す。

Opera Mobile Emulatorがエイリアスとしてサポートしているプロパティは次。

-o--webkit-
box-shadow -webkit-box-shadow
-o-transform -webkit-transform
-o-transform-origin -webkit-transform-origin
border-radius -webkit-border-radius
border-top-left-radius -webkit-border-top-left-radius
border-top-right-radius -webkit-border-top-right-radius
border-bottom-left-radius -webkit-border-bottom-left-radius
border-bottom-right-radius -webkit-border-bottom-right-radius
-o-transition -webkit-transition
-o-transition-delay -webkit-transition-delay
-o-transition-duration -webkit-transition-duration
-o-transition-property -webkit-transition-property
-o-transition-timing-function -webkit-transition-timing-function

プロパティの数は最小限にしているね。Animationsがないけれど、これはOpera 12以降になるからだろう。

値については、-webkit-linear-gradientが-o-linear-gradientのエイリアスとして扱われている。radial-gradientはそこまで使われていないんだろうか。それともまだOperaがサポートしていないだけかな。

CSSOMについても、webkitTransitionEndがoTransitionEndにマップされていると。ただし両方のリスナが登録されている場合、fireされるのはoTransitionEventのみらしい。

エイリアスなので、「今後は-webkit-のみをサポートする」なんてことではない。-webkit-fooという名前で標準になったら、話は変わってくるかもしれないけれど、今のところそういう話もないし。

Webが壊れるやら失望したとかいうコメントが随所で見られたけれど、MozillaもMicrosoftもそういう段階にあるし、WebKitだってそういう事態に直面すれば実装することはあり得るだろう（むしろ率先してやりそうな気もする）。

ナンセンスさは否めない。どのベンダーだって、CSS WGだってそう思っている。ただ、すでにある接頭辞つきの機能については、啓蒙活動やら継続的な更新やらもした上で、こういう対応をしていくしかないんだろう。

それを食い止めるためには、接頭辞の仕組みをやめることがひとつ。あと、ベンダーとベンダー、ベンダーと標準化団体のコミュニケーションをもっとスムーズにすること。そういうことをしないといけないんじゃあないかなあ。

ベンダー、標準化団体、Web開発者をそれぞれなじっても、何も進まんよ。

2012-04-26

すでにある機能の廃止は難しい

WebKit

OperaがWebKitの接頭辞を…というのは、まあとりあえずは中の人からの報告を待っておくとして。

さて、WebKitプロジェクトは接頭辞についてどう考えているんだろうか。先週やっていたWebKit Contributor Meetingで接頭辞などについて取り上げたセッションがあったらしい。

機能の廃止、接頭辞の削除と、ふたつトピックがあったので、ふたつに分けて書く。

機能は廃止できるのか

この前WebKitは接頭辞をエイリアスとして残す方針があると書いた。もう少し広げてかくと、既存のコンテンツが依存している機能は、接頭辞の有無にかかわらず、削除せず残しておく感じだ。カジュアルに使われやすいCSSの機能は、たぶん削除されることは今後もほぼないと考えている。

けれど、APIについては実装を削除している場合もある。event.layerX/layerYがそのひとつで、昨年削除された。

コンソールにwarningが出るようになっている。Chrome 16以降あたりで反映されたので、見ている人も多いんじゃないかな。

なぜ「見ている人が多い」のかというと、ちょっと前までjQueryになんとなく入っていたから。Chromeでwarningがでまくるというバグが立てられて、その結果jQuery 1.7でも削除された。

layerX/Y are not used internally and we do not normalize them. They are only present on the event object where supported, so anyone actually using them would have to check if they were undefined first anyway.

内部で使ってもいないし、ノーマライズもしてない。依存したコードもそれほど多くないだろうというのが、削除の理由。ただ、jQueryのアップデートがされないなんて日常茶飯事だ。それでなんとかしろよ的なissueもあがっている。

そんな中IE9で互換性のため実装されたという話もあって、削除すべき（だった）のか、むしろもう標準化しないといけないんじゃ…的なことになった。

Warningが出なかったらここまで言われることもなかったのかなとも思う。けれど、一度世に出てしまった実装を削除するのはなかなか大変だ。MozillaもFirefox 7でimage.x/yを削除したんだけど、互換性に問題があることが分かって昨日バックアウトされ、HTMLでの標準化を求めるバグが立てられた。

うまくいってそうな例もある。ミーティング内ではsync XHRでのArrayBufferサポートについて、削除したらどこかのゲームフレームワークに影響を与えたものの、フレームワーク開発側がなんとかしたので収まったという話がでていた。使っている人がほとんどおらず、また（結果的に）協力的な対応が行われればうまくいくということなんだろう。ただ、こういうケースは稀だろう。影響をほとんど出さずにうまく削除できるなんて奇跡に近い。

Blob.slice()は成功例か？

うまくいった例として、Blob.slice()も挙げられている。もともとBlob.slice()はWebKitやMozilla, Operaで接頭辞なしで実装されたんだけど、そのあと、String.slice()などとセマンティクスが違うということが分かった。お粗末ではあるんだけど、仕方ないから変えようということで、Blob.webkitSlice()/Blob.mozSlice()と接頭辞つきのメソッドに改名された。Chromeでは12あたりから、FirefoxはFx5から反映されている。

Operaはそのままなんだけど、WebKitやMozillaではそのメソッドが1年近くも存在していない。なので、古いBlob.slice()に依存するコードがある場合、なにか問題がでてくるはず。ただ、とくになかったようだ。

今年2月になってOperaが、接頭辞なしで通していた古い実装を新しいものにする、でも接頭辞をつけて実装する必要性は（上記の理由から）たぶんないので、接頭辞を削除してくれとMozilla, WebKitに報告した。

Mozillaは速攻でmozSlice()から接頭辞を削除して、これ、Firefox 13で反映予定なのだけれど、どうやらmozSlice()に依存したコードがあったらしくバグが立てられている。

なのでこれ、古いBlob.slice()への依存回避はうまくいったのかもしれない。ただ、mozSlice()/webKitSlice()でへの依存という新しい問題を生み出している。Blob.webkitSlice()は接頭辞取れよってバグも放置されっぱなので、これからMozillaのように問題が起こる可能性がある。なので、接頭辞の削除ではなく、エイリアスとして残すんじゃないかな。

廃止の意義は？

機能や接頭辞の削除にどういう意義があるのか。こんなくだりがある。

weinig: aren't gradients a success story? we were able to ship the new syntax without breaking anything. arv: but we haven't removed the old syntax.

weinig: but is that really hurting us?

jamesr: who is "us" here? the web or webkit developers?

weinig: webkit developers.

WebKit開発者にとって、機能を削除しないことの悪影響はあまりないのかな。削除して動かなくなったらクレームが来るだろうし、残すことに利があるケースが多いのかも。Web開発者にとっても、うまく残せるのなら、今まで使えてたものが急に使えなくなるよりは、いいだろう。ただ、接頭辞によって特定の環境固有にされてしまってるので厄介なことになっている。

WebSQLを例に、メンテがされていない機能についてはどうなのかという質問もでている。（WebSQLはメンテがされているらしいので、適当な例ではないようだけれど、）広く使われている機能なら、長く残り続けるだろうと。Transition/Animationについても、たとえ他のブラウザが接頭辞を省いたとしても、これまでを考えると接頭辞のwarningさえ出せないだろうとも書かれている。

その後に、省きたくても使われていて省けないものには、よりよい代替が出るしかないとある。Mutation EventsやlocalStorageがそれに当たるのかな。よりよい代替が出たとしても、それの普及を待って消すというのには大変な時間がかかるだろう。

既存のコンテンツを大事にするなら、機能の廃止は接頭辞の有無や標準非標準に関係なく難しい。廃止だけじゃなくて追加や変更も難しいことがあるんだけど、それはそれで別に書こうかな。

2012-04-24

HTML5のeditor募集とHTML.nextにむけたHTML WGのプラン

W3C HTML

HTML WG co-chairのMaciej Stachowiakが、HTML5のeditorを募集するというメールを出している。

HTML5のファイナライズ、つまり勧告をみる時期にきている。一方で、「ポストHTML5」な機能についても考えはじめなければならない。新しい機能については、既にHixieがもういろいろやり始めていて、その中でHTML5の勧告に向けた作業については誰か引き継いでくれないかと依頼があったと。そういうわけで彼がeditorをつとめていたHTML5仕様とCanvas 2D Context仕様のeditorを募集すると。

HixieにW3C版の作業をする気はもうないので、こういうことになったんだろう。彼がWebAppsでeditorをつとめてる仕様（Workersやらいろいろ）の更新は既に人に任せていたりもするし、それをHTML WGでもやってくれということ。ただ、HTML WGの場合は仕様が大きく、まだいろいろissueもある。そこらへんも対応するとなると、ほぼ仕様の更新作業だけなWebAppsとはわけが違う。

さて、MaciejのメールではHTML.nextに向けた動きについても触れている。HTML WGの変更としてあげられた6点をざっくり訳す。

  • W3CはHTML5仕様とCanvas 2D Context仕様の勧告に向け、その作業を担当するeditorを募集する。期間は30日をみている。
  • 将来的にHTML WGの成果物となるもののインプットとなりうる提案も歓迎する。提案はCommunity Group, HTML WG内のTask Force, HTML WG内などを問わない。
  • Ian (Hickson) はWHATWG HTML仕様の編集を続ける。WHATWG HTML仕様も前述した提案のひとつと見込んでいる。
  • 勧告に向けた作業をするeditorとHTML.nextへの提案の作成者は、不整合などを起こさないよう共同で作業にあたることが望まれるが、各仕様の変更は直接行なってよい。
  • HTML5仕様と並行してHTML.nextの作業を開始できるように、W3CはHTML WGのcharterを延長する手続きを始めた。HTML WGがrecharterされたら、HTML.nextに対する提案の評価および、HTML.nextのeditorを探しはじめる。
  • HTML5の作業と同様、W3CとWHATWGは今後のWebに対し適切な機能を策定するために協力していく。

Charterの延長なのかrecharterなのか

気になっているのが、5番目のHTML WGのcharterに関するもの。一文目にはcharterを延長とあるんだけど、その次の文はrecharterについて説明している。

延長とrecharterはどう違うかというと、めんどさが違う。Charterの延長は、DirectorがAdvisory Committeeに報告するくらいで、そんなに大したことはないはず。実際に去年延長したけれど、とくに混乱もなかったし。

ただこれがrecharterとなると、めんどくなる。Recharterは、まず新しいcharterの作成にはじまり、次にACのレビューを通し、そして新しいWGとして再出発するというステップを踏む。今まで参加してたひとも全部解除されて、また参加の手続きをふまなければいけない。

Charterの作成は、いまのcharterをベースにはするんだろうけれど、HTML.nextが入るのであれば、どういった機能が検討されているか、そのおおよその範囲を考えて含めなければいけない。言及のない機能についてはそのWGで作業できなかったりするので、多くの機能を入れたいのであればいろいろ考えることになる。

ただ、機能がありすぎたりするとWebAppsみたいにカオスになる。あと、特定の範囲について、どこかのMemberが意見を言う可能性もある。WebEvents WG, Geolocation WG, Notification WGみたく、どこかの反対があると小さなWGにしかできず、さらにTouch Events vs. Appleみたいなことも起こりかねない。

ACのレビューについては他にも、Decision Policyやワークモードに関して意見が出るかもしれない。アクセシビリティ界隈から強い声もでると思う。そういうのを解決して、charterのdraftを更新して、またレビューにかけて…と、途方もなく長くなるかもしれない。

なのでrecharterなんて、本当にできるのかって気がするんだけど、するのかね。ふぁいと！

WHATWGがCommunity Groupに

W3CとWHATWGは引き続き協力、とあるけれど、WHATWGをCommunity Groupにする動きが始まっている。

WHATWGについては、特許ポリシーが弱いという批判がある。詳しくは知らないけれど、こうしたポリシー関連の不都合で、企業としての参加を阻んでいるケースがある。代表的なのがMicrosoftで、こないだも、innerHTMLやinsertAdjacentHTML()がDOM Parsing & Serialization仕様に移動したとき、その仕様がW3Cでホストされていないのでissueになった。彼らが発明したものだから、特許情報の開示とかそういうのはおいといても、ポリシーは必要なのかなと。

あとは、仕様書のライセンスもちょくちょく問題になっている。こちらも詳しく知らないんだけれど、今のW3C Licenseだとforkはおろか教育目的の利用なんかもできないという話があったりする。それは実情に即してないし、柔軟性もない。さっきのDOM P&SやDOM4 (のED)やらがCC0を採用しているのは、そうしたライセンスへの反発と、オープン標準を強く意識してるところがある。

WHATWGをCommunity Groupとして位置づけることで、ポリシーとライセンスが解決できる。
というわけで早速できた。早いなあ。

コミュニケーションルールは引き続きWHATWGのものを使って、仕様の公開に関してはCGを利用ということらしい。他のCGでも似たようなことをやってるので、そんな新しいわけではない。こういうバックドアちっくな流れが広まっているのを見ると、W3C Processの改訂もうちょっと急いだほうがいいんではと思ってしまう。

結局どうなんのよ

長くなってしまった。

HTML5についてはそう極端に変わる（WHATWG HTMLから完全に独立するとか、W3Cオリジナルの機能が入るとか）はないかなあと。Maciejのメールのフォローアップのひとつとして公開されたDraft HTML5 Stabilization Planを読んでも、そんな変わりそうな気配はない。

WHATCGについても、今のところ仕様の公開元を解決するために使う感じなので、WHATWG HTMLにもとくに変化はないだろう。Microsoftが入るとか、そういうのはわかんないけど。

2012-04-17

AppleがTouch Events仕様に対し新たに3件の特許情報を開示

W3C

jQuery BlogでTouch Eventsと特許の件についてエントリが上がっていた。

Appleの独自拡張としての始まり、Mozillaの独自タッチイベントモデル、W3CのTouch Events仕様、MicrosoftのMSPointer、Appleの特許開示について簡潔にまとまっていて良かった。特にMSPointerとの比較のところで、Xperia solaのホバー実装を取り上げTouch Eventsは特定のデバイスの特定の入力に特化していると指摘している。そこをラップするPointer Eventsの方がfuture-proofだと考えてるみたいで、さすがjQueryのひとだなあと思う。

さて、そんな中タイミングよろしく、新たに3件discloseされたようで。

On April 14, Apple disclosed 3 additional patent applications for the Touch Events spec. Web Events' patent status page [1] states all three of these new disclosures have "No Royalty-Free Commitment"

すでに開示されている4件とおなじくNo Royalty-Free Commitmentということで、お察しくださいというか。

Touch Events PAGからのレポートが来るまでTouch Events仕様は止まったまま。jQuery Blogのエントリを書いたScott GonzálezはWebEvents WGのteleconでjQuery won't release a normalization layer if the feature is not a standardと、独自拡張のままなら抽象レイヤーをつくる気はないと言っている。

さらに3件追加されたし、時間かかりそうだなあ。

ニュースサイトみたいなタイトルになってしまった。