アカウント名:
パスワード:
言ってる事の範囲がどう見ても「プラグインをブラウザ内部に取り込みたい」であって、良い意味での「プラグインが必要なくなる未来」ではなく、悪い意味での「プラグインが必要なくなる未来」を思い描いているように思います。以前から思っている印象を再認識した、というか。 今でさえ困難な WCAG との整合性をどう取っていくのかとか、携帯端末、ハンドヘルド端末、tty 端末……といった PC と比べて処理能力も表示性能も劣る端末に対するコンテンツ提供とか、そういったところは「とりあえず無視」なのかなぁ、と。
もっと簡単に言うと「ブラウザを作るのは金も体力もあるところだけで十分。俺たちが Web を支配する」という感じが異様に強いというか。 プラグインが不要な Web の世界 = その辺りを全部サポートできないようなところはブラウザを作ろうなんて思うな、と締め出してるような印象さえ受けてしまうのですよね。
現状の「現実の Web」を考えると、さまざまな動画配信サイトにおいて WCAG にもある「動画と同等、または内容をユーザに伝達できる代替となる文章の提供」なんてものは一切存在しない訳で、HTML4 が目指していた事が強く感じられた「媒体を選ばない Web」を根底から破壊するのが HTML5 だ、という印象しか受けないのですよね。 なお、「動画と同等、または内容をユーザに伝達できる代替となる文章の提供」というのは現行の WCAG 2.0 ですら Level A (最低限のレベル) です。AA や AAA (満たす事が望ましい以上のレベル) ではありません。(WCAG 2.0 1.2 Time-based Media: Provide alternatives for time-based media)
HTML4 (1999/12) + WCAG 1.0 (1999/05) 時代ですら「画像は同等、または内容をユーザに伝達できる文章の提供」「動画は同等、または内容をユーザに伝達できる大体となる画像や文章の提供」が盛り込まれていた訳ですが、実際のところはどうでしょう。img 要素の longdesc 属性すらブラウザがまともに "使い物になる" インタフェースを提供しているものなどは "比較的マシな実装をしている" Gecko 系ブラウザですら全くありません。 動画を全部見なくても大体のサマリが分かる文章の提供 + 該当 URL へのリンクへ簡単にアクセスする手段を提供するインタフェース、なんてものは現状の Web や Firefox/SeaMonkey に存在するでしょうか。
実際、一部の原理主義者 (笑) のサイトを除いた場合、(イントラネット/LAN 内に存在する機器の Web インタフェースを含む!) Web の世界において「媒体を選ばない Web」を考慮してコンテンツを作っているサイトなんて、政府調達要件を満たすためにアクセシビリティに配慮しました、というもの以外ほぼ存在しないのではないでしょうか。
# 以前いた会社がそういうサイトを目指していたのは分かってます。分かってますよ。現実が伴わなくても。
なんというか、「先行実装しているブラウザ」の開発者群は、こういった強者の理論を押しつけようとしているように思います。まさに Microsoft が HTML 3.0 で提唱し、HTML4.0 策定時に IE で先行実装していたがために acronym 要素をごり押ししようと (して失敗) したように。
HTMLは論理構造を記述するためだけのフォーマットであれば良い、という主張だと思うけどあってる？
HTML5の方向性に関しては、求められてるブラウザが「高度なUIを表現できるもの」である以上、仕方ないんじゃない？私もそういう主張に近いところはあるし、そういう意味でXHTMLはかなり好きなのだけど、HTML5みたいな進化も仕方ないのかなぁ、と思ったり。Webが論文を公開するばではなく、サービスの基盤になってしまった以上、UIのリッチ化は進めるべきだし、どうせ標準装備にするならプラグインより仕様で取り込んだ方が良いってのはある。
まあ、個人的には、媒体を選ばないWebとサービスプラットフォームとしてのWebがAirみたいな形で綺麗に分離してくれたらと思うけど。
> 良い意味での「プラグインが必要なくなる未来」
これがどういう未来を想定しているのかよく分かりません。結局は動画やら音声やらアクセシビリティやらをフルサポートしないとどうにもならないと思うのですけど。
うまく行かなかったのは「XHTMLが」というより「XHTMLのモジュール化が」だな。HTML 5はXML文法でも記述できるわけだし。もっと言うと「複数のボキャブラリを組み合わせて使うというXMLの理想形が」失敗に終わったってことね。
まあちょっと考えてみれば失敗するのは必然だということはすぐにわかる。自由度があまりにも大きすぎるんだわ。複数のボキャブラリが含まれた文書をブラウザだけで完全にサポートするのはまず不可能。いくつかのボキャブラリはW3Cで策定が進められたが、勧告になるのが遅かったり、あるいはまだ出ていないものもある。仕様が分割されてバラバラだと、ブラウザ実装者やコンテンツ開発者はその全てに対応しなければならず、互換性や相互運用性の保証が困難になる。そもそも従来のHTMLからかけ離れすぎていて学習コストも高い。
頓挫した理想形から比べるとHTML 5は随分と日和った醜い代物に映るが、これは結局worse is betterなんですよね。Multicsに対するUNIXみたいなもので。巨大な仕様だけど、そのおかげで融通が効くわけだし。
simple is the bestではなくworse is betterと言っていることに注意。
気になったので、ググってみました。これのことでしょうか: The Rise of "Worse is Better" [artcompsci.org]
あるとき、MIT 出身と Berkeley 出身(ただし、Unix開発に携わっていた)の二人の有名人が OSの問題を話し合うために集まった。 MITの彼は ITS (MIT 人工知能研究所のOS) に精通しており、 Unix のソースコードを読んでいた。彼は Unix がどのように「PC loser-ing」問題を 解決しているかに興味を持った。「PC loser-ing」問題は ユーザプログラムがI/Oバッファのような大規模な状態を内部に持つ、時間のかかる操作を システムに要求したときに起こる。もし操作の実行中に割り込みがかかったら、 ユーザプログラムの状態は保存されなければならない。しかしシステムルーチン起動は通常1つの命令であるため、ユーザプログラムの 現在の命令の実行位置を示すプログラムカウンタ (PC) はプロセスの状態を適切に保持していない。そこでシステムはその命令が実行される 前に戻るか、そのまま命令を実行したことにして先に進むかしなければならない。「正しい」やり方はもちろん、前に戻ってプログラムカウンタを システムルーチンを起動した命令に戻し、ユーザプログラムに復帰するとそれがシステムルーチンを再実行するようににすることである。プログラムカウンタがユーザモード (MIT
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
プラグインを無くしたい？何言ってんの？ (スコア:3, 興味深い)
言ってる事の範囲がどう見ても「プラグインをブラウザ内部に取り込みたい」であって、良い意味での「プラグインが必要なくなる未来」ではなく、悪い意味での「プラグインが必要なくなる未来」を思い描いているように思います。以前から思っている印象を再認識した、というか。
今でさえ困難な WCAG との整合性をどう取っていくのかとか、携帯端末、ハンドヘルド端末、tty 端末……といった PC と比べて処理能力も表示性能も劣る端末に対するコンテンツ提供とか、そういったところは「とりあえず無視」なのかなぁ、と。
もっと簡単に言うと「ブラウザを作るのは金も体力もあるところだけで十分。俺たちが Web を支配する」という感じが異様に強いというか。
プラグインが不要な Web の世界 = その辺りを全部サポートできないようなところはブラウザを作ろうなんて思うな、と締め出してるような印象さえ受けてしまうのですよね。
現状の「現実の Web」を考えると、さまざまな動画配信サイトにおいて WCAG にもある「動画と同等、または内容をユーザに伝達できる代替となる文章の提供」なんてものは一切存在しない訳で、HTML4 が目指していた事が強く感じられた「媒体を選ばない Web」を根底から破壊するのが HTML5 だ、という印象しか受けないのですよね。
なお、「動画と同等、または内容をユーザに伝達できる代替となる文章の提供」というのは現行の WCAG 2.0 ですら Level A (最低限のレベル) です。AA や AAA (満たす事が望ましい以上のレベル) ではありません。(WCAG 2.0 1.2 Time-based Media: Provide alternatives for time-based media)
HTML4 (1999/12) + WCAG 1.0 (1999/05) 時代ですら「画像は同等、または内容をユーザに伝達できる文章の提供」「動画は同等、または内容をユーザに伝達できる大体となる画像や文章の提供」が盛り込まれていた訳ですが、実際のところはどうでしょう。img 要素の longdesc 属性すらブラウザがまともに "使い物になる" インタフェースを提供しているものなどは "比較的マシな実装をしている" Gecko 系ブラウザですら全くありません。
動画を全部見なくても大体のサマリが分かる文章の提供 + 該当 URL へのリンクへ簡単にアクセスする手段を提供するインタフェース、なんてものは現状の Web や Firefox/SeaMonkey に存在するでしょうか。
実際、一部の原理主義者 (笑) のサイトを除いた場合、(イントラネット/LAN 内に存在する機器の Web インタフェースを含む!) Web の世界において「媒体を選ばない Web」を考慮してコンテンツを作っているサイトなんて、政府調達要件を満たすためにアクセシビリティに配慮しました、というもの以外ほぼ存在しないのではないでしょうか。
# 以前いた会社がそういうサイトを目指していたのは分かってます。分かってますよ。現実が伴わなくても。
なんというか、「先行実装しているブラウザ」の開発者群は、こういった強者の理論を押しつけようとしているように思います。まさに Microsoft が HTML 3.0 で提唱し、HTML4.0 策定時に IE で先行実装していたがために acronym 要素をごり押ししようと (して失敗) したように。
Re:プラグインを無くしたい？何言ってんの？ (スコア:4, 参考になる)
HTMLは論理構造を記述するためだけのフォーマットであれば良い、という主張だと思うけどあってる？
HTML5の方向性に関しては、求められてるブラウザが「高度なUIを表現できるもの」である以上、仕方ないんじゃない？
私もそういう主張に近いところはあるし、そういう意味でXHTMLはかなり好きなのだけど、HTML5みたいな進化も仕方ないのかなぁ、と思ったり。
Webが論文を公開するばではなく、サービスの基盤になってしまった以上、UIのリッチ化は進めるべきだし、どうせ標準装備にするならプラグインより仕様で取り込んだ方が良いってのはある。
まあ、個人的には、媒体を選ばないWebとサービスプラットフォームとしてのWebがAirみたいな形で綺麗に分離してくれたらと思うけど。
Re: (スコア:0)
> 良い意味での「プラグインが必要なくなる未来」
これがどういう未来を想定しているのかよく分かりません。
結局は動画やら音声やらアクセシビリティやらをフルサポートしないと
どうにもならないと思うのですけど。
Re: (スコア:0)
いまさらあえてHTML5を作ろうとしたのは、結局XHTMLがうまく行かずに、HTMLの進化を止めてしまった状態から抜け出したいというのが動機なんだから、そもそもこちらに文句を言っても仕方ないのではないでしょうか。むしろXHTMLがちっとも進まないということと、結局HTML5に擦り寄った方向に進むとしたら、そっちに文句を言った方が良いのではないかと。
W3CにもXHTML自体に求心力がなくなってるんですから...HTML5というのは現実的な解だと思います。
Re: (スコア:0)
うまく行かなかったのは「XHTMLが」というより「XHTMLのモジュール化が」だな。HTML 5はXML文法でも記述できるわけだし。もっと言うと「複数のボキャブラリを組み合わせて使うというXMLの理想形が」失敗に終わったってことね。
まあちょっと考えてみれば失敗するのは必然だということはすぐにわかる。自由度があまりにも大きすぎるんだわ。複数のボキャブラリが含まれた文書をブラウザだけで完全にサポートするのはまず不可能。いくつかのボキャブラリはW3Cで策定が進められたが、勧告になるのが遅かったり、あるいはまだ出ていないものもある。仕様が分割されてバラバラだと、ブラウザ実装者やコンテンツ開発者はその全てに対応しなければならず、互換性や相互運用性の保証が困難になる。そもそも従来のHTMLからかけ離れすぎていて学習コストも高い。
頓挫した理想形から比べるとHTML 5は随分と日和った醜い代物に映るが、これは結局worse is betterなんですよね。Multicsに対するUNIXみたいなもので。巨大な仕様だけど、そのおかげで融通が効くわけだし。
Re: (スコア:0)
その例えよくわかんないんだけど、
UNIXって仕様が巨大だったの？
Re: (スコア:0)
simple is the bestではなくworse is betterと言っていることに注意。
Re: (スコア:0)
Re: (スコア:0)
気になったので、ググってみました。これのことでしょうか: The Rise of "Worse is Better" [artcompsci.org]
あるとき、MIT 出身と Berkeley 出身(ただし、Unix開発に携わっていた)の二人の有名人が OSの問題を話し合うために集まった。 MITの彼は ITS (MIT 人工知能研究所のOS) に精通しており、 Unix のソースコードを読んでいた。彼は Unix がどのように「PC loser-ing」問題を 解決しているかに興味を持った。「PC loser-ing」問題は ユーザプログラムがI/Oバッファのような大規模な状態を内部に持つ、時間のかかる操作を システムに要求したときに起こる。もし操作の実行中に割り込みがかかったら、 ユーザプログラムの状態は保存されなければならない。しかしシステムルーチン起動は通常1つの命令であるため、ユーザプログラムの 現在の命令の実行位置を示すプログラムカウンタ (PC) はプロセスの状態を適切に保持していない。そこでシステムはその命令が実行される 前に戻るか、そのまま命令を実行したことにして先に進むかしなければならない。「正しい」やり方はもちろん、前に戻ってプログラムカウンタを システムルーチンを起動した命令に戻し、ユーザプログラムに復帰するとそれがシステムルーチンを再実行するようににすることである。プログラムカウンタがユーザモード (MIT