アカウント名:
パスワード:
言ってる事の範囲がどう見ても「プラグインをブラウザ内部に取り込みたい」であって、良い意味での「プラグインが必要なくなる未来」ではなく、悪い意味での「プラグインが必要なくなる未来」を思い描いているように思います。以前から思っている印象を再認識した、というか。 今でさえ困難な WCAG との整合性をどう取っていくのかとか、携帯端末、ハンドヘルド端末、tty 端末……といった PC と比べて処理能力も表示性能も劣る端末に対するコンテンツ提供とか、そういったところは「とりあえず無視」なのかなぁ、と。
もっと簡単に言うと「ブラウザを作るのは金も
うまく行かなかったのは「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)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
プラグインを無くしたい?何言ってんの? (スコア:3, 興味深い)
言ってる事の範囲がどう見ても「プラグインをブラウザ内部に取り込みたい」であって、良い意味での「プラグインが必要なくなる未来」ではなく、悪い意味での「プラグインが必要なくなる未来」を思い描いているように思います。以前から思っている印象を再認識した、というか。
今でさえ困難な WCAG との整合性をどう取っていくのかとか、携帯端末、ハンドヘルド端末、tty 端末……といった PC と比べて処理能力も表示性能も劣る端末に対するコンテンツ提供とか、そういったところは「とりあえず無視」なのかなぁ、と。
もっと簡単に言うと「ブラウザを作るのは金も
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