最大化とリサイズ

一般的なWindowsアプリケーションはウィンドウを最大化するとリサイザが消える。最大化状態のウィンドウの大きさを変更することが出来ないからだ。この挙動が好きになれない。最大化した状態から適当なサイズに変更するために無駄な労力を強いている。

Mac OS Xなんかだと常にリサイザが出ているのが普通だ。いつでもリサイズすることが出来る。が、右下のリサイザ以外でサイズを変更できないため、一方向のサイズを変更したいというニッチな要求を持っているときに苦労する。Windowsよりは良いけれど、これも好きではない。まぁ好きになれない理由は実に単純で、Windowsに染まっているからなのだろうが。

いつでもどこでもウィンドウサイズを変えたいという欲求はあると思う。使う側が最大化状態か否かを理解して操作するなんて理不尽だ。使う側は思った操作を簡単にできればそれでよい。いつまで経ってもここを変えないWindowsは不思議だ。

ついでにOperaのリサイザについて。WindowsやLinux向けのOperaにはリサイザがない。あるに越したことはないが、無いならないでも良い。だが、二方向のスクロールバーが表示されるMDIの子ウィンドウが最大化されている時にもリサイザを表示するのは大きな問題だろう。リサイズできないのにリサイザが出るのは、まずい。

SlidyでShift+Spaceを使えるようにするUser JavaScript

JavaScriptによってHTMLでプレゼンテーションを行うためのツールとしてW3CのSlidyがある。W3Cの人がプレゼンテーションを行うときには十中八九これが使われている。同種の他のツールに比べれば随分見やすいと個人的には感じているツールだ。

が、一つだけ問題がある。Shift+SpaceとSpaceの動作が同じなのだ。しばしばShift+Spaceで戻ろうとして、次のスライドへ進んでしまい、苛つくことがある。

というわけでやっつけでShift+Spaceで前のスライドに戻れるようにするUser JavaScriptを書いた。考えるのが面倒だったので関数をざっくり入れ替える魔法を使った。今楽になればそれだけで十分だったんだ。

Opera Mini 4 BetaとOpera 9.5

斉藤さんのエントリーにOpera開発者の一人Mitchmanがコメントを寄せている。Core-2という名称とレンダリングエンジンの関連についての捕捉なのだが、その流れでちらりとOpera Mini 4やOpera 9.5に使われるレンダリングエンジンKestrelが取り上げられている。

「Core-2」は単なるレンダリングエンジンではなく、コアとなる基盤(core platform)です。Core-2は、初期の形ではあるものの、Merlinにも使われていました。Opera Mini 4はとても新しいCore-2のコード(今もなおレイアウトエンジンとして「Presto」を使用しています)を使用しています。また、Kestrelにはこれと同じCore-2のブランチが使用されるでしょう。

要するにこういうこと。

• Core-2 ⊃ Presto
• Opera 9.0(Merlin)にも、Opera Mini 4にも、Core-2が使われている
  • もちろん同じCore-2が使われているわけではない

でも、そんなことはどうでも良い。気になるのは最後の一言、the same core-2 branch that kestrel will useだ。sameというからには、Kestrelコアのブランチは既に切られているのだろう。そして、そのブランチをベースとしたOpera Miniのベータが公開されている。Opera Mini 4 Betaをそういった観点から使い倒してみるのもおもしろいかもしれない。

Docufarmへのリンクに書き換えるブックマークレット

Hidetoさん経由でDocufarmなる素晴らしいツールを知った。WordやPowerPoint、Adobe Readerといった重量級ソフトを起動せずにすみ、憂鬱感が多少和らぎそう。

Docufarmで開ける形式をリンクから適当に判別している。

• Wordのdocファイル
• PowerPointのpptファイル
• AdobeのPDFファイル
• リッチテキスト形式のrtfファイル
• ポストスクリプト形式のpsファイル

とりあえずUserJSを作ったのだけれど、これらのファイルに出会うのは稀なので毎回処理される必要はない。……というわけで、ブックマークレットにしてみた。

• 対応ファイルへのリンクをDocufarm経由へ書き換えるブックマークレット

適当なニックネームを割り当てれば幸せになれる気がする。

menu要素型とnl要素型とnav要素型

Re: Re: XHTML+CSS (r)evolution, 3rdの内容は信ずるに値するか?は案外興味のあるところなのかなぁという事で簡単にmenu、nl、navの大きな違いだけざっくりと紹介する。網羅的な紹介ではないので、細かいところは各自仕様書を参照していただきたい。……というか、やっつけで書いた表なので、ニュアンスで適当に解読していただきたく。

とりあえずこの辺は理解しておいた方が良い。

• menu要素型はつかいものにならない
• nl要素型とnav要素型は目指すものが違う

ロッカージェスチャこそ必要

Firefoxユーザに対するマウスジェスチャについてのアンケート結果を見て驚いた。FlipBackに意義を見いだしていない人が多数を占めている。

Q3. ロッカージェスチャ機能（右クリックしながら左クリック）は必要ですか？

回答	回答数
はい	56
いいえ	116
わからない	27

必要かと問われて必要だと答えるのは利用者だと推測できる。そうすると、利用しない人が143人居るのに対して利用する人は56人ということになる。

この母集団が実際にマウスジェスチャを実現するために用いている方法は以下の通り。

Q1. あなたはマウスジェスチャの拡張機能を使っていますか？

実現方法	回答数
All-in-One Gestures	77
Optimoz Mouse Gestures	9
userChrome.js	99
使っていない	14

userChrome.jsで弄ってしまうような上級ユーザも、ロッカージェスチャは要らないとしているのだろうか。この2つの質問のクロス集計結果を見てみたいものだ。

自分の感覚だと、普通のマウスジェスチャは手を動かすのが面倒で、ただクリックするだけのロッカージェスチャ(FlipBackやFlipForward)が重要だったりする。

複数ページ戻るとき、ロッカージェスチャ(FlipBack)ならマウスの右ボタンを押しながら左ボタンを連打すればよいが、マウスジェスチャだとそうはいかない。右ボタンを放したり、少しずつマウスを左にずらしたりと面倒だ。

Operaユーザに対してこのアンケートを実施したら回答がずいぶん変わるだろうと思う。十中八九ロッカージェスチャの必要性に関する項目は逆転するだろう。

是非やってみたいけど、どうやってアンケートするのが簡単で、妥当なんだろう。

• ロッカージェスチャこそ必要…?

XHTML+CSS (r)evolution, 3rdの内容は信ずるに値するか?

XHTML+CSS (r)evolution, 3nd スライド・音声データ(原文ママ)も公開されたようですので、今回のプレゼンテーションに対して補足と説明を加えておきましょう。プレゼンの内容をほとんど否定しているのは気のせいということにしておきます。公開されているスライドPDFと併せてご覧になると良いでしょう。

この文書が長いと思う人は見出しだけ読めば良いでしょう。概略はつかめるはずです。HTML 5はそれほどに無茶苦茶な提案ではありません。

Reinventing HTMLは全くの作り直しではない

HTML 5を世間が最初に知るきっかけとなったTim Berners-LeeのReinventing HTMLというエントリーがある。益子さんはこのエントリーに含まれるinventの語義に最初から作り直すという意味があることを指摘し以下のように述べた。

……つまりrevise、単なるこうちょっとした修正というよりは、reconstruct、再構築のために作り直す、一旦、こう、潰して作り直すっていう本当にこう、drasticな改訂という風に考えて良いと思います。……

思いますなんて曖昧な表現はやめてほしい、という話はさておき、再構築の本当の意味については、ディスカッションにてW3Cのカール氏が説明していた。その内容は文字起こししてある通り、内容的なものではなく体制の一新といったところだろうか。

内容が本当に作り直されているのかについては実際にHTML 5仕様の目次をみてみると良い。3. Semantics and structure of HTML elementsがほぼ既存のHTMLに該当する部分だ。リンクタイプの定義が4.4.3. Link typesにあるなどといった例外はあるが、ほぼそれで網羅することができる。

ここには知らない要素もいくらか登場する。だが、既存の要素のほぼすべてはそのまま残っており、基本的な概念は変わらない。drasticな、徹底した改訂という印象を受けるほどではないと思う。

HTML 5はそもそもXHTML 2より既存のHTML仕様、つまり最新版であるXHTML 1.0やその元となった非XMLベースのHTML 4に近いものだ。それが全くの作り直しになるはずもない。

なお、新たに追加定義される内容については追加定義される多数の要素の項で少しだけ紹介している。

XHTML 1からXHTML 2への改訂がdrasticだ、と言うのであれば何となく理解できる。妥当で想定される範囲の改訂だが、既存の仕様と比較すると大きな違いを感じる人が居てもおかしくない。

Web Applications 1.0がHTML 5の名称へ変更された理由

Ianが5月9日にWHATWGのMLへ投げたメールに書かれている内容の冒頭を稚拙ながら訳しておこう。

本日、W3CのHTMLワーキンググループはWHATWGが現在進めている著作物を始めることを決議した。明確に、グループは我々の作業を再検討することを決議した。十中八九WHATWGが現在進めている著作物に基づいてHTMLの議論を進めることとなるだろう。

また、彼らはこの著作をHTML5と呼ぶことも決議した。

従って、「Web Applications 1.0」仕様は今、公式に「HTML5」と呼ばれるのだ!

名前が変わったのはW3CのHTML WGでの議論を受けてのことと考えるのが妥当ではないだろうか。このようなメールが流れているのを見る限り、益子さんの唱えるHTML 5の名称の方が有名になったからという理由が妥当とは考えにくい。

なお、表題の記録は5月10日0時56分のRevision 799からヘッダが別ファイルに分離されたのを最後にトラッキングすることができなかった。しかしこのRevision 799はIanのメールが投げられる後の更新である。そして、この更新時にはまだWeb Applications 1.0と呼ばれていたようだ。

著作権情報が付加された理由

今回のイベントでは著作権情報として記載されている内容から益子さんが類推した内容は語られたが、なぜ著作権情報が存在しているのかについては一切語られなかった。これについてはマイコミジャーナルがうまくまとめているのでそれを参照するとよいだろう。

追加定義される多数の要素

要素名だけ紹介するのはあんまりでしょう。数だけ紹介してもその意義は全く伝わらない。HTML 5はただ複雑になっただけという印象を与えるだけだ。だが、HTML 5はただ複雑になっただけではない。具体例をいくつか紹介しよう。

先日公開したエントリーのURIがhtml5-dis-eventであるのはここに由来していると言っても過言ではない。HTML 5の説明すらしていないじゃないか。

文字コード指定の簡略化

HTMLでは文字コードを指定するためにcontent-typeを記述する。ここに疑問を抱いたことはないだろうか。今まさにHTMLを書いているのに何故HTMLであることを明示しなくてはならないの、今指定したいのは文字コードなのに、と。

HTML 5ではmeta要素にcharset属性が導入される予定だ。これが導入されれば今まで<meta http-equiv="content-type" content="text/html; charset=utf-8">などとまどろっこしい記述を強いられていたのが、<meta charset="utf-8">とだけ記述すればよくなる。

もちろん実装されるまでの期間は併記する必要があるだろうが、この程度の実装が長々と放置される可能性は決して高くないだろう。

HTTP通信中に得られたcontent-typeに含まれる文字コード情報と文書中にcharset属性で記述された情報が矛盾している場合の処理についても、その処理順がきちんと仕様に明記されているため安心だ。

フッタの明示

フッタに使われうる要素としてaddress要素型がある。かつて論文を公開するにはこれで事足りていたのかもしれない。しかしこれが今の用途を満足させるものではないことは、説明するまでもない。

多くの人は<div class="footer">などとマークアップしている。だが、こんなことを考えたことはないだろうか。

• 何らかのマークアップによってこのブロックが本文でないことを明示せねばならない
• フッタに対して見出しを振るのは妥当だろうか
  • 見出しを振るとどうしても本文の見出しと同じ階層で処理されざるを得ない
• hr要素を前に置くことで伝えられるかもしれない
  • 本文中に使われるhr要素も存在する
  • hrは本文との関係性を断ち切るには力不足
• 見出しとhrを併用したらどうだろう
  • hrを入れたからと言って見出しの木構造が断ち切られるわけではない

HTML 5は、新しくfooter要素型を定義することでこの悩みを解消してくれる。さらに、ここには見出しの類を中に含んではならないと定義してある。もう悩む必要はない。ただfooter要素でマークアップするだけだ。

会話文のためのdialog要素型

資料ではdialog (会話文)とだけ説明されている。これだけをみると別にdl要素で良いじゃないか、と思うかもしれない。だが、ちょっと待ってほしい。

実際に会話文のマークアップを考えてみよう。多くの人は次のようなマークアップを想像するだろう。

<dl>
  <dt>鈴木</dt>
  <dd>今日田中が<q>調子悪いから休む</q>って言ってたよ</dd>
  <dt>佐藤</dt>
  <dd>そうなんだ</dd>
</dl>

しかし、会話の内容はそれ自体が文書にとっては引用で、話し手はその出典である。そう捉えると、以下のマークアップの方が妥当だ、と思えてこないだろうか。

<dl>
  <dt><cite>鈴木</cite></dt>
  <dd><q>今日田中が<q>調子悪いから休む</q>って言ってたよ</q></dd>
  <dt><cite>佐藤</cite></dt>
  <dd><q>そうなんだ</q></dd>
</dl>

どちらが妥当かという論議はさておき、HTML 5のdialog要素型はこれをスマートに解決している。

<dialog>
  <dt>鈴木</dt>
  <dd>今日田中が<q>調子悪いから休む</q>って言ってたよ</dd>
  <dt>佐藤</dt>
  <dd>そうなんだ</dd>
</dialog>

HTML 5のdialog要素型の項では以下のことを明記している。

• dialog要素内のdt要素の中の文字列は後続するdd要素の中で与えられる文字列の出典を暗示する
• dd要素のコンテンツは暗黙のうちに話者からの引用であるとする
• (会話文をマークアップする上で)このマークアップの中にciteやq、blockquote要素を含む必要はない
• dialog要素内のdd要素の内側のq要素は、その人の会話が誰か他の人の引用であったことを実質的に暗示する

dl要素でのマークアップより素直だと感じてこないだろうか。

canvasの実装状況の誤り

イベント中ではFirefox 1.5とSafariで実装されていると述べられていたが、Opera 9も実装している。もっともこの件はWebで公開されている資料では、さりげなく修正されているようだが。

videoの実装状況の誤り

先日公開したエントリーで補足した通り、Opera 9.2 Betaにvideoは実装されていない。videoが実装されたのは実験的ビルドである。

jp.opera.comなどからダウンロード可能なOpera 9.2では、資料に記載されるhttp://people.opera.com/howcome/2007/video/opacity.htmlを参照しても、何も起こらない。Haavardの紹介する通り、video要素が実装されたのはlabs.opera.comで公開された実験版である。

この実験版をOpera 9.2 betaと呼ぶのは誤りである。Opera 9.2 ベータというバージョンは別に実在しており、その更新履歴にもvideoが実装された旨は記載されていない。言うまでもなく先の実験的ビルドとこのOpera 9.2 ベータは別のものなのだから。

ポイントとして挙げられている内容が謎

まず、スライドからポイントとしてあげられていることを引用する。ポイントは大きく2つに分けられるだろう。

まずはXMLの話。

• XMLワールドではXHTMLは単なるボキャブラリ集のひとつ
• XHTMLもXMLベースで開発されるならやはり単なるボキャブラリ集のひとつ
• 今後の(X)HTMLはひとつの言語体系というよりさまざまなXMLアプリの複合文書と考えるべき
• 複合文書=Compound Document
  • WebページへXHTMLのボキャブラリを提供
  • WebページへSVGのボキャブラリを提供
  • WebページへMathMLのボキャブラリを提供

そして仕様を拡張する具体的な方法に関する話。

• id/class志向(W3C仕様を尊重)=microformats
• 要素/属性志向(W3C仕様を逸脱)=HTML 5

HTML 5にはXMLベースもある

スライドの14枚目に記載されている内容をそのまま引用する。

An extensible, serialized form of such a language, using XML.

A serialized form of such a language using a defined, non.XML syntax compatible with the 'classic HTML' parsers of existing Web browsers.

(XMLベースだけでなく非XMLベースにも対応。前方/後方互換性の確保)

これはまさにその通りで、HTML 5にはXMLベースのものと非XMLベースのものが用意される予定だ。従ってXMLワールドに於いてはHTML 5も単なるボキャブラリ集のひとつとして扱えると考えるのが妥当だろう。もちろん複合文書として扱うこともできるようになると推測される。

ドラフト草案すら公開されていない仕様であるため推測以上のことを語ることはできない。しかし、これだけは言っておきたい。私にはなぜここにきてXMLの話がポイントになるのかさっぱりわからなかった。HTML 5もXMLとして扱えると自分で述べていたではないか。質疑応答で問おうと思っていたが、その時間は残念ながらとられなかった。

何が仕様の逸脱なのか

HTML 5の仕様が定義され、それに従って文書を作成し、HTML 5で定義される新しい要素や属性を使う。これの、どこが仕様の逸脱だというのか。まさか勧告すらされていないHTML 5の要素や属性を、既存の文書型定義に基づいた文書で利用することに関して発言しているのだろうか。それならば確かに逸脱だが、それは当然である。

microformatsとHTML 5を既存仕様の枠組みで比較しても無意味

microformatsは現時点の仕様に則ってsemantic Webを実現しようとする素敵な試みだ。しかしそれは新しい言語であるHTML 5と比較すべき対象ではない。microformatsはAbout microformatsに書かれているとおり新しい言語ではないのだから。

microformatsと比較するのはナンセンスとしか言いようがない。

比較すべき対象はXHTML 2

HTML 5と比較されるべきはXHTML 2だ。どちらも今策定途中であり、現行のHTMLに代わることを目指す仕様だ。

思えば今回のプレゼンにはXHTML 2という単語がほとんど出てこなかった。不思議なものである。

意見諸々

利点と欠点の両方を提示すべきだ

いま話題の「HTML5」とHTMLの再開発という題目で行われているにもかかわらず肯定的な話を一切せずに終始否定し続けるのはいかがなものか。聴衆が再開発について考えるにはあまりに情報が偏りすぎている。端的に言ってしまえば、これは情報操作に近い。

僕もそれほどHTML 5について知識を持ち合わせているわけではないので、利点と欠点は他の人の資料を見ていただこうと思う。

HTML 5の利点

たとえばOperaからHTML WGに参加しているAnneが次のような資料を用意している。英語のプレゼンテーション資料(Opera Show)だが、簡潔にHTML 5の利点がまとめられていると考えられる。

• QUTでAnneが行ったプレゼンの資料「Evolving the Web: HTML5」
• reboot 9.0でAnneが行ったプレゼンの資料「HTML5: Incremental Improvements to the Web」

HTML 5の欠点

たとえばUAIアクセシビリティセミナーで梅垣さんが行ったプレゼンではXHTML 2を前提としているWAI-ARIAと、W3CのHTML系列の新しい仕様開発との関係を懸念事項として挙げていた。これはHTML 5の仕様如何では問題になるだろう。

実装先行より仕様先行が好ましい

益子さんのプレゼンテーションでしばしば繰り返し述べられていたのは以下の主張であった。

1. 実装が行われていない仕様は使われない
2. HTML 5が定義されても実装されると思えない
   • ディスカッションから、既存の仕様で十分であるという思想が根底にあると推測できる
3. 従ってHTML 5は不要である

もちろん永久に実装されることのない仕様に価値はない。しかしHTML 5は本当にそうだろうか。今回のプレゼンテーションでは実装されないという主張を多く口に発していたが、その根拠は提示されなかった。

むしろcanvasなどが実装されていることを紹介していた。紹介されていない部分ではOpera 9のWeb Forms 2.0の先行実装が挙げられる。Web Forms 2.0はHTML 5に含まれるだろうとされるフォームの拡張案である。これもHTML 5の実装といえる。

HTML 5はまだ策定が始まったばかりの新しい仕様だ。長期間公開された状態で議論が進むからこそ徐々に実装が進んでゆくのではないだろうか。そして一部は既に実装されている。

これが仕様を先に策定することを否定しているのだとしたら、とんでもないことだ。それは健全な競争を阻害することと相違ない。せっかくWebブラウザに競争が生まれつつあるというに。仕様が先に策定されないと云うことは、実装がすべてということ。つまり、実装を持ってそれが仕様となる。その仕様すら公開されない場合、実装を元にほかの環境が似て似つかぬ実装を行うことになるのだ。公開されたとしても、実装までの期間には相当な差が生まれることとなる。

むしろHTML 5やXHTML 2の仕様が先に決められゆく流れは良い傾向だと思うのだが。

同様に仕様が先に定義されつつあるXHTML 2についても若干補足しておく。XHTML 2ではフォームとしてXFormsを採用する予定である。この実装は、着実にMozilla内で進められているのだ。

既存のHTMLで事足りない分野もある

一応コンテンツを作成することはできるし、それを一般的なユーザは利用することができる。だが、Webアプリケーションのアクセシビリティなどを考え始めると全くもって十分とは言い難い事実に気づく。WAI-ARIAなどはそれを白日の下にさらしている好例だ。

WAI-ARIAが遠くのものに感じるのであれば、ユーザスタイルシートの定義を考えてみると良いかもしれない。HTML 5にはsectionやfooter、navなど、様々なSectioning Elements(セクション化要素とでも呼ぶのが良いだろう)が定義されている。セクション化要素の多くは今まで多くのページでdiv要素に適当なclass名を与えていたブロックだ。これらがはじめから用意されるようになる。これがきちんと利用されるようになれば、ユーザ側でのスタイル操作が容易になることは想像に難くないだろう。

classやidでは何も定義できない

ディスカッションで挙げられたul要素型とol要素型をまとめてしてしまえばいい、という提案を題材に使おう。

以下、ul要素型とol要素型をまとめた要素型をlist要素型と呼ぶことにする。list要素型としてまとめたとしても結局ul要素型(順不同リスト)やol要素型(順序付きリスト)に当たる何かを、たとえばclass名などとして、どこかに定義することとなる。

なぜならば、HTMLのボキャブラリ内でリストの扱いを判断できなくなるからだ。たとえばリストを50音順にソートし直すことが妥当かどうか、どこかで定義されていない限り判断することができない。スライドにもあるとおり、XHTMLは単なるボキャブラリ集のひとつだ。ボキャブラリとして活用するためにはそのボキャブラリの中にリストの扱いが定義されていなければならない。

具体的な弊害としてはユーザスタイルシートの作成ができなくなるといった事例を挙げておこう。

list要素型はスタイルシートで表現することだけできる。言い換えてみよう。list要素型はスタイルシートで表現すること以外何もできない。

結局どこかで定義するのであれば、既に色々な人が気ままに活用しているclass名より、新たな要素として定義した方が応用しやすい。class属性の値は、たとえ同じでも、他の誰かが、他の用途のために使っている場合がある。そのようなマークアップをデータとして永続的に使うのは不便この上ない。

これはmicroformatsの否定とも言えるかもしれない。microformatsは確かにおもしろい試みだし、現実的な解の一つだとは思う。が、永続的に続くとは思っていないし、そうあるべきではないと考えている。

ついでに極論も書いておこう。もし本当にclassやidで事足りるなら、本文のマークアップのための要素型としてHTMLにはdiv要素型しか定義されなかったかもしれない。何でもclassやidで示せばいいのだから。

classやidによる拡張は可能だが、それは共有することが困難な拡張だ。はじめから多くの人が似たようなものを必要とするのであれば、それははじめから定義されていた方がよい。わざわざ勝手に拡張させる必要はないのだ。(必要とされていても定義すべきでないものも存在するけれど。)

• XHTML+CSS (r)evolution, 3nd スライド・音声データ

• XHTML + CSS (r)evolution vol.3の骨子

• XHTML+CSS (r)evolution, 3rd について
• Re: XHTML+CSS (r)evolution, 3rdの内容は信ずるに値するか?

XHTML + CSS (r)evolution vol.3の骨子

益子さん主催のXHTML + CSS (r)evolution vol.3と云うイベントに足を伸ばしてきました。題目はHTML 5の概要、との事。取り急ぎ骨子を紹介いたします。なるべく実際の表現を尊重してメモをとるよう心掛けましたが、誤りを含む可能性があります。

私見を述べるのは、またの機会にでも。関連エントリーとしてXHTML+CSS (r)evolution, 3rdの内容は信ずるに値するか?を公開しました。私なりの結論を述べるとこのイベントの内容は信じるに値しないと考えます。

なお、このエントリーを読む方には途中で止めず、対談後半のW3Cの主張もきちんと読むことを強く推奨します。この部分については公開された音声を文字起こしし、書き改めました。十分正確な情報を得ることができるようになったと思います。

益子さんのプレゼン

• HTML 5のきっかけはtbl
  • 彼がブログへエントリーを投稿した
• reviseではなくreconstract
  • 作り直しと考えていいと思います
• 最初のドラフトは今年の7月の予定
  • 出せるのかな、という感じですけどね……とのこと
• 2010年に勧告の予定
  • (今と)3年後で状況が変わっていて(完成したときにHTML 5は)使えるのでしょうか
  • 新しいHTML(5)のニーズがないのではないかと思っています
• (これは)1つの独立した仕様をつくるというもの
• XMLベースの仕様だけでなく従来の非XMLも
• DOMやUIの内容も盛り込む
• W3Cの方も居ますが本音トークで行かせていただきます
  • W3Cから4名の方が来られていた
    • validatorのメンテナンス担当のオリビエさん
    • QA(品質保証)担当で最近はHTML WGのコンタクト(平たく言えば雑用らしい)を担当しているカールさん
    • モバイルイニシアチブのマイクさん
    • 広報担当の平川さん
• HTML 5の仕様は結構頻繁に更新されているようです
• 昔はWeb Application 1.0という名前で通称がHTML 5でした
  • 通称だったHTML 5がタイトルになった
  • そっちの名前が有名になったから(名前を変更した)?
• コピーライトが増えた
  • (並ぶ社名から)ブラウザベンダーが支えているといえる
• GoogleのIanと元W3Cの石川さん、平川さんとで話す機会があった
  • IanはGoogleの代表としてではなく個人としての意見をHTML WGへ投じている
• HTML 5はWHATWGが作っている
  • W3Cとは別のところ
• HTML 4、XHTML 1、DOM 2 API、Web Forms 2などの新仕様に当たる
• アプリケーションとしてHTMLを捉えている
  • 仕様として(明確に)決めたい
• XHTML 2には非文書型コンテンツのための要素が足りない(という考えがHTML 5の根底にはある)
• UI言語からは独立した存在
  • XUL、MXMLなどはベンダーが提供すればよい
• 例えば……(と、追加予定の要素型名を紹介していた)
  • XHTML 2と共通のsection要素を追加
  • ナビゲーションを示すnav要素
    • XHTML 2ではnl要素
  • すでに実装されている例
    • canvasはFirefox 1.5やSafariで実装されている
    • videoはOpera 9.2に実装されている
      • メモをとった人間による補足。videoが実装されたのはOpera 9.5のテクノロジープレビュー版(HaavardのTry Opera with native Theora video supportを参照)です(ただしバージョン表記には9.2とあるためこれは一応Opera 9.2であると言えなくはない。しかしOpera 9.2正式版には搭載されていない点やOpera 9.5を類推させるファイル名である点からOpera 9.2に将来的な実装へ向けた機能の一部を仮に組み込んだバージョンと捉えるのが妥当でしょう。少なくともこれをOpera 9.2と呼ぶのは間違っていますし、いわゆるベータ版でもありません。)。また公式にOpera 9.5でvideoをサポートするという発表も私は聞いたことがありません。テクノロジープレビュー版で実装が行われた事実がある、と捉えるべきでしょう。
    • canvasでぐりぐり3D描画できる
    • HTML WGはWHATWGと協調している
      • Ian曰く温度差はある
      • Ianも2010年(に勧告)と云うのは現実的でないと述べている
    • (仕様が定義されることより)浸透することが重要でそれには時間がかかる
• 以下(益子さんの)まったくの私見ですが、
  • ブラウザベンダはXHTMLに不満があるのではないか
  • tblの焦りではないか
    • 自分が作ってきたHTMLを他の人に触らせたくないのではないか
    • W3Cの中でやって欲しいのではないか
• (HTML 5の仕様が)実現した時に存在理由はあるのでしょうか
• Ianや石川さんがこの流れはHTML 3の時に似ていると言っていた
  • HTML 3は幻の仕様
  • 結局HTML 3.2が勧告された
• 神崎さんも枯れた技術をいじる事はないと言っていた
• XMLの世界ではXHTMLやRSS、Atomは全て単なる語彙
  • HTMLもXMLベースなら単なる語彙
• 今後の(X)HTMLは言語体系と言うよりXMLアプリとの複合文書と考えるべき
• id/class志向
  • microformats
  • W3Cの仕様の範疇
• 要素/属性志向
  • HTML 5
  • W3C仕様の逸脱
• HTML 5は本当に必要なのか
  • その結論はトークセッションで

トークセッション

益子さん、中村さん、植木さんのディスカッション。トークセッションの書き取りはメモは割と手抜きなため、あまり信じない方がいい。参考程度に。

印象

益子さん

HTML 5の印象は?

植木さん

まだドキュメントをきちんと読めていない(ので何ともいえない)

(今回を受けての)正直な印象としては右から左へ受け流すのがいいのかな

中村さん

一通りドキュメントには目を通していた

まだ読み切れてはいない

使用書に出てくる語をクラス名として活用することはできると思う

勧告されていないので使うかどうかはわからない

益子さん

Googleがclassやidの一覧を公開している

同じ感じで使えそう

再開発は要りますかね?

中村さん

XHTMLに慣れちゃったからね

益子さん

もう結論が出てしまいましたね

簡単なHTML

益子さん

リスト3つも要らなくない?(listを示す要素を一つ作ってあとはクラスでやればいいという意見)

中村さん

HTMLは簡単だから普及したと思う

(HTML 5のように)複雑になったらその利点はなくなると思う

(益子さんと)昔(要素を)減らせばよいと話した

益子さん

(その方が)逆転の発想でいい

中村さん

role属性で補った方が書きやすいのでは(ないかと思う)

益子さん

基本がシンプルなほど拡張性は高くなりますよね

アクセシビリティとHTML

益子さん

植木さん何かありますか

植木さん

アクセシビリティの(観点)から言うとXHTML 5でもよい

日付を5/31と書くと分数として読み上げるのが一例

このように(機械で処理できない)曖昧な情報をマークアップできるようにせねばならない

(その方法は)classでもidでも要素でも属性でも何でもいい

(仕事で)ツールを作ることがあるが実際(これらを判別するのは)難しい

益子さん

人間の判断が要りますよね

植木さん

HPRはその後分数読みをやめたら今度は逆の苦情がくるようになった

bAの小久保さんがWebは唯一ユニバーサルデザインを実現できるメディアだと言っていたがそれをうまくキャッチするものが必要

益子さん

W3CにDatetimeフォーマットがあるけれど日本なら日本らしい表現(5月31日など)がありますからね

植木さん

今WGがありますが(こういった)言語ごとの対応をきちんとしてほしいですね

W3CとHTML 5

公開された音声データを元にこの話題に関してのみテキスト起こしを行い、初稿の内容と差し替えました。

益子さん

W3Cの平川さんせっかくきてるんで、聞きたかったのが、HTMLの再開発、W3Cのスタッフとして、乗り気なのかどうか。

会場

(失笑)

益子さん

いや、実は重要なんですよね、やっぱり。

平川さん (W3C)

カールさん……

カール (HTML WG)

(日本語は難しい、と前置きして英語で話し始めた)

平川さん

W3Cのスタッフとして、我々はやらなければいけないことは、Webに関わっている人たちの意見やコミュニティの意見や、ベンダーとかが関わっているマーケットとして、市場としてのWeb空間のニーズに応えることが我々の目的であると。という意味で我々は是非これは進めていきたい。そのかわり決定をするのはコミュニティでありマーケットであるので我々が何か方向性を形づけることはないし、むしろそういういろんな人たちの意見が集約されたところに答えが出てくる、ということ。

一応彼の自己紹介を入れますと、彼は……自分でやりますか?

カール

(英語で自己紹介し、その後に意見を語り始めた)

平川さん

HTML 4の前の状況ではそのベンダーないしブラウザベンダーさんが実際に実装したものが仕様というか技術……

益子さん

そうですね、HTML 4まではそうでしたね、4まではブラウザベンダーの独自拡張を仕様に、こうまとめてるっていうのが一つの仕様の作業でしたけども、そっからW3Cがじゃあうちの仕様を逆にブラウザベンダーが準拠してねという方向に変わった、と。

平川さん

で、単に要素がどれかっていうのもそうですし、各要素の解釈の仕方。表示の仕方もそうですし、pってなんだろう、pタグってなんだろうっていう、そのセマンティクスの部分も今までは実装してた人たちが勝手に決めていたと。でもこれからはWGなりそのコミュニティの中できちっと議論をして、その部分をちゃんと詰めてゆきましょう。それがre-inventの意味なのではなのかなぁ、と。

で、この議論の最後、かどうかわからないんですけども、一応付け足しておきますと、新しく始まったHTMLのWGは、一般の人も参加できるようなグループとして立ち上げられました、ですのでここにいる皆さんが個人としてW3CのWGに参加して、意見を、大企業の一意見と同じように発言することができるように、なりました。日本からも個人という形で、いまちょっと人数はわからないんですけども、2桁にいくくらいは入ってるんじゃないかなと思うんですけども……

益子さん

あー

平川さん

世界中からは400とか……

益子さん

HTML WGだけで?

平川さん

(HTMLの)WG1つに400とか450ぐらいの人たちが参加して居るんですけども、世界中からですね。ということで、ここにおられる皆さんの意見を、HTMLを再開発したいと思う人もいればしたくないと思う人もいると思います。だからその1つの意見を伝えていくこと、標準のプロセスに乗せていくことっていうことが一番重要なことじゃないかなと思うんですね。是非皆様にご参加いただきたいと思います。あの、英語での議論になるのでちょっと大変なところもあると思うんですけれども、日本語に長けた、じゃなくて英語に長けた日本人の方もグループに参加されてますので、そういった人たちとある程度協調しながら参加されることもおもしろいのではないかなと思います。是非ご検討いただきたいと思います。

HTML 5と現実

益子さん

エンドユーザとして(HTML 5の)影響は大きい

ブラウザがサポートしなかったら(新しい仕様は)使われないけど

中村さん

古いもの(既存のHTML)も使える(ので)便利なら(HTML 5も)使おうかなと(思っている)

益子さん

DOMは(どうですか)?

中村さん

あまり変わらない

むしろ早くブラウザがDOMを(きちんと)実装してほしい

念のため

このエントリーは単なるメモの書き起こしであり、Operaの件の補足一点をのぞき私見を一切挟んでいない……つもりです。もし実際の資料との相違がありましたらそれは私の本意ではありませんので本来の資料をご参照ください。話によれば実際に用いた資料を昼頃までにはアップしていただけるとのことです。

私見を述べ始めるとまぁ長くなりそうな感じですね。誰かが書いてくれることに期待しつつ私は床につきます。お休みなさい。

• XHTML+CSS (r)evolution, 3rdの内容は信ずるに値するか?

OperaでIEのように選択フォルダのブックマークだけ表示する

IE 6のお気に入りエクスプローラーバーのような使い心地を他のブラウザで実現したい、という人が少なからずいるようなので、その辺りの話を少しだけ。結論から言うと、Operaの場合2画面分割表示を利用するか、マウスジェスチャを活用すると良い。

何が違うのか

手元のIE 6ではあるブックマークフォルダAを展開した状態で他のブックマークフォルダBをクリックし展開すると先ほどまで展開されていたフォルダAの木が閉じてフォルダBの木が展開される。

いちいち閉じるのが面倒だ、という人にとってはこの方が使いやすいのだろう。私にしてみればフォルダを展開したときにマウスポインタがそのフォルダを指してくれず、相対位置で操作できないことの方がずっと辛いのだけれど。

勘の良い人は察しているだろうが、手元のIE 7ではそのような動作をしなかった。FirefoxやOpera同様、閉じない限りその木は展開されたままになる。クラシックシェルを利用していることが関係している可能性も若干あるが、おそらく動作の変更だろう。この動作の方が、自然だ。

必要なこと

このような動作を実現したいと思い立つ理由は以下の通りと推測できる。

• いちいちフォルダを閉じるのが面倒
• 余計なものを見たくない

この位なら、代替案で十分。

2画面分割表示

その代替案が2画面分割表示。ブックマークパネルで右クリックし、表示の下で2画面分割表示を選択すればよい。これでブックマークパネルが上下に分割して表示されるようになる。

2画面分割表示では上にフォルダのツリーが、下にフォルダ内の項目が表示される。フォルダの移動は上下どちらでも可能だ。これなら1つ以上のフォルダを同時に表示することはなく、余計なものを見なくて済む。

IE 6のようにほぼ全体を使ってフォルダ内の項目を表示するわけではないため、フォルダ内に多くの項目が並んでいる場合は見にくい。しかしきちんとフォルダ分けが細かくされているのであれば各々のフォルダ内の項目は少なく、フォルダの数が多くなるはずだ。そのような場合、フォルダだけをリストアップすることができる2画面分割表示の方が使いやすい。

ちなみに数年前のOperaの初期状態はこの2画面分割表示だった。それが今のような形に変更されたのは、それだけ2画面分割表示が馴染みにくいものだったという現れなのかもしれない。

マウスジェスチャでフォルダを開閉する

フォルダをクリックして閉じるのが面倒、という話であればマウスジェスチャを使えばよい。戻るためのジェスチャでフォルダを全て閉じ、進むためのジェスチャでフォルダを全て開くことができる。

一回全てのフォルダを閉じてから任意のフォルダを開くようにすれば、ほぼ同じ操作感となるだろう。

フォルダ間のブックマーク移動を考えると、開いておくこともできた方が汎用的で使い勝手はよいように思う。

戻るためのマウスジェスチャ

←

マウスの右ボタンを押した状態で左クリック

進むためのマウスジェスチャ

→

マウスの左ボタンを押した状態で右クリック

一方のボタンを押しながらクリックする動作をOperaではFlipBackやFlipForwardと呼び、Firefoxではロッカージェスチャと呼ぶことが多い。右ボタンを押しながらマウスを移動させる一般的なマウスジェスチャより軽快に操作できる。

Operaでタブを切り替える幾つかの方法

Operaを主にキーボード操作している人はタブバーに捕らわれる必要がない。この話はタブバーを消してみたら案外良い感じだったでも取り上げたが、一応補足しておく。ウィンドウパネルやウィンドウ一覧のメニューを活用しているだろうか。特にウィンドウパネルはマウスで利用している人にとっても役立ちうるものだ。せっかくの機会、タブの切り替えについて事細かに説明してみよう。

Operaはタブを切り替えるために様々な方法を用意している。よく知られている方法はこの辺りだろう。

• タブバーで任意のタブをクリック
• マウスの右ボタンを押しながらホイールを回転させる
  • タブの表示順に基づいて移動する設定になっている人が多いはずだ
  • Use Thumbnails in Window Cycleへチェックを入れてサムネイルを表示するようにしている人がいるかもしれない
• (Shift+)Ctrl+Tabキーを押す
  • 右ボタンとホイールとの組み合わせと同じ事が起こる

だが、こんな(いうなればhistoricalな)方法もある。

• 1や2キーを押す
  • タブバーでの表示位置に基づいて移動する
• ウィンドウパネルを用いる
• ウィンドウメニューの最下部に用意される一覧を利用する

ウィンドウパネルを使ったことがない人は一度ウィンドウパネルに触れてみると良い。簡単に説明するなら、ウィンドウパネルはタブバーの高機能版なのだから。

もしキーボード操作が中心なのであれば、これらのhistoricalな方法を一度試すべきだ。数字キーは比較的押しやすく実にOperaらしい。またその他2つは大きく操作性を高めるだろう。

ウィンドウパネル

ウィンドウパネルはタブバーの高機能版と言える。ドラッグ&ドロップでタブを移動させるなんてことは当然できるし、マウスポインタを合わせておけばサムネイルも表示される。では何が高機能なのか。その肝は2つある。

• 複数ウィンドウの表示
• クイック検索での絞り込み

複数ウィンドウの表示は、まぁタブをグループ化したい人が勝手に使っていればよい。重要なのはその下、絞り込みだ。標準状態のウィンドウパネルにはクイック検索欄が表示されていない。もし標準状態のまま使っているのなら、今すぐウィンドウパネルへクイック検索を追加すべきだ。

多数のタブを開く場合、その全て表示させることはあまり現実的ではない。もちろん不可能ではないが、タブを探すだけでも一苦労することとなる。ある程度ならタブを縦置きすることで対処できるだろう。だが、Operaユーザには多くのタブを開きっぱなしにする人が少なくないように思う。100程度のタブを開くことは私にとって日常のことだし、ある人は200以上開くと言っていた。画面の解像度にだって限界はある。表示する情報量が増えるに従って、一覧表示させることは非現実的となるのだ。表示しきれないものは探せなくなるのだから。そんな状況に陥ったとき、このウィンドウパネルでの絞り込みが役に立つ。

ウィンドウパネルでの検索は、ブックマークでのそれのようにURIなども含めた検索ではない。単にタイトルとの一致をとるだけだ。だが一期一会にも等しいWebブラウジング、タイトルの一致さえ取れれば十分なのだ。現にタブバーにはタイトルとfaviconしか表示されていないけれど、それで十分事足りているわけで。

クイック検索の追加方法

外観の設定画面から追加することができる。クイック検索はネットサーチカテゴリに分類されている。おそらく最上部に居座っていることだろう。それをドラッグ&ドロップすればよい。たったのそれだけだ。

toolbar.iniを直接編集するのであればこんな感じだろうか。

[Windows Panel Toolbar.content]
Button0, 228969467=New page
Button1, -1393253531=Stop | Reload, , , -1705826954
Quickfind2

追加したい箇所にQuickfindを追記し、続けて通し番号を振る。

ウィンドウ一覧メニュー

WindowsやLinux環境下では標準で非表示にされているが、Operaにはウィンドウ(タブ)の一覧を表示させるメニュー項目がある。それを表示させる方法を以下に2つ紹介しておく。どちらかを行えばよい。

• GUIからの設定方法
  1. メニューバーのツールから設定画面を開く
  2. 詳細設定タブのブラウジングを選択
  3. ウィンドウメニューを表示するにチェックを入れる
• opera:configのShow Window Menuにチェックを入れる

ウィンドウメニューの最下部には開いているタブの一覧が表示されているはずだ。このメニューの利点はただ一つ。全ての項目にショートカットキーが割り当てられていることだ。メニューさえ呼び出せばあとは目的のウィンドウ(タブ)のショートカットキーを押すだけ。

だが、これをそのままメニューから読み出すのはスマートとは言い難い。そこでこのメニュー呼び出しを適当なキーに割り振ってしまうのだ。そうすればいつでも2ストロークで任意のタブに切り替えることができる。もちろんメニューに表示しきれない分は2ストロークでアクセスできない。だが、その場合もエクステンダーメニューのショートカットキーを押すだけで、方向キーを押す必要はない。

ちなみに私はこれを以下のようにCtrl+0に割り当てている。ウィンドウパネルの呼び出しがCtrl+Shift+0であることに関連づけたというわけ。

[Application]
0 ctrl="Show popup menu, "Internal Window List""

蛇足だがCtrl+0に割り当てるアクションはShow popup menu, "Internal Window List"かGo to homepageしかないと思う。言うまでもなく後者は隠されたスピードダイヤルの10個目であるホームページを0番に割り当てるという発想だ。Ctrl+0は実に押しやすい。開けておくにはあまりにもったいないキーだと思う。

• タブバーを消してみたら案外良い感じだった

おぺらたんをテッちゃんに見せびらかすオフ

Opera東京オフィスにピザをおごらせるオフ無事終了。素敵なイベントを立ち上げてくれたTERRAZI、その他関係各位に感謝。次回は西で開催とのことなのでそのときは案内してくださいな。楽しみにしとります。

flickrへ2007-05-26の写真を20枚ほど挙げておきました。最初の一枚からスライドショーで辿ると見やすいのかもしれません。フォトセットとやらが良いらしいので作ってみました。無料アカウントは3つまでらしいのでフォトセットは時期に消えるかと思いますが、当面の閲覧には便利そうな感じです。

ついでに初めての一人作業(何)の動画も上げてあります。

他の人のエントリーを参照するのであればこの辺りから参照するとよさげ。

• 「Opera東京オフィスにピザをおごらせるオフ(仮題)」についてのまとめ (Opera PukiwikiPlus!)
• higeorangeさんの関連ブックマーク

一応僕がさっくり見て発見できた関連ページを幾つか参考までにリストアップしときます。沢山ありすぎて困るという人は弥助さんの雑感とマイコミジャーナルのOperaユーザの方が書かれた記事を読むと良い気がします。

• 「Operaにピザをおごらせるオフ」対策本部 (#japanese's blog)
• 「Operaにピザをおごらせるオフ」 (TERRAZI)

• Opera ピザオフ会終了！ (Choose Opera 日本支部)
• ピザオフ会・関連エントリ一覧 (Choose Opera 日本支部)

• 寒中を泳いだCEO・Tetzchner氏も登場 - Operaユーザーミーティング開催 (マイコミジャーナル)

• Operaピザオフレポート。 (karakara)
• How about some Opera-tan cake? (ma31 aka temp_h)
• 三行日記１３８（OperaピザオフでOpera CEOテッちゃん登場） (madarame)
• Opera オフ会・東京の部 (saito)
• Opera Tokyo Meet (saito)
• オフ会 (T)
• ピザオフ (takef)
• 07-05-26雑感 (yaske)

• karakaraさん撮影の写真
• saitoさん撮影の写真
• takefさん撮影の写真
• 私が撮影した写真

• テッちゃんとビデオチャット
• おぺらたんケーキの最期 1
• おぺらたんケーキの最期 2

Kestrel(Opera 9.5)とPeregrine(Opera 10)のまとめ

Opera 9.5およびOpera 10に関する情報を追いきれていない人向け。2007年5月4日に公開されたThe Next Wave: Opera 9.5 (Kestrel) and Opera 10 (Peregrine)と、そこからリンクされためぼしい文書の概要です。当該記事を既に読んでいる人にとって目新しい情報はありません。その他のソースに記載されている細かな情報には触れません。また、この記事はA blog? with Σαιτωでも簡単に取り上げられていたものであるため、そこからリンク先を丹念に読んだ方にとっても既知の情報です。

なおMerlinという語が出てきますが、これは現行Operaの愛称です。多くの場合Opera 9.2と読みかえて支障がありません。

引用文中および見出し中のリンクは原文へ、日本語概要文中のリンクはこの文書内の適当な箇所へリンクしています。適宜使い分けてください。

以下、まとめ記事であるThe Next Wave: Opera 9.5 (Kestrel) and Opera 10 (Peregrine)の概要を取り上げ、他に取り上げた記事を時系列に新しいものから順に紹介します。多数の引用が行われていますが、全て概要を日本語で説明していますので基本的に引用部分を読む必要はありません。

「The Next Wave: Opera 9.5 (Kestrel) and Opera 10 (Peregrine)」より

このエントリーは2007-05-04に投稿されたブログのエントリーです。以下にあるとおり主にKestrelへ的をしぼっています。

In this article we mainly discuss the upcoming Kestrel release as news on Peregrine is still very limited due to it's early stage.

リリース計画

Currently Opera 9.5, code named Kestrel, is planned for a golden final release this year, while the first preview of Opera 10, code named Peregrine, will appear at the end of this year.

• 今年中にKestrel(Opera 9.5)の正式版
• 今年末にPeregrine(Opera 10)の最初のプレビュー版

Kestrelとは

So what is Kestrel? A falcon. And also a warming up present from Opera Software. But you shouldn't take that too negatively, Kestrel is an in-between release, while Peregrine is the next major release (Opera 10). Kestrel will introduce some of the rendering engine changes from Peregrine which don't have a too high impact yet on the entire release.

• 否定的に言えば次のメジャーアップデートであるPeregrineまでのつなぎ
• レンダリングエンジンをいくらか変更
  • Peregrineで大幅な変更に驚くということは無い

Peregrineとは

Peregrine itself, also a falcon, will have major rendering engine changes (of course everything that's in Kestrel), improvements to the user interface, performance enhancements and stunning new features. What we can expect remains to be seen, but I'm betting on an entirely new skin, one that fits Windows Vista and Mac OS X 10.5 (Leopard), as well as features that, just like Speed Dial, will make the news headlines.

• レンダリングエンジンのメジャーアップデート
  • もちろんKestrelにも含まれる
• ユーザインタフェースの改良
• パフォーマンス強化
• 新機能の追加

AvencisはWindows VistaやMac OS X 10.5 (Leopard)に合った新しいスキンやニュースヘッドライン機能が追加されるのではないかと予想している。

レンダリングエンジンの改良

• CSS3のサポート
  • Upcoming CSS3 support in Operaに詳細
  • text-shadowのサポート
    • 複数の影へ対応
    • 最大ぼかしに制限あり
• KestrelでSVG Tiny 1.2の関数のいくつかをサポート
• document.getElementById関数がIEの様にnameを返していた問題の修正
  • 本来はidを返す
  • 詳細はBug: document.getElementById() returns element with name equal to id specified(原文)を参照
• 不正なtable要素のエラー処理改善
  • table要素やtr要素の直下にtable要素が出現した場合など
  • 詳細はHow should this table code be handled?(原文)を参照
• emを用いたときに発生していた丸め込みの問題を修正

Opera Mailの改良

ついにKastrelでM2として知られるOperaのメールクライアントが変更される

• 新しいバックエンド
  • メールチェック時に固まる現象が無くなった
  • 間違いだらけの検索やインデックスの修正
• 不正確な情報だがニュースグループに待望の機能が追加されるかもしれない
• Apple MailとOpera Mail間のデータ交換の完全サポート
  • 一部は既にOpera 9.2で実現している
  • これはApple MailがRFC標準に完全準拠していないことに起因する
• content-typeの認識に起因して、添付ファイルがオリジナルのファイル名ではなく.tmpファイルに改名されてしまう問題の修正

ユーザインタフェースの修正

• Kestrelではユーザインタフェースの大幅な変更は予定されていない
• 2つの小さな変更を期待している
  • コンテンツのブロックをサイト設定に追加
    • 既にコードは存在する
    • Kestrelにもそのまま残ることを願っている
  • opera:aboutに対するサイト設定の追加の正しい動作
    • 詳細はNew weekly (build 8746) is available(原文)を参照
• Opera for Linuxでタブバーを利用せずウィンドウパネルを利用している場合に生じていた問題の修正が含まれる
  • 詳細は"Open in background" with no tab bar - a mild irritation(原文)を参照

さらに

• (Firefox 3に追加されるのと同様の)HttpOnly cookieのサポート追加
  • 詳細はDoes Opera support HttpOnly cookies ?(原文)を参照
• KestrelではhttpsでもUserJSが動作するようになる
• 新しいページ情報パネルが既に実現している

確証のない新機能

• video要素のサポート
  • Opera Labsで既に実験版が配布されている
  • 詳細はWeb Developer Chat: Håkon Wium Lie on the tag(原文)を参照
• Microsoft Silverlightのサポート
  • 詳細はSilverlight, coming soon to a browser near you(原文)を参照
  • 齋藤さんも簡単に取り上げている
• PeregrineではHTML 5や、同様にウェブアプリケーションのオフライン動作がサポート(原文)されるかもしれない

「Upcoming SVG support in Opera and a Wii suprise」より

2007-05-07にDavid Storeyがブログへ投稿した内容。

Kestrelの内部ビルドでは以下がサポートされており、これらはKestrelの公開ベータ版にも搭載される。一部はWiiインターネットチャンネルにも搭載されている。

• CSSのリストマーカー画像や背景画像へのSVGの利用
• 画像要素に対するSVGファイルの指定
• 以下のSVG 1.2 Tiny仕様
  • vector-effect
  • navigation
  • handler
• 速度向上と最適化
• アニメーションやテキスト、SVG DOM関数、フィルタに於ける多くの一般的なバグ修正

その他についても今後実装される可能性はある。

「Switching on/off of FILTER.INI in SitePrefs」より

2007-04-13にMy Opera Communityへ投稿されたスレッド。Petter Nilsenが2007-04-19に以下のようにコメントしている。

We hope to have site specific support for the content blocker in kestrel. The code has been written, but obviously no promises that it will be in kestrel.

そのまま訳しておく。

我々もKestrelでサイト別にコンテンツのブロックが設定できるようになることを期待しています。そのコードは既に書かれているのですが、Kestrelへその機能が追加されることを明確にお約束はできないのです。

「9.20 is out but...」より

2007-04-11にMy Opera Communityへ立てられたスレッド。ここでは2007-04-15のolliのコメントのみ取り上げる。

• 全ての人の嗜好は違うため全ての人の理想通りに(機能を追加するなどして)仕立てることはできない
• 現在最優先で作業しているのはバックエンド
  • メールチェック時にフリーズするなど全員に影響する問題の解消へつながる

In the second run we might see more of these bells and whistles features I hope. Doesn't mean none of these will not end up in first run (kestrel). We have f.ex a longwaited newsgroup feature being worked on :-)

とも書いてあるが、よくわからないので訳さないことにする :D

「Tim's Opera Bits v5.0」より

Note: I should mention that the exact version these features will be available in is tentative. This is our current plan, but plans change.

上に引用した注意書きにもあるとおり、以下の内容は2007-02-26時点での計画であり、変更される(もしくは変更されている)可能性がある。

MerlinとKestelとPeregrine

• 2006年6月からMerlinへの多くのバグ修正は停止していた
  • すなわちそれらは全てKestelで修正されていたということを補足しておく
  • この話についてはThe Rendering Engine for the Wii(原文)を参照するとさらなる情報を得ることができる

Meanwhile, we've continued to add features and fix bugs in both the rendering engine and Desktop-specific functions. All of those rendering engine changes will be included in Kestrel, though some of the changes in the user interface will have to wait until Peregrine.

• Merlinへの機能追加やバグ修正は継続している
• Merlinエンジンに対して行われた修正はKestrelにもマージされる
• ユーザインタフェースに対する変更の一部はPeregrineまで待つことになる

レンダリングエンジンの更新

David Storey has already provided details about several of the changes in his post, Upcoming CSS3 support in Opera. David lets us know that Kestrel will have support for many more CSS3 Selectors, as well as the text-shadow property. Rijk was good enough to make a screenshot of Opera's forthcoming text-shadow support and include a few more details. Additionally, some more of Opera's bugs have been squashed, including a long-standing rounding problem, various XSLT bugs, SVG problems, and a whole lot more.

• DavidがUpcoming CSS3 support in Operaにまとめている
  • Kestrelは多くのCSS 3セレクタをサポートする
  • text-shadowプロパティをサポートする
    • Rijkが詳細な情報とともに来るべきtext-shadowサポートのスクリーンショットを作成している
• 多くのバグが修正された
  • 長年の丸め込みの問題
  • 様々なXSLTのバグ
  • 様々なSVGの問題
  • 他諸々

インタフェースの変更

One of our major initiatives for Kestrel and Peregrine is improving accessibility. As such, Opera will again include screen reader support in Kestrel for the first time since Opera 7.0 was released. Charles McCathieNevile has more details about this support in his recent blog entry, Speaking out.... We have a lot of work to do in this area, but things are progressing nicely. Everything may not be finished in Kestrel, but I hope it will be.

• KestrelとPeregrineの大きなイニシアチブの一つはアクセシビリティ強化
  • Kestrelでは再度スクリーンリーダをサポートする
    • Opera 7.0リリース以来初めてのサポート
    • Charles McCathieNevileが詳細をブログに投稿している
  • 順調に進んでいるがKestrelに間に合わない可能性もある

Opera Mailの更新

Opera Mail will finally have a new indexing back-end, which will fix the long-standing problem with index and search corruption. We've also spent some time on our IMAP and POP back-ends, adding in some more user-requested functionality. Opera Mail is now faster and more efficient than ever before. A heap of user interface improvements are planned, but it's not clear if they'll be included in Kestrel, Peregrine, or later.

• インデックスのバックエンドが新しくなる
  • 長年の問題であった索引や検索の修正
• IMAPやPOPのバックエンドの改善
• ユーザの要望に応えての機能追加
• Opera Mailはより速く効率的に
• 多くのUIの改良が計画されている
  • 内容は不明瞭
  • KestrelやPeregrineで実装されるのか、それ以降になるのかも未定

「Speaking out...」より

2007-01-30にCharles McCathieNevileがブログへ投稿した内容。

And in the Opera way, that means we have code to work across platforms - I can fire up the screen reader built into my Mac and try it out, while the G-man (a blind friend I am staying with who is an Opera tester) can fire up JAWS on Windows, and another tester can use Window-Eyes or HAL, according to their particular preferences.

• クロスプラットフォームでの音声読み上げが実装された
• 以下の環境での読み上げを確認した
  • Mac OSに搭載されているスクリーンリーダ
  • JAWS for Windows
  • Window-Eyes
  • Halスクリーンリーダ

...at least I can say that we have made significant progress, and in an upcoming major release (I don't know what version number - that's a decision made by others in the company) you will be able to browse the web, use web-based applications, read and write email, chat with IRC, follow your favourite news feeds, and do it all through a screen reader...

• バージョン番号は分からないがこれはメジャーアップデート時に追加されることになるだろう
• 全ての機能をスクリーンリーダから利用することができる

「a screenshot of Opera's forthcoming text-shadow support」より

Rijkが2007-01-22にブログへ投稿した内容。

• Panelizerで実際にtext-shadowが機能している場面のスクリーンショット
  • 単なる影付き文字は嫌いなためにじみ効果(blur)を用いている
  • text-shadowのみを利用するのは(サポートしない環境が多い現状)得策でない
• 以下の機能はうまい具合に機能している
  • 複数個の影のサポート
  • にじみ(blur)の最大値制限
    • 他のブラウザが大きなにじみ値での動作に深刻な問題を抱えているのはご存知だろう

「Upcoming CSS3 support in Opera」より

2007-01-22にDavid Storeyがブログへ投稿した内容。

• 特にセレクタに注力している
  • 既にOpera 9.1でサポートされているセレクタも存在する
    • 現在利用している環境での対応状況はCSS Selectors testsuiteで知ることができる
  • 2007年1月22日時点での内部最新版の実装状況
    • 既にサポートされているセレクタは以下のとおり
      • :root
      • :not()
      • :nth-child()
      • :nth-of-type()
      • :first-of-type
      • :target
        • 今のところバグが多い
    • コアエンジンでは実現できているが様々な問題に起因して現在の所無効となっているセレクタは以下のとおり
      • :empty
      • :nth-last-child
      • :nth-last-of-type
      • :last-child
      • :last-of-type
      • :only-child
      • :only-of-type
  • 最終的には全てのセレクタがサポートされる
  • 現在欠けている唯一の機能は::selection疑似要素
• 内部ビルドではtext-shadowプロパティが既に実装済み

個人的な補足

これらCSS 3対応の一部がWiiインターネットチャンネルに反映されている旨がThe Rendering Engine for the Wiiにて示されました。これを受けてWiiインターネットチャンネルでの対応状況がWii Opera のCSSセレクタ対応状況にまとめられています。

「More on updating the Info panel」より

2007-01-11にPeter Karlssonがブログに投稿したエントリーの内容。

• Updating the Info panelに対して様々なコメントをもらった
• 新しいページ情報パネルのスクリーンショット
  • 加えられた全ては表示されていない
    • 例えばここにはリンクされているJavaScriptの一覧が表示されていない
• ページ情報パネルにはページの静的な情報が表示される
  • ページのコントロールはできない
  • 個別にスタイルシートを無効化するといったことはできない
• プログラム上の制限も存在する
  • 例えばロードに要した時間の表示などはできない
• 何を適用したかに関する情報を含めるかは未定
• レンダリングモードは表示されている
• 今のところbrowser.jsが適用されたかどうかの情報は表示していない
  • browser.jsは利用されたときにコンソーメッセージを投げるため、それを利用して適用されているかどうか知ることはできる
• サイト別設定やコンテンツのブロックに関する情報も表示されない
• These are on the list of ideas to consider.

「rounding problem」より

2005-08-22に投稿されたブログエントリーTop 10 Rendering Engine Bugsにて挙げられていたうちの1つ。

• 20.47emを越えたmarginやpaddingをem単位で指定したとき値の丸め込みがおかしくなるバグが存在する
• http://www.brunildo.org/test/emarg.plにて検証されている

• The Next Wave: Opera 9.5 (Kestrel) and Opera 10 (Peregrine)

カラオケでの曲探しはまだ面倒だ

カラオケで曲を探すのはずいぶん楽になったと思う。分厚い冊子から探すのが基本だった頃はこんな感じだった。

• 曲名から探す
• アーティスト名から探す
• ジャンル別の一覧から探す
• 新譜一覧から探す

いつの間にやら選曲にも電子化の波が押し寄せて、色々な選び方ができるようになった。特に便利だなぁと思うのはこの辺り。

• 年代別にヒット曲をリストアップ
• 履歴を見る

でも、個人的にはこんなことが実現されたらなぁ、と思う。

歌いだしで検索

曲と一緒に歌いだしのデータも保持しているのだからこれで検索できていいはず。と書いていたら、すごいデンモクか何かにはあったような気がするとのこと。試聴もできるそうで。すごいなぁ。

サビで検索できたり鼻唄で検索できれば言うことなしだけれども、それはまた別の話だろう。

アーティスト別にヒットした順にソートして表示

うろ覚えの曲は概ねヒット曲でソートしたら発見できる気がする。案外アーティストは覚えているという例は多いと思う。そういうときアーティストで絞りこんで曲名をざっと眺めるのは難しいし、そもそも曲名を覚えているとも限らない。これって僕だけの特殊例なのだろうか。

はてブでいう人気順と注目順があればなお便利。

せっかく電子化されたんだからこの位できても良いだろうになぁ、と思う次第。

カラオケ大好きというわけでは無いので、もしかすると、もう既にあるのかもしれない。

Operaの良いところ

今回は他に無いOperaの特徴を6つ見てゆこうと思う。Operaについて詳しく知らない人がこれを読みOperaに興味を持ってくれれば嬉しい。世間ではFirefox全盛期だけれど、人によっては他のどんなブラウザよりOperaの方が魅力的なのだ。

WindowsにはWindowsの、MacにはMacの習慣がある。それと同様、FirefoxとOpera(ここではあまり取り上げないがその他の環境)にもそれぞれの習慣がある。ここではそういったOperaの習慣についても取り上げる。これによってよりOperaをOperaらしく使うことができるようになるかもしれない。

特にOperaらしさの観点からはmanateeさんが具体例を幾つか紹介してくれたので興味がある方はそちらも参照するとよいだろう。

Firefoxの事

さて、まず明らかな事実(と私が思っている事)を書いておく。

• 機能でOperaがFirefoxを凌駕し続けることは無い
• 手厚く博学なコミュニティを抱えているのはFirefox

Firefoxは拡張機能によって機能を追加する事ができる。ソースコードを書き換えれば、なんでもできる。

Firefoxは世界中の素晴らしいオープンソース開発者がともに作り上げている。開発者の情報交換は広く深い。知識の多くは公開され、共有されている。

Firefoxの利用者数は増えてきている。情報も増え続けるだろう。それに伴ってコミュニティはさらに素敵なものへと成長する。

Operaのコミュニティも、悪くはない。だが、どうしても情報に限界がある。ユーザの絶対数が少なく、ソースを漁ろうにもそんなことは認められていないのだから。

Operaを選択する能動的な理由

ではどこにOperaを選択する能動的な理由が存在するのか。僕はこの辺りだと思う。

• 軽い
• 統一感

話をFirefoxとOperaに絞るのであれば、この辺も選択理由になるように思う。

• 必要な機能が最初から揃っている
• MDIによるブラウジング(Mac OS版では受けられない恩恵)
• 拡張できないことによるセキュアな状態の保証
• 一度覚えれば拡張機能を探すよりこなれているini編集

これ以降で各々について詳しく見てゆく。

軽い

これはレンダリング速度の話ではなく、メモリ消費量の話だ。IEコンポーネント系と比較するとレンダリング速度も品質も圧倒的優位だが、まぁそれは置いておこう。

かつてはレンダリング速度で大きく優位に立っていた時期もあった。だが、今はほとんど変わらない。特にメモリキャッシュの扱いによる、戻る際の遷移速度には大きな差があった。しかし、スペックさえあればFirefox 2も十分早い。Firefox 3に至ってはOperaと変わらぬ速度を実現してくれる。

だが、ここで話題とするのはメモリ消費量だ。ここにはOperaとMozilla系プロダクトの思想の違いが存在する。各々の関係者の言葉を引用しておこう。もっと良い資料を見た記憶があるのだが、すぐに出てこなかったのでこの辺りで許してもらいたい。なお、引用中の強調は筆者による。

ここで注意したいのは、Mozilla系のプロダクトはある一貫したポリシーを持っている(と思われる)ことだ。メモリを犠牲にして、速度向上に努めるのが基本方針のようである。(誰の意志が色濃く反映されているか分からないので偶然かもしれないが、)例えば、Windows版で、ウインドウを最小化してもメモリを解放しなくなったのは、ウインドウ復元時にパフォーマンス低下の苦情が多かったことへの対応なので、この方針に一致している。

性能というよりも根幹となるビジョンの話になるのですが、開発当初から近い将来PCだけではなく色々な機器にインターネットを利用するための通信機能が搭載される時代がくるだろう、ということを思い描いていたようです。そこで『Opera』が他と差別化すべく続けてきた点はプログラムのスリム化とスピード化です。

ここに並べた2つの引用は、そもそものレイヤーが異なることを念のため明記しておく。Opera for Desktopはある程度デスクトップの高性能環境を意識したチューニングがなされているだろうし、Geckoエンジンも十分スリム化に勤めているだろうことは想像に難くない。

鵜呑みにするべきでは無いが、一つの参考資料として昨年末にFirefox 2とOpera 9.1のCPU負荷とメモリ使用量を調べた方が居たので紹介しておく。記事の最後に考慮すべきと点が2つ提示されているが、それを鑑みても十分な差であるように思う。

実際の活用例

タブを大量に開いておけるため、Operaユーザの中にはしばしばこのような人がいる。

• 常時画面一杯のタブを開くため、タブバーは左右に縦置きできないと話にならない。
• とりあえず思いつく限りのページを(数十単位で)バックグラウンドに開いておき、後からページを閉じながら読む。

このような使い方はOperaでしかできない。少なくともFirefoxでは難しい。言い方を変えるならば、Operaユーザはいつでもあとで読むことができる。そしてその使い方は実にOperaらしい。

Operaが用意する後で読むための手段は他にもある。いわば、もっとあとで読むといったところだろうか。セッションとして保存しておくという方法がまず思い浮かぶだろう。しかし、ブックマークのフォルダにまとめておくという方法もある。Operaのブックマークフォルダにはニックネームが付けられるため、あたかも一つのページを開くのと同じ感覚で一気に開く事ができるのだ。

中にはどうせ全てのタブを表示させることはできないのだからと、タブバーを消してしまう人もいる。それは私だ。事の顛末はタブバーを消してみたら案外良い感じだったを参照していただきたい。当該エントリー中では特にタブの表示量に付いて触れていないが、理由の一つとして存在していた事をここに付け加えておく。

統一感

Operaは拡張をサポートしない。それによって統一感を持ったインタフェースを提供することができる状態にある。ほぼ全ての機能は連携可能だ。

全てが入った状態でショートカットを定義することができるためほとんどの機能にはキーボードショートカットが割り当てられており、それらに矛盾は無い。Linux環境下であればEmacsライクなキーバインドを実現するための設定ファイルも付属してくる。全部入りだからこそできることだ。

メニューバーのツールから外観の設定を開き、ツールバータブを見てほしい。ここで全てのバーの配置を変更することができる。適当なバーを実際にクリックし選択、その後配置のプルダウンメニューを利用して上下左右に配置する。どれも同じなのだ。ほぼ全てのものを移動させることができ、全ての場所にいかなるボタンをも配置することができる。

それを実際に活用して様々な初期状態を実現したiniファイルをOpera社のRijkが配布している。このページで配布されるiniファイルはクリックするだけで適応させることができる。Operaのカスタマイズに精通していなくても利用できるので安心してほしい。

必要な機能が揃っている

Operaは特殊な機能を持たない。例えばiTuneなどといった他のソフトウェアと連携させたりといったことは(コマンドラインで叩けるのなら別だが)基本的にできない。外からOperaの機能を利用することもできない。

だが、ブラウジングに必要な機能はほぼ全て揃う。インストールするだけで十分だ。

もちろんカスタマイズしなくても良い、という利点はある。しかしそれ以上に着目すべきは外出時にそのまま使える、という点だ。そういう状況下では管理者権限が無いのが普通だろうから、Portable Operaを入れる事となる。これなら管理者権限不要だ。自分の環境を入れて持ち歩く必要は無い。もともとカスタマイズなんて必要ないんだから。

標準状態で使いにくいFirefoxの場合、そうは行かない。自分の環境をメモリに入れて持ち歩くことはできる。だが、日々カスタマイズされた状態を持ち歩かねば結局戸惑うこととなる。

もちろんOperaも多少はカスタマイズして使うことになるだろう。だが、概ね標準状態で事足りる。そして、その状態を保つべきだ。Operaをメインブラウザとしていない人でも、Operaでそこそこ満足いくブラウジングができるようになっておいて損は無い。

大丈夫、概ね今使っている操作性とたいして変わらないはずだから。便利なキーボードショートカットをいくつか覚えればそれで十分。いざというときに使おうと思い立つには、一度使っておいた方が良い。ただそれだけのレベルだから。

OperaにはGoogle Browser Syncのようにブックマークや履歴を同期する手段は無い。でも、そんなものを同期する暇があるならさっさと検索エンジンに調べてもらった方が早い。必要ならばウェブサービスを普段から使えば良い。

重要視すべきは時間短縮。本当にそれ全てを同期することが、今、必要?

MDIによるブラウジング

残念ながらMac版Operaではこの恩恵を受けることはできないのだが、WindowsやLinuxでOperaを使えるのであれば是非試してほしいのがMDIによるブラウジングだ。

Operaが自身をタブブラウザと呼ぶようになったのは最近の事だ。今のOperaを見てもMDIとは感じにくいだろう。意図的にそれを裏に隠しているから。

MDI化の第一歩はメニューバーにウィンドウメニューを表示させることだ。メニューバーのツールから設定を開き、詳細設定タブのブラウジングを選択し、ウィンドウメニューを表示するにチェックを入れよう。面倒な人はopera:config#UserPrefs|ShowWindowMenuを開いてチェックを入れれば良い。

完全なMDIへOperaを変貌させるためには、同詳細設定タブのタブを選択し、タブに「閉じる」ボタンを表示のチェックを外す。面倒な人はopera:config#UserPrefs|ShowCloseButtonsのチェックを外せば良い。これで見慣れたMDIに変貌する。

最近FirefoxにもSplit Browserという拡張機能が作成され、MDIのような使い方ができるようになった。これはこれで面白い。

実際の活用例

後は煮るなり焼くなりしてほしい。が、それでは途方に暮れる方も居るだろうから幾つか利用例とその方法を挙げておく。初期状態ではメニューとキーボードショートカット以外割り振られていないが、もちろんマウスジェスチャに割り当てることもできる。どれも同じだから。

• 任意のウィンドウ(タブ)を並べて利用する
  1. 一度全てのウィンドウ(タブ)を最小化する
  2. 任意のウィンドウ(タブ)を開く
  3. 縦もしくは横に並べる
  4. 終わったら全て最大化するなりなんなりお好きにどうぞ
• Exposeもどき
  1. 何も考えずにいきなり並べて表示する
  2. 任意のウィンドウ(タブ)を選択する
  3. そのウィンドウ(タブ)を最大化

ちなみにパネル(Firefoxでいうサイドバー)もウィンドウ(タブ)の一つとして扱う事ができる。メニューバーのツールから外観の設定を選択し、パネルタブのパネルの位置のプルダウンメニューから浮動表示を選べば良い。これは何気に便利でおすすめである。

Operaのパネルについて少しだけ。パネルにはブックマークした任意のページを表示させることができ、必要に応じてSSRでレンダリングできる。プロパティ画面から簡単に設定できるため、活用範囲は広い。

さらなる情報

さて、最後にMDI活用のためのヒント。設定したであろう「タブに『閉じる』ボタンを表示」のチェックボックスの上にあるタブをクリックすると最小化やタブなしウィンドウを許可するの設定は好みにあわせ、使いかたにあわせて設定すべきだ。ちなみに私はというと、ともにチェックを入れた状態で使っている。

基本的にOperaは終了させない。特にメモリを食わないのだから。とりあえず起動して常駐。必要なときに前面へ呼出し、必要ないときは最小化ないし、Ctrl+hで通知領域へOperaを隠す。これがOpera流だと僕は思う。だからこそタブなしウィンドウを欲するのだ。

また、より興味を抱いた人が居れば齋藤さんのMDI で行こうもあわせて参照すると良い。

拡張できないことによるセキュアな状態の保証

拡張機能の大半はセキュアだが、外部で配布される拡張機能をインストールする際に提示されるメッセージの通り、それは保証されない。こんなことを言い始めるときりがないと言えばきりがないのだが、拡張性の無いOperaはFirefoxに比べて安全だろうと思う。(ただしOperaもUser JavaScriptを利用する場合はその限りでない。)

コアな部分のセキュリティに関しては特に述べない。Secuniaなどの結果を用いて現状を提示しても良いけれど、そんなものは逐一変化するものだ。

一度覚えれば拡張機能を探すよりこなれているini編集

Firefoxはある動作に対して操作を割り当てる。これは拡張機能によって増え続ける機能に対応するために必然といえる手順だ。それに対してOperaのini編集はある操作に対して動作を割り当てる。そこさえ分かれば後は勘で編集できる。

というのはさすがに乱暴なのでもう少し補足しておく。

• 設定は単なるiniファイルなので比較的いじりやすい
• 項目を入れ替えたいならiniの記述順を変えるだけ
  • ただし検索エンジン定義(search.ini)はナンバリングされているため例外
• ボタンにもメニューにもキーボードショートカットにもマウスショートカットにも同じアクションを割り当てられる
  • つまりどこかでできることはどこでもできることを意味する
    • Operaを良く知るユーザには嘘だと一蹴されそうだがほとんどの場合どれも同じだ
    • 例えばマウスジェスチャやキーボードショートカットにブックマークレットを登録したりなどは易しい
  • アクションを作成するための資料としてOpera All Action in Japaneseを挙げておく

私信

こんなことを書くとOpera信者とかいうヨクワカラナイ人たちの袋叩きに遭いそうで若干恐いですが、書きましょう。lomoさんはメインブラウザをOperaに変えることを考えない方が良い。あくまでもサブブラウザとして見た方が良いでしょう。もしくは、使いわけ。開発環境としてのFirefoxは間違いなく最強なのですし。

逆に言えば多少遅くても重くても、たまに落ちたり、プロファイル入れ直しを迫られようとも、今の環境のためにはそれらのリスクや不便さをガマンできるってことかもしれません。

今の環境に固執するのであれば、今の環境が良いという所に落ち着くでしょう。全部実現できていて、不満もないのです。立ち入る隙なんて、無い。

というわけで、機能移植については他の人のエントリーを参照してくださいまし。概ね移植できるという結果が得られるかと思います。しかし速度を重視していないとなると、いずれFirefoxに戻るかと思う次第です。

• Operaのよいところってどこですか?
• 今現在のFirefoxでのブラウジング環境

• 発想の違い
• Re: Operaの良いところ

• 僕がOperaに落ち着く理由

OperaのスピードダイヤルとFirefoxの拡張機能Speed Dial

Operaのスピードダイヤルを模したFirefoxの拡張機能Speed Dialが公開された。見てくれは非常に似ているが、これらはまったくの別物である。今のところこの拡張機能でOperaのスピードダイヤルが便利であることを実感するのは難しいだろう。特に長期間使いつづけるのであれば。

ここではOpera 9.2のスピードダイヤルと拡張機能Speed Dial 0.1.1を比較し、Operaのスピードダイヤルが実現している本当に便利な所を見てゆこうと思う。

機能

まずはそれぞれが実現する機能をリストアップする。

共通する機能

驚くかもしれないが全く同じ機能はこれしかない。

• ブランクページに9つのページサムネイルを表示する
• サムネイルをクリックするとそのページへアクセスできる

スピードダイヤルで目を引くのはこの部分だ。しかしこれはスピードダイヤルが便利である一部分に過ぎない。

拡張機能Speed Dialの機能

拡張機能Speed Dialは以下のような方法でページを編集する。

• タブで開くコンテキストメニューから現在見ているページを追加
• ページ上で開くコンテキストメニューから現在見ているページを追加
• ブックマークメニュー直下に追加されるメニュー項目から現在見ているページを追加

サムネイルを利用するために最低限必要な機能だ。ページの表示場所は番号で選択することとなる。バージョン番号が0.1.1と非常に小さい所以はこのあたりにあろう。

Operaのスピードダイヤルの機能

Operaのスピードダイヤルは直感的だ。全てはスピードダイヤル画面から始まる。

ページを編集する為に以下のような方法が用意されている。

• 追加したいページのタブをサムネイル表示領域へドラッグ&ドロップする
• パーソナルバーなどへ配置されるリンクボタンをサムネイル表示領域へドラッグ&ドロップする
• サムネイル表示領域間でドラッグ&ドロップして場所を変更する
• (サムネイル表示領域が空の場合)領域をクリックして表示される編集画面でページを選択して追加
• サムネイル表示領域で開くコンテキストメニューで表示される編集画面でページを選択して追加

どれもマウス操作によるものであり、位置管理が前提である。使うにあたってサムネイルの位置以外を意識する必要は無いのだ。

一応マウス以外のアクセス方法としてこれらも用意されている。

• アドレスバーに1〜9の番号を入力してそのページへアクセスする
• Ctrl+1〜9のショートカットキーでそのページへアクセスする

続いてスピードダイヤルの編集画面を詳しく見てゆこう。ここからページ選択の方法を4つ選択することができる。表示される順に挙げておく。

1. よくアクセスするページ
2. 開いているページ
3. Opera サイト
4. アドレス入力欄

これらそれぞれについて、念のため説明しておく。

よくアクセスするページ

最近よく閲覧しているページ上位10件がリストアップされる。何を登録すれば良いか思いつかない場合でもここを見れば多くの場合追加すべきページを知ることができる。

開いているページ

開いているタブの一覧が表示される。複数のウィンドウを開いている場合でも全てのウィンドウに存在するタブがリストアップされる。

Opera サイト

Operaの公式サイトが幾つかリストに並ぶ。キャプチャを見てわかるとおり、スクロールバーを移動させねばない限り表示されない。多くのユーザは公式サイトになんて頻繁にアクセスしないのだ。登録する人がいる可能性を想定しているとともにそのウェイトは低くなっている。

アドレス入力欄

直接入力することもできるようになっている。入力履歴や補完機能もきちんと働く。

これらによってOperaのスピードダイヤルはなんとなくで操作できるようになっているのだ。

Operaのスピードダイヤルのポイント

Operaのスピードダイヤルのポイントは大きく3つある。

• 新しいタブ(ウィンドウ)にサムネイルを表示し、そこから簡単にページへアクセスする機能
• 思いついた方法を適当に試行する事で概ね成功する、直感的な操作
• サムネイル表示すべきページのリコメンド

拡張機能Speed Dial 0.1.1で実現されているのはこのうちのただ1つだけなのだ。拡張機能Speed DialはまだOperaのスピードダイヤルの利便性を体感するには不十分である理由はそこにある。もちろん将来的には十分になるだろうが。

直感的な操作

Operaのスピードダイヤルに於いて番号は飾りに過ぎないということは先に述べたとおりだ。拡張機能Speed Dialではページの追加時に番号を意識する必要があり、サムネイルの表示場所を直接に連想させることは無い。それに対しOperaのスピードダイヤルは位置情報以外のものを意識せずに使えてしまう。操作に一切の勘が働かない初心者が解説に沿ってボタンなどをクリックしてゆくことでも利用できるのに加えて、思いつくままに勘で操作しても応えてくれる。

例えば編集画面でページを選択する場面を想定してみよう。いわゆる初心者は編集画面で項目を選びOKボタンを押すことだろう。しかし勘が働く人の場合、編集画面の項目をダブルクリックすることで確定するだろうと推測するのだ。Operaのスピードダイヤルはこのような勘にきちんと応えてくれる。これは使いやすいソフトウェアに求められる基本的な事柄だが、残念な事に拡張機能Speed Dial 0.1.1はまだそこまで気が回っていない。

確かにキーボードショートカットやニックネームを付加する機能もあるが、あくまでもおまけだ。Operaのスピードダイヤルは単なる9つのブックマークでは無い。3×3のマトリクスなのだ。1番では無く左上、5番では無く真ん中。人によっては方位で表現する方がしっくりくる人もいるだろう。そういう人は9番を南東と表現すれば良い。番号で表現する必要は全く無い。番号なんて使わないのだから。

窓の杜の拡張機能Speed Dial紹介記事ではこの番号による機能が抜けていることをわざわざ指摘している。だが、そんなことはどうでも良い。拡張機能Speed Dialの課題は以下のようなことだ。

• ページの追加や編集が面倒
• サムネイルを削除するためのアイコンが無いため、削除のためにコンテキストメニューを呼び出さねばならない

番号による機能が損ねる使い勝手は微々たるものだ。しかし、これらの機能が欠けていることは使い勝手に大きな影響を及ぼしている。

よくアクセスするページ

よくアクセスするページにリストアップされる内容は、かつてスタートバーに存在していたTop 10でリストアップされるものと同一だ。アルゴリズムの詳細はわからないが、推測するに最終アクセス日時と人気から算出しているのだろう。これらはどちらもOperaが履歴とともに保持している値である。Ctrl+Alt+Hで表示される履歴ウィンドウから確認できるので一度見てみると良い。

この項目があることで、特に9つ思い浮かばない人でもスピードダイヤル9つを埋めることができる。何も初めてスピードダイヤルを使うときに限ったことでは無い。訪問頻度の下がったページを削除したは良いけれど代わりに何を入れるか浮かばない、といった場面も十分ありえるのだ。よくアクセスするページをそのままスピードダイヤルへ登録することでができるため、9つの枠を使いきることが容易になっているのだ。

今スピードダイヤルを体験しようと思った人は

スピードダイヤルがどのようなものかを体験しようと思った人には、是非Operaのスピードダイヤルを試してもらいたい。だが、FirefoxのコアなユーザにとってOperaへの乗り換えは難しいだろう。そういう人はもう少し待ってほしい。今の拡張機能Speed DialにOperaのスピードダイヤルを期待するのは、無理だ。最初の段階では似たような操作感を味わえるだろうが、維持管理が面倒になるのは目に見えている。

スピードダイヤルの紹介としては芦塚さんの記事がリンクも豊富で詳しい。ヘルプを読まずに使え、適当に使えるからこそ余計な記憶を増やさなくてよい、というのがOperaのスピードダイヤルの利点であると思うのだが、一応紹介しておく。個人的には解説記事を一切読まずに、適当に使ってほしいというのが正直な所だ。できることさえ把握できているならば、その手段は適当で良い。

補足

スピードダイヤルのさらなる活用

スピードダイヤルがサムネイルを表示することを活かし、サムネイルとして活用する事も考えられる。実際のところコンテキストメニューから自動更新のタイミングが制御できる事からも、そこそこにこれをある程度意識していることが伺える。今回はこれを特に取り上げなかったが、先に紹介した芦塚さんの記事にもあるようにうまく活用するとなお面白いかもしれない。

拡張機能Speed Dialが目的とする所

この記事は拡張機能Speed DialがOperaのスピードダイヤルと同じものを目指しているという前提で書かれている。しかし目的が違うのであれば話は変わってくる。

Operaのスピードダイヤルは今見ているページをサムネイルとして追加する事を重視するならば、不便だ。「あとで読む」タグを付ける代わりに気になったページを登録するのであればわざわざスピードダイヤル画面を開くのは億劫であり、ページを見ている所から直接追加できた方が便利だ。しかし、Operaはそれをサポートしていない。Operaのスピードダイヤルはあくまでも3×3のマトリクス表示を頑なに意識し、サムネイルの表示場所で覚えさせようとしているように思える。

目的によっては拡張機能Speed Dialの方が便利だ。この点はきちんと補足しておきたい。

キャプチャ画像の事

いうまでもないとは思うが、この記事にあるキャプチャ画像のよくアクセスするページはでっちあげだ。おぉ、と思ってしまった人、残念でした。

• スピードダイヤル (えむもじら)

僕がOperaに落ち着く理由

綾川版Firefoxに乗り換えたのが先月4日、Gran Paradisoにしたのが今月の2日。一月半ほど、まじめにFirefox生活を送っていたことになる。が、結局Operaの方が自分には合っていると思うに至った。折角なので感じたことを全て書き留めておこうと思ったのだが、結局3大Webブラウザとユーザの関係の焼き直しのようになってしまった。つまりはそういうことなのだろう。

手間をかけることに労を惜しまない人はFirefoxを使えばよいと思う。むやみやたらと拡張を入れない限り十分な早さで動いてくれるし、やろうと思えば何でもできる。探せばドキュメントは多く存在するし、ドキュメントを見つけるのも比較的容易だ。

しかしながら、裏を返せば何をやるにも面倒、とも言える。ふとした思いつきでメニューやショートカットを増やしたい衝動に駆られたとき、すらすらとスクリプトを書けない私は、探すか諦めるかの二択を迫られる。Operaであれば出来るか出来ないかの二択。出来るならちょっとiniファイルに書き足すだけだし、出来ないなら諦めるだけ。決断にもそう時間は要しない。

特にこれを顕著に感じるのがキーボードショートカット。Firefoxへ乗り換えるときも随分悩んだが、これを自在に設定できるOperaの手軽さの虜になっているとも言えるような気がした。

なんだかんだで僕が一番長期間利用しているブラウザはOperaだ。どうしてもOperaだったら出来たのにな、と考えてしまうことが多い。もちろんFirefoxでも拡張機能を入れたりすれば出来る。だが、探すのが面倒だ。結局はそこに行き着いてしまう。

Firefoxはほぼなんでもできる。だが、それはスクリプトを書ける人にとっての話だ。書けない人にとってかゆいところに手が届くのはOperaのように思う。少なくとも僕はそう感じた。iniファイルでやりたいことは概ね事足りてしまうのだから。

Firefoxへ移行しようと思い立たせたきっかけがOperaのXMLパーサのバグであったように、Operaへ戻ろうと思い立たせたきっかけは謎のアラート。綾川版に戻るという選択肢もあるのだけれど、次はスピードダイヤルで遊ぼうかな、と。もっとものりさん曰く、今のビルドではこの謎のダイアログが発生するバグは再現しなくなっているとのことで、alpha4 では直ってると思われとのことだが。

先日手元のコンピュータのひとつをLinuxデスクトップにしてみた。新規構築時に何を入れたくなったか、と言えばOperaだ。確かにFirefoxのカスタマイズ方法はメモした。しかし、時間を費してFirefoxをカスタムするくらいならOperaで良いかな、と思うに至ったのだ。僕はOperaに十分過ぎるほど満足している。逆も然りだろうと推測される。FirefoxやOperaを既に使っている人は、その環境に満足しているのだ。

OperaとFirefoxには確かに微妙な挙動の違いがある。それが味になっているといえるだろう。その味が、さらに慣れた環境を捨てることを難しくしている。そう思い知らされた。

最後に。今回1ヶ月半使って、Firefoxいいなぁ、と思った。好感度は確実にあがった。好感度が何を指すのか、なぜそう思ったのかは、さっぱりわからないけれど。好感度の源がはっきりしたらまたエントリーとして公開しようと思う。

もし他のブラウザを試してみようと思うなら

他のブラウザを試すのであれば、本気で取り組まねばなんの意味もない。はっきり言っておこう。乗り換え対象として名前があがるようなブラウザが実現していることはどれもたいして変わらない。ではなぜ一つのブラウザを使いつづけることになるのか。それは、初めて触れたからとか、初めて本気で使い込もうと思ったとか、そういった理由だろう。

他のブラウザを試し、満足感を得るためには、既存の良く知った環境を短期間で越えなければならない。だからこそ本気である必要がある。何らかの強い不満を抱いていない限り、既に十分満足している元の環境へ戻ってしまうのだ。もしかすると、戻れるという安心感すら問題なのかもしれない。

ウェブブラウザはどれもある程度成熟している。乗り換え対象として挙げられるようなものはどれも似たような機能を持っている。必要とされる機能の大半は実現できる。そんな中で積極的な理由を見出すのは難しいのだ。

少なくとも僕には難しかった。既にOperaのおいしい部分を存分に知ってしまっている。そんな状態で、時間を費してまでFirefoxのそれを会得する利点はなかなか感じられるものではなかった。Operaでいいです、という感じだろうか。

本気で取り組まなかったことで先入観を持ってしまう可能性がある。誤った判断ほどもったいないことはない。将来的な機会を失ってしまうことにもなるのだから。だからこそ、やるならば本気で取り組んでほしい。そういう意味でわたしは今回良いきっかけに恵まれたと思う。Operaに戻りたくないというはっきりとした理由があったのだから。

雑感

よく言われていることばかり並んでいる気もする。

Ctrl+Alt+Zかctrl+Shift+Tか

閉じたタブを開く機能のショートカットキーはFirefoxの方が押しやすいと感じた。Operaはタブを元に戻すことに着眼してCtrl+Zをベースにしたのだろう。対してFirefoxはタブを開くことに着眼してCtrl+Tをベースとしているように思う。意味的にはOperaのそれが私にはしっくり来る。しかしMacの⌘+Altは押しやすいが、WindowsやLinuxで使うこととなるCtrl+Altは離れていて押しにくいのだ。まぁあくまでも私の場合、なのだけれど。

タブを一気に開いたときの挙動

全文を配信しないフィードが私の周りには多数存在しているため、LDRのピン機能をよく使う。つまり後から一気にタブを開くこととなるのだが、そのときの動作が機敏なのはOperaであるように感じる。ページのレンダリングはほぼ同じ体感速度だが、複数タブを同時に読み込んだ時の挙動はまだOperaに分があるようだ。

文字列選択

キャレットブラウジングがあるという点ではFirefoxのキーボードブラウジング環境は優れていると言える。しかしながら、CSS生成内容を選択できないのは厳しい。

ユーザスタイルシート環境

Stylishは本当にうらやましい。あれは便利すぎる。

開発環境として

開発環境としてはFirefoxの方が圧倒的に優れているといえる。Firebugは実に便利だし、JavaScriptの実装はFirefoxの方が早い。実装速度に関しては歴史的経緯が若干あるのかもしれないが、新しい機能が使えるのはやはり便利だ。

コメントに対する回答

JavaScriptを書くときにはFirebugが使えるようになった頃からFirefoxを使っています。FirebugはOperaにない優れた開発環境を実現してくれますから。そういった意味ではわたしもFirefoxとOperaとの二股生活を送っている、と言えるのかもしれません。

おまけ

一躍時の人となった彼の演説を用いたネタを載せておく。あまりに脈絡が無いので捨てるつもりだったのだけれど、せっかくなのでおまけとして。

ブラウザにこだわりを持つ諸君!私がOperaである!
諸君!他のブラウザは最悪だ!
拡張機能だとかプラグインだとか、
私はそんなことには一切興味がない!

あれこれ機能を追加してみんなが幸せになれるような、
もはやそんな甘っちょろい段階にはない!
そんな機能はもう見捨てるしかないんだ、
そんな機能はもう滅ぼせ!

私には、建設的な提案なんか一つもない!
今はただ、スクラップ＆スクラップ、全てをぶち壊すことだ!

諸君!私は諸君を軽蔑している!
この下らない機能を!そのシステムを!
支えてきたのは諸君に他ならないからだ!
正確に言えば、諸君の中の多数派は、私の敵だ!

私は、諸君の中の少数派に呼びかけている!
少数派の諸君!今こそ団結し、立ち上がらなければならない!
奴ら多数派はやりたい放題だ!
我々少数派が、いよいよもって生存しにくい
世の中が作られようとしている!

少数派の諸君!ブラウザの乗り換えで何かが変わると思ったら大間違いだ!
所詮ブラウザ選択なんか、運命の出会いに過ぎない!
我々少数派にとって乗り換えほど馬鹿馬鹿しいものはない!
普通に使っていれば、手に馴染んだブラウザが良いに決まってるじゃないか! 

じゃあどうしてブラウザを乗り換えたりしたのか?
その話は、長くなるから、昔のエントリーを見てくれ!
エントリーは二種類あるから、どちらも見逃さないように!

私は、はてブホッテントリの、ブラウザ自慢にもう我慢ならない!
少数派の諸君!利用者を説得することなど出来ない!
奴ら利用者は、我々使われていないブラウザに耳を傾けることはない!
既得権が支配する、こんな下らないブラウザの乗り換えは、
もはや滅ぼす以外にない!

乗り換えなんかいくらやったって無駄だ!
今進められている様々な乗り換えは、
どうせ全部全て奴ら利用者の確認に過ぎないじゃないか!
我々少数派は、そんなものに期待しないし、勿論喜びもしない!

我々利用者はもう他のブラウザに何も望まない!
我々利用者に残された選択肢はただ一つ!
他のブラウザを滅ぼすことだ!
ぶっちゃけて言えば、もはやウェブの消滅しかない!
		    
ブラウザにこだわりを持つ諸君!これを機会に、
手持ちのブラウザ削除の恐ろしい陰謀を、共に進めていこうではないか!
キーボードに、Deleteキーがあるから、
今すぐでも、読み終わってからでもかまわない!
とりあえず手持ちのブラウザを消してみてくれ!
勿論、乗り換える気の無いそこの君や、
ブラウザなんて動けば良いと思っている君でもかまわない!
我々利用者には、シェアなんか元々全然関係ないんだから!

最後に、一応言っておく!
きみが乗り換えたら、
奴らはビビる!!
私もビビる!!

Operaに悪意の一票を、
Firefoxにやけっぱちの一票を!
じゃなきゃブラウザ乗り換えなんてするな、
どうせ乗り換えなんて成功しないんだよ!!

• 3大Webブラウザとユーザの関係
• さらばOperaよろしくFirefox
• Gran Paradiso 3 Alpha 3
• Operaの良いところ

• 慣れだけではない差
• ryuzi_kambe の？Ｄ
• 諦めの悪い人向けなのかもしれない
• 良いブラウザに出会えていないのか、それとも現状で満足しているのか
• Operaのよいところってどこですか?
• 僕がFirefoxに落ち着いた理由...そして今、苦しんでいる

敢えてHTMLを選択するとき

よほどの理由がない限り簡単で再利用しやすいXHTMLを選択するのだけれど、ごくまれにHTMLを選択することがある。

それはろくなテキストエディタが無く、かつ1回限りのとき。やっつけでモックを、ろくでもない環境しかないところで作れと命じられたときとか。エディタがろくにXMLを編集できないのであれば、多くの省略が認められたHTMLの方が書きやすい。某氏の言葉を借りるならば、よく知っているから。段落やリストを書くたびに終了タグを書くなんて面倒なことやってられない。

まぁ、もちろんいまだかつてそんな境遇に遭遇したことはほとんど無い。何回だろう。たぶん、2回。

• XHTMLが流行らん理由
• XHTMLは何がいいのか
• htmlに戻りそう
• HTML は何がいいのか

スタートバーとホームページ

ホームページへ移動する方法が最近のOperaではちょくちょく変わっている。

最初は他の多くのブラウザと同様にアドレスバーにボタンが配置されていた。Opera9からスタートバーが搭載され、ページへ移動する系統のボタンは全てスタートバーへ移された。Opera9.2からスピードダイヤルの導入に併せてスタートバーは標準状態で無効になった。スタートバーに配置されていた検索窓、ブックマークやTop 10などは良いのだが、ホームページボタンへのアクセスが失われてしまったような気がする。概観の設定を開かない限り、今までどこかにあったホームページボタンはなくなる。Top 10などは他のブラウザにない独特の機能ゆえになくてもそれほど違和感を感じないのかもしれないが、ホームページへの移動はそこそこ利用頻度が高いように思う。なんてことをふと思った。実際どうなのかは、知らない。

• やっぱりボタンを押したいのだろうか

文字が全てだ

Web Applications 1.0仕様草案のバージョン管理などが置かれているhtml5.orgにアクセスすると、たった19バイトの文字列がかえってくる。

Text is everything.

application/xhtml+xmlでもtext/htmlでもなく、text/plainが一番(違)。

文字列選択に関するFirefoxとOperaの違い

FirefoxとOperaでは文字列選択時の挙動に幾つかの違いがあるのでこの機会に挙げておこうと思う。なお、何らかの方法によって変えられる項目も幾つか存在するが、全て標準状態での動作を基準とした。

選択可能な文字の上でマウスカーソルがI字型のキャレット状に変化することは、少なくともWindows環境下では一般的と言える。個人的には常にマウスカーソルが十分な大きさを保ってくれるOperaの実装が好みなのだが、Operaのマウスカーソルに違和感を感じる人が居ることも容易に想像できる。

かつてUserJSによってOperaのマウスカーソルもI字型になるようにしようと試みた人がいた。残念ながら今はページが存在しないようなので斉藤さんの紹介記事へもリンクしておく。全ての要素をフォーム周りの要素へDOMで置換することで、OperaのカーソルをI字型にするようなスクリプトだったように思うが、記憶は定かでない。閑話休題。

現状をまとめると以下のようなところだろうか。

• OperaのマウスカーソルはI字型に変化しないないため文字列を選択しにくいと言われることが多い
  • Firefoxで文字列上へポインタを載せてもI字型に変化しない場所はフォーム要素と関連づけられたlabel要素の上だけ
• FirefoxではマウスカーソルがI字型に変化するにもかかわらず文字列選択できないことがある
  • CSSのcontentプロパティによる内容生成部分
• クリップボードへ投げた際の整形に一長一短
  • 最近の傾向として整形するアプリケーションが増えつつあるようには感じる
  • 広い範囲を選択する場合整形の恩恵を受けることが多く、狭い範囲の場合整形がおせっかいとなる事が多い

個人的な用途に照らし合わせるとOperaの実装が好みだが、一般的にはFirefoxの実装が好まれるように思う。だが、内容生成の扱いのわかりにくさが致命的。選択できるか否かはたいした問題ではない。I字型カーソルへ変化するにも関わらず文字が選択できないのが痛い。