HTML5に期待することと期待していないこと

最近何かと話題のHTML5とChrome OS関連(?)の記事より

@IT: 進化するHTML 5、OS化するChrome

講演の中盤を過ぎて耳に飛び込んできた言葉の数々に思わず顔を上げた。HTML 5の枠組みで、ノーティフィケーション、P2P、Webカメラ、ドラッグ＆ドロップ、リッチテキスト編集のAPIを標準化するというような話をしていたのだ。極めつけは、質疑応答での次のようなやり取りだった。Webブラウザ内の複数ウィンドウ管理のAPIを標準化してはどうか、という聴衆の提案に対して「それは考えたことがなかったが、確かにいいアイデアだ」とグーグルの担当者が即答していた。HTML 5には、このまま行けばかつてデスクトップOS上のアプリケーションだけが利用できた機能が次々と取り込まれていきそうだ。

うーーん。。。ありのような、なしのような。。。

便利さと大変さはトレードオフ

思い起こせばプログラミング始めたころは、HTML+JavaScriptのセットではローカルファイルが扱えないことを不便だなと思っていましたが、物心が付いてくると、それができないからこそセキュリティ的に安全なんだなと納得したものです。

確かにHTMLだけでローカルファイルの操作ができたり、3Dグラフィックス関連のAPIがあれば便利なのでしょうが、そのアプリケーションにWeb上のリンクをクリックするだけでアクセスできてしまうのならば、開発者はあらゆるセキュリティ項目を考慮する必要が出てくると思います。

ひょっとしたらHTML5のいくつかの機能は、セキュリティの考慮のために、ブラウザ機能でデフォルトOFFになるかもしれませんね。そしてGoogleを始めとする各種サービスを実行するにはそれらをONにする必要があり、ONにしたままWeb上をうろうろすると色んなウイルスに侵入され、ON/OFFを使い分けるということをユーザに意識させ、情弱は付いていけないという大変息苦しい世の中になるかもしれませんね。

Javaの失敗とFlashの成功という教訓

そもそもWebの世界にはJavaという偉大なる失敗の先住民がいます。Javaを使えば確かに色々なことができます。できることで言ったらJavaScripの比ではありません。しかし信じられないほど起動が遅く、メモリを大量に食うわりには、できることはネイティブには遠く及ばない上に速度もそこそこ。加えてセキュリティ面では穴だらけという分かりやすい特徴があるため、結果として一部の信者を除いて全く使われていないという現実があります。

そのような先住民の失敗から、JavaやActiveXのようなブラウザ上で動作するプラグインが忌避された時代もありましたが、そのいわれなき差別を払拭したのがAdobe Flashです。

Adobe Flashもれっきとしたブラウザのプラグインです。しかしインストールが手軽で、読み込みが速く、動作が軽くて、そしてできることもかなり広いという便利プラグインです。おかげでFlashは、プロプライエタリなプラグインであるにもかかわらず、普及率がかなり高いものになっています。Youtubeの普及がそれを示していますよね。

以上より、HTML5の普及には起動が速くとても軽いAPIであることが必須であると言えます。どんなにネイティブアプリケーションと同じスピードでも、起動や読み込みに何秒も待たされるようではダメですよ。;)

ブラウザはアプリケーションの共通基盤として腰を据えてほしい

冒頭で引用した記事にはマルチスレッド用のAPIや通信用のAPIについて書いてあり、それによって完全にバックグラウンドで動作するスレッドやタブ間通信、ノーティフィケーション機能が盛り込まれると書かれていますが、そこまで高度なアプリケーションをブラウザ上で動かす必要があるんでしょうか？ アプリケーションをブラウザ上で動かす利点は、いわゆるS/Cモデルのシステムのように、クライアント側に特別な環境を用意することなく、サーバとやりとりするだけで色んな事が出来る、という点だと思います。であれば、そこまで複雑なマルチスレッドプログラミングは不要ですし、通信もリクエスト送信/レスポンス受信の機能だけ整理してくれればいいんじゃないでしょうか？ バックグラウンドスレッドやノーティフィケーションはブラウザ固有のプラグイン(Firefoxの拡張機能等)で実現すればいいのではないでしょうか？

ブラウザは現在でもOSを(ある程度)意識しないで使えるプラットフォームとして便利に使っています。単純な計算やテキスト処理ならJavaScriptだけで作れば、クライアントはアプリケーションのインストールなしにそれを利用できます。Wikiをサーバ上に作れば、誰でも簡単に情報共有ができます。これをブラウザを使わずに実装するとしたら大変なことです。ブラウザさまさまです。

色々書きましたが、HTML5には大いに期待しています。今できないことがブラウザ1つでできるようになれば、開発者がアプリケーションのプラットフォームを何にするか悩まなくて済みます。ですが、飽くまでHTMLに期待することはページ(タブ)単位の表現力であり、タブをまたいだ通信や、デバイスを制御する機能は(個人的には)不要だと思います。

間違ってもJavaの二の舞にならないようにしてください。

吉祥寺の旅: アテスウェイ再び。しかし。。

今日も午後仕事が休みなので(休みにしたので)、吉祥寺に遊びに行きました。しかも今日は珍しく(!?)1人ではなくお休み中の同期と。下はお昼に食べたオムライス。卵がふわふわ。ボリュームもありました。サラダとコーヒーもしくはデザートが付いて1200円ぐらいでした。

 

吉祥寺と言えば何と言ってもアテスウェイ(?)なので、何はともあれアテスウェイを目指すことに。

天気はあいにくの雨でしたが心は元気に、吉祥寺からアテスウェイを目指します。途中で、そう言えばこの前友達が吉祥寺の「ステファノアンナ」という店を勧めてたなーと思い、ふとその店の住所を見ると、
あ、あった。

大きな地図で見る

目の前にありました :D 吉祥寺と西荻窪のちょうど真ん中ぐらい。突然の発見だったのでそこで何を買うべきなのかもよく分からず、店員の人にお勧めを聞いてみると、夏だけ限定でゼリーを扱っているとのこと。限定と聞いたら買わずにはいられない日本人的な遺伝子(!)の人間なので、りんごゼリーを購入。よく考えたらこれを持ったままこの後アテスウェイまで行かなきゃならないことを、全く考えていなかったことをちょっと後悔しつつも、お店を後にしました。

今回は写真なしなので、今度行ったときに写真付きで紹介できればと思います。なお、ゼリーはりんごの果汁が入っているということがど正面から来るような果実感がありました。しかしお酒(ブランデー?)が入っているらしく、私にはちょっと大人の味すぎました。今度は焼き菓子に挑戦する予定です。

さていよいよ本命のアテスウェイへ。てくてく歩くこと約10分。東京女子大の前に出てアテスウェイを見るとなんと！

 

や、休み・・・！？

なんたる。。。まー振り替え休日の日にきてしまうとは。。。これも全て日ごろの行いのせいだと思って諦めます。。

この日はあとは吉祥寺をぶらぶらして、その後新宿へ移動して2時間ぐらいだべって(!?)帰りました。やっぱり誰かと一緒だと楽しいですね。一人だとどうも買い物も無機質で :s

楽しい半面、色々と課題の残る一日でした :)

Perfume 「トライアングル」

椎名林檎に続き、勢いでPerfumeの「トライアングル」を買ってしまいました。「前から気になっていた。いつか買ってやろうと思っていた。後悔はしていない。(定型文)」

Perfume程の人気があれば、Youtubeだけで十分視聴はできるんですが、やはり音楽はCDでしょう ;) 音質がどうのじゃなくて、作品として入手することに意義があるんですよ。ジャケットも歌詞カードもDVDも付いてくるし。

肝心の中身ですが、初Perfumeということもあり、聞いてると洗脳されそうになります :D キャッチーな曲調はいいんです。いいんですがいかんせんテクノですからね。Blues好きには540度ぐらい視点が違いますからねー。なんか、ビートマニアの曲に聞こえます :s いや苦言じゃないですよ。曲は聴きやすいですよ。なんとなく口ずさんじゃうし。踊りたくなるし ;)

DVDにはライブ映像も入っていますが、彼女達、よくヒールであんなに踊れますね :O エンターテイナーとしてのツボを抑えてますねー

全然詳しくないんですが、今はアイドル系でテクノというのは彼女達以外いませんよね？ このジャンルを無くさないためにも、今後とも頑張って欲しいです。

椎名林檎 「三文ゴシップ」

椎名林檎さんの「三文ゴシップ」を買いました。東京事変は買ったことありますが、椎名林檎さんのアルバムは初です。初「林檎」です。ジャケットが肌色すぎて、iPodでジャケットが表示されるたびにドキッとします :)

やはり特徴ありますねー椎名林檎さんは。ロックからバラードまで椎名林檎ワールドが渦巻いています。個人的には2曲目の「労働者」が好きです。イントロの入りがいい。歌詞が面白い。声が高い :)

椎名林檎のソロアルバムだと東京事変とは雰囲気が違いますね。メンバーも違うし。浮雲さんがいないのであんまりギターを押してきませんし。

thee michelle gun elephantもTHE YELLOW MONKEYもJUDY AND MARYも解散しちゃったし、最近はこういう気骨のあるロッカーがいなくなった気がします。これも時代の流れですかね。さびしー限りです。

XHTML2終了、HTML5へ一本化

XHTML 2終了、HTML 5一本化: マイコミジャーナル

HTML 4.01の後継となる規約がHTML 5になることが、ほぼ明らかになった。2日(米国時間)、W3CはXHTML2 Working Group Charterが12月31日に期限をむかえても、もはや更新しないことを明かにした。これはW3Cが次世代のHTMLとしてHTML 5を推進していることを明示するとともに、HTML 5の策定作業に割くリソースを増やしたい狙いがある。

HTML 4.01の後継規格としてXHTMLの策定が進められたが、当初期待されていたようには普及しなかった。結局、あとから策定が進められたHTML 5が後継として使われることになった。ただしHTML 5には、XHTML 2で規程されている機能のいくつかは取り込まれている。

最近は勉強不足で、HTML5についてはほぼ無知識状態です。何やらマークアップの仕様レベルでビデオの再生まで規定する、ということぐらいしか知りません。それすら合っているか微妙です。。。

しかしXHTMLが流行らなかったからやめるって。。。W3Cってそんなにいい加減なの？ まー仕様は1つだけあればいいですよ。

何でもXML化するのが世の流行りという中で、HTMLだけは異色の存在となっている現状ですが、これでよりStrictなマークアップ言語になるのでしょうか。だいたいXHTMLが流行らないのはそれ用のソフトウェアが少ないからですよ。

HTMLでは「空要素には閉じタグは不要」とか「属性値をダブルクォーテーションで囲まなくてもよい」とか言われていますが、仕様上許容しているだけであって推奨しているわけではありませんなのでHTML4.01準拠の文書でも「空要素に閉じタグを付ける」「属性値は必ずダブルクォーテーションで囲む」とすればいいんです。

しかしこれは何も作成者が必ず意識しなければならないことではありません。作成するソフトウェア側で吸収すればいいのです。Wordで文書を古いHTMLで出力させると、丁寧に空要素から閉じタグを消してくれますが、これこそ余計なお世話なのです。HTML4.01で出力しようがXHTML1.0で出力しようが、基本的に同じ内容になるようにするべきです。

例えば<i>タグはXHTML1.0では使用できませんが、そもそも斜体はCSSで表現するべきものですし、<i>ではなく<em>を使えばよいのです。無理に<i>タグなんて使わなくてよいのです。

「XMLを必須にするとWebページ制作者への負担が増える」とも言われていますが、そうでしょうか。FlashやActionScriptの方がHTMLよりよっぽど複雑です。それでもFlashは十分市民権を得ています。それはオーサリングソフトが優れているからです。対してHTMLはタグの手打ちか、ひどいタグ出力しかできないWYSIWYGエディタだけです。

「思ったより流行らなかった」とティムバーナーズリーが嘆いているのは、HTML出力ソフトウェアの製作者の志の低さだと言っても過言ではありません。なるべくしてなった結果なのかもしれません。もっとガンガンXMLをプッシュしましょうよ。

ん？待てよ？XHTMLが流行らなかったからHTML5に統合するってことは、HTML5でもぐだぐだな仕様が続くってこと！？まさかね。。。

なお、HTML5が出てきた経緯については、ちょっと古い記事ですが@ITのHTML5が持つ本当の意味が参考になると思います。

翻訳者には便利？: Google Translate Toolkit

翻訳者のための作業ツール『Google Translate Toolkit』公開: マイコミジャーナル

米Googleは6月9日(現地時間)、『Google Translate Toolkit』を公開した。

…中略…

修正に際しては各種補助ツールが用意されており、例えば辞書であったり、専門用語や熟語など、簡単な辞書だけでは解決が難しい用語の参照も可能になっている。また翻訳に際してはGoogleが提供するTranslation Memoryという機能も利用できる。これは以前に人の手によって翻訳された文書を記録・蓄積しており、もし翻訳時に似たようなフレーズが登場した場合に、こうしたデータベースを活用して翻訳の精度を高める。

Googleからまた面白いものが出ました。翻訳者用のツールキットです。上述の通り専門用語辞書を作成し参照しながら作業ができたり、翻訳内容に対応する原文をハイライトしてくれたり、翻訳作業を便利に補助してくれます。

編集できるのはローカルファイルのWordやPDF、または一般的なWebページやWikipedia、Knol。

使ってみた感想は、翻訳作業は確かに便利かもしれないけど、いかんせん翻訳結果を保存したときにレイアウトが崩れてしまうなど、ちょっと不便。あと機械翻訳するときも、専門用語辞書に登録した単語を使用してくれるともっと助かるかも。個人的には、RFCの翻訳にも特化してくれるとありがたいです。

Googleのサービスは多々あれど、まだまだ進化過程であるGmailやGoogleマップはBetaが付いていますが、このGoogle Translate Toolkitには付いていません。ということはこれがもう完成であり、機能追加は見込めないんですかね。:s

思い付きだけでなく、もっと便利に進化してくれることを切に願います。