ただ、YouTube は話がちょっと違う。プラグインのインストール状況を考えてみた時に Flash Player だけが圧倒的に普及してたから Flash で再生できるようにしたってだけだ。おそらく全ブラウザが動画再生用の UI を自前提供してても、結局何らかの動画形式に対するプラグインが普及してなかったのなら YouTube は Flash でのインターフェイスを実装してたはずだ。

ウェブ向けの動画・音声・画像形式

こりゃ無理だなあ。というか意味がない。多分今やってもみんな不幸になる。

たとえば現在動画形式が乱立してるのにも理由があって、新しいコンテナ、新しい圧縮形式に対応できるようになってるんだよ。たとえば AVI と QuickTime ぐらいしかない頃にその頃の考え方を盛り込んでウェブ用に機能拡張した動画形式を W3C が提唱したとする。そのあと Matroska が出てきても、そこにある複数音声、字幕、頭出しはウェブ用動画形式のバージョンが上がるまでウェブでは使えないということになる。これじゃあ話にならない。

じゃあどうすればいいかというと、動画・音声・画像のコンテナ・圧縮・再生のためのプラグインは各種サードパーティーに勝手に作らせといて、ウェブではそれをラップするしかない。じゃあラップするためのファイル形式を W3C が提唱すればいいかというとそうでもない。

まず、機能的な動画・音声・画像形式っつったって結局は他の動画・音声・画像やウェブページへ機能的に飛べなければ意味は無い。あくまでもウェブサイトのコンテンツの一部だから単純なリンクではだめだ。複雑な情報を、視覚的に優れた形で提供できなければならない。

次に、動画・音声・画像をアップロードするためにわざわざラップ用のファイル形式をエンドユーザーが覚えなければならず、またただでさえ複雑化した HTML、CSS、JavaScript などのパース・レンダリングに手一杯のブラウザ開発側が機能的な動画・音声・画像形式に対応しなければならない、世界全体を巻き込んだ莫大な負担増を許容させなければならない。しかもその内容は HTML で充分に代用が効く。

流石にこれを肯定できるだけの主張を僕は思いつかないよ。機能的な動画・音声・画像形式の標準化は無理だ。Opera だけが使える形式があっても意味ないし、結局は HTML への埋め込みにしかならないと思うよ。

Permalink | 記事への反応(0) | 07:40

2007-04-04

■Re: anond:20070404200550

anond:20070404150650の人ではないけれど。

HTML + CSSだとそれを解釈するWeb ブラウザ限定になっちゃうじゃん。
anond:20070404144349

に対して

RSSはXMLパーサに依存してるよ。
anond:20070404150650

と言ったわけだ。

つまり、「HTML+CSSを扱えるのがWeb ブラウザに限定されるように、RSSを扱えるのはXMLパーサに限定されてる、どっちも同じようなもの」ってことでしょ。

で、ここからは私の意見なのだけれど、RSSに見た目を求める人ってのは、なんでRSSを使うのだろう。

上の「HTML+CSSとRSSは似た様なもの」ってのは、ある意味正しいのだけれど、でも、現状では「似たような物」ではない。ちゃんと用途別に使われている。

RSSが出てきたのは、この「用途」の違いじゃないの？

HTML+CSSはブラウザがレンダリングして人が見るために豊かな表現力を持つ。それと引き換えに、ブラウザの消費する(開発とかも含む)リソースは多い。

そういうのじゃなく、もっと軽やかな仕組みのために、表現力を落として意味付けに重点を置いたのがRSSでしょ。RSSにHTML+CSSのような表現を求めてもしょうがないと思うけどなぁ。というか、そこまでするなら、UAみて振り分ければよいのに。

Permalink | 記事への反応(0) | 21:10

2007-03-17

■無茶なレンダリングしないように

一定以上の階層化はシステム側で拒否してくれんかなぁ

それはそうとトップページが読み込みづらいと皆「自分の日記」だけ書くので、それはそれでいい傾向になると思う。

Permalink | 記事への反応(0) | 16:39

2007-02-22

■実装ではなく趣旨を理解しよう

*{ margin : 0 }はもう古い！？ | Emotional Web

はてなブックマーク - *{ margin : 0 }はもう古い！？ | Emotional Web

はてなが酷い。

はじめに

base.cssとかcommon.cssとかを書いて読み込ませるのは、何のためだったか考えてみよう。古い新しいの問題じゃないと気づくだろうか。少なくとも、レンダリング時間なんて完全に後付けだと洞察できるはずだ（あなたたちはjs大好きだよね）。

さて、真っ新なとこからCSS書いてくとき、どんなデザインにしろほぼ毎回指定する要素が出てくる。a img{border:none;}とかhtml,body{margin:0; padding:0;}とかだ。それなら始めにa img{border:none;}とかを羅列したファイルを用意しておけば、余計な手間が省けるじゃないか。たぶん根本の動機はこんなとこだろう。

それがいつの間にかデフォルトで適用されるスタイルをキャンセルするっていう方向へ迷走し、*{margin:0; padding:0;}なんて表現が生まれた。この指定は言うまでもなく有害で、著名なのはフォームのボタンが縮こまったり、liのネストが判別できないなどの副作用が生まれる。あまりにもすべてがキャンセルされるため、わざわざひとつずつ要素のスタイルを定義しなければならなくなって、ファイルサイズは増え可読性は下がり、冒頭で言うようにレンダリングにも時間が掛かるようになる。FireBugがない時代、この要素のスタイルはどのファイルのどの部分で指定されてるのか調べるのは本当に大変だった。*.cssをgrepしたとしても、単にul li{}とか書かれてるのがカスケーディングしてたらお手上げ。

これらのデメリットを認識したとき、はて*{margin:0; padding:0;}のメリットはなんだろうと考える。あ、特にないよね。じゃあやめよ。←いまここ

こんなのは実際にCSSを書いてたら気づくことだ。海外とか時代とか関係ない。元記事の趣旨は「*{margin:0;}は古い」じゃなくて「どんなCSSが効率的か Part2」だ。レンダリング重いから*{margin:0;}やめようなんてコピペ脳丸出しじゃ、いつまで経っても効率的なCSSなんぞ書けんよ。

＊原理主義者が「（例えば数十年後にリリースされた）UAがどんなスタイルを適用するかわからないので、最初にリセットするのは永続性完全性の観点から意味がある」と言うけども、未知のUA（というかデフォルトスタイル）まで考えてCSSを書くのはあまりに大変だ。それに、そんなことになれば、たぶん、compat.user.cssみたいなのが流行るはず。デフォルトスタイルに頼った表現がしょせん実装依存なのは認めるけど、ちょっと非現実的すぎるので、考慮から外させてもらう。俺はいま実務の話をしたいんだ。

じゃあどんなのがいいんだよ

で、元記事では、じゃあどんなCSSがいいのかって点がついで程度にしか触れられていないので、俺なりに考えてみた。

a img{border:none;}

これは外せない。aの中のimgにborder付けたいってほうがイレギュラーなので、わざわざa.logo img{border:1px solid #333;}なんて書き直すのも苦にならない。例外には手作業でもって対応すべき。

html,body{margin:0; padding:0;}

ほとんどの場合、隙間を空けたいよりも隙間を空けたくない。キャンパスはフルに使いたい。

印刷時にはそうでもないので、@media print {body{padding:1cm;}}なんてのがあってもいいけど、それはまた別の話。あとそういうのは印刷するユーザー側で指定すべきだとも思う。理想論だけど。

*{font-style:normal;}

lang="ja"な文章において斜体は不要。どうせあなたはemとかaddressとかにfont-style:normal;付けるんだから。

pre,code{font-family:monospace; white-space:pre;}

preやcodeがsans-serifだとイラっと来ますよね。

これは絶対やるな

やられるとイラっとくるもの。個人的。

body{font-family: "MS Pゴシック";}など

俺はページをメイリオやヒラギノやM+ FONTやVLゴシックで見たいんだよ！　お前の趣味を押しつけんな！　あと最後に一般名（sans-serifとか）くらい書け！

でもpre.2ch-ascii-art{font-family: "MS Pゴシック";}なんてのはやさしさが溢れていてとても好ましいと思う。部分的にfont-family指定するのは別にいいけど、全体のデフォルトフォントをいじられるのは不愉快でしかない。

pre{overflow:auto;/* or scroll */}

まあ仕方ないのはわかる。解決法も知らない。けどホイールでスクロールしてるとき興味のないサンプルコードで引っかかるのはとてもムカつくんだ。俺は君のサイトが崩れてるかどうかより、いつも通りのスクロールに関心がある。

pre以外にグラフィック目的でoverflow:auto;を指定するのは論外。

まとめ。そうねえ。

「CSSは個々人のスタイルを反映してるということでしかないんじゃないの」

「そうですね」

Permalink | 記事への反応(2) | 21:46

2007-02-01

■そろそろまたJavascript オフの時代が来た

Google Maps以前のころ。ヘビーユーザーのあいだではJavascript オフが常識になっていた。度重なる時計の再発明に業を煮やし、IEのActiveXに警戒心を抱き、不安定なOSをさらに不安定にするため暗躍するのがJavascriptでありJScriptだった。

Google Mapsがあれだけのインパクトを与えたのは、ひとえに、こういった先入観を打ち砕いたからに尽きる。信じられないことに、Javascriptって便利なのだ。実に見事な枯れた技術の水平思考である。

Ajaxという言葉が帰納され、ライブラリがぼこぼこと発表される。ネイティブオブジェクトの拡張と、クロスブラウザのための供物ラッパー集合体たるprototype.jsを筆頭に、様々なものが世に出、様々なアプリケーションがより手軽に実装できるようになった。

script.aculo.usやLightBoxやmoo.fxといった、エフェクト中心のライブラリも出回り始める。IEのせいで煩雑な記述を強要されたグラフィックアーティストが、DOM操作によって問題を解決しようとし始めた。リンクにmouseoverしたらうっとうしいエフェクトを振りまくスクリプトが当たり前のように設けられた。このはてなも、いつの間にか大量のMochikit/*.jsを読み込んでページのレンダリングを遅らせている（たまにad.hatena.ne.jpのレスポンスが遅いときなど目も当てられない）。これらに共通することは、多くの人がそれを望んでいないということだ。

もちろん好ましい方向への進化もあった。OperaがUser Javascriptを発案・実装し、FirefoxもGreasemonkeyでそれに追随。SafariもCreammonkeyを得て、いわゆるモダンブラウザユーザーは、豊かなスクリプトライフを楽しめるようになった（IEにもなんとかいう同様の機構を実現する環境はあるが、IE ユーザーには敷居が高いのかほとんど見かけない）。Livedoor ReaderやGoogle Readerはイベントを操作することで、キーボードでの操作を今までにないほど豊穣にした。入力フォームのリアルタイムバリデーション、Google AnalyticsやAdsenseの導入容易さなど、見るべき意匠もいくつかある。

しかし平均的に考えて、何の変哲もない個人ブログにJavascriptは必要ないものだ。素人がつくったタイマーは、いつもユーザーを憂鬱にする。素人がつくったAjax サイトは、だいたいの場合IEとFirefox以外を排除するもっともらしい理由を得るためにAjaxを使う（Dellが自社サイト上で「Netscape4.6以上で閲覧せよ」と警告することによって、やる気のなさを主張するようなものだ）。

我々が自分のブラウザ上でページを表示するとき、Javascriptによる意外な効果などまったく期待していない。UIにおいては最速こそ正義、というmala氏の言葉を引用するまでもなく、不必要に重いサイトはそれだけで忌避するに足る理由となる。流行を追って常識を忘れるのは愚かとしか言いようがない。

Firefox(のNoScriptアドオン)とOperaは、ページごとサイトごとにきめ細かなJavascriptの挙動を設定できる（不勉強にしてSafariについては知らない。IEはできない）。Javascriptに限らず、広告ブロックや不要ファイルの無視、特定Flashの再生可否など、ユーザーは「何が要らないか」を指定でき、要らないものを気軽に突っぱねられるようになった。不要なものを除去する習慣が、ヘビーユーザーのあいだで間違いなく形成されつつあるのだ。

何かひとつのことをするためのJavascriptは、これからしばらく出現し続けるだろう。ウェブマスターが、重厚長大な飾りで貧弱なコンテンツを隠すためだけに。何かを拒絶するテクノロジーは、今後しばらく発展し続けるだろう。十重二十重のラッピングに疲れた人たちのために。

Permalink | 記事への反応(4) | 21:11

「レンダリング」を含む日記

■嫁がynkに萌えて困ります

■Re: ウェブ2.0時代のウェブブラウザに求めるもの

最新の HTML 定義に準拠しろ

デフォルトスタイル改善しろ

textarea をもっと機能的にしろ

YouTube・2ch ブラウザ

ウェブ向けの動画・音声 UI