- Firefoxデスクトップ版ユーザーにだけ表示されるブログのミニマップは、Firefoxの低い市場シェア 4% の中でも、ブラウザ専用CSS機能を実験した事例
- 核心はFirefoxだけが対応する
element() CSS関数で、実際の実装ではベンダープレフィックス付きの -moz-element() を使用
- この関数は任意のHTML要素を画像のように表示しつつ、テキスト選択、スクロール、遅延読み込み画像の変化までリアルタイムに反映する
- ミニマップの背景は
#main DOMノードを background として描画するCSS 1行が担い、現在のビューポートボックスの移動にはJavaScriptも併用
- Firefox専用機能を活用すると、別途Canvasレンダリングを行わずにページの一部をミニマップの背景として再利用できる
Firefox専用の element() ベースのミニマップ
- ブログ記事のミニマップはFirefoxデスクトップ版ユーザーに表示される機能で、Firefoxの市場シェアは現在 4% と言及されている
- Firefoxは CSS
element() 関数 に対応する唯一のブラウザであり、実際の利用にはベンダープレフィックスが必要
element() 関数は、ページ内の任意のHTML要素を画像のように表示できる
- 表示対象は静的なスクリーンショットではなく、ライブ画像のように動作する
- テキスト選択や、スクロール中に遅延読み込み画像が表示される変化も反映される
実装方法
- 別のHTML要素を背景画像として定義するCSSは次の形
mini-map .screen-image .canvas {
background: white -moz-element(#main) no-repeat scroll center center / contain;
}
-moz-element(#main) が #main DOMノードをミニマップの背景画像として描画する役割を果たす- ミニマップ内の現在のビューポートボックスの移動にはJavaScriptも使われるが、別のDOMノードを描画する核心はCSS 1行
- Firefoxでは
-moz-element を使って、ページの一部をミニマップのように表示できる
1件のコメント
Hacker Newsの意見
10年前、DOM要素を紙のように折りたたむおもちゃのようなJSライブラリ https://oridomi.com を作ったが、折りたたむたびにノードを退屈に複製する代わりに element() が使えるようになることを期待していた。
10年経った今でも、このニッチなCSS機能は他のブラウザに採用されておらず、同時期の CSSカスタムフィルター 仕様もすぐ使えるようになると思っていたのに、いまだに traction を得られていない。
一方では、安全にできないから機能を諦めるのは理解できるが、他方ではCSSカスタムフィルターを本当に欲しかったし、今でもそれでできたはずのことをよく思い出す。
https://lists.webkit.org/pipermail/webkit-dev/2014-January/0...
ミニマップ付きのエディタを使うと、まず最初に オフにする。
コーディングではほぼ最も役に立たない機能で、サイトでも同じように役に立たなさそうだ。内容が小さすぎてどこへ行くのか把握しにくく、短いページでも長いページでも、画面スペースの損失や気の散りを受け入れるほどの利点がない。説明的なタイトルの付いたまともな索引や検索機能のほうが、ページ内ナビゲーションにははるかに優れている。
ミニマップが映えるのは、大きな画像や地図のような本質的に視覚的な対象で、拡大したときに全体のどこを見ているか確認できる場合だ。未来的でクールな機能ではあるが、この実装はあまり優れているようには見えない。
最近のOSはスクロールバーを隠したりできるだけ小さくしたりしようとするが、ミニマップはその問題を解決しつつ、ファイル内容の視覚的な形も少し見せてくれる。テキストは読めないが、長く作業したファイルなら何を見ているのか正確に分かる。
じっと見ることは少なくても視界に入っているので、無意識にしょっちゅう目を走らせている。こういう機能が明らかに万人向けではないのは確かだが、気に入らないからといって役に立たないと考えるのは間違いだ。
たとえばVSCodeはミニマップ内でエラーを赤く目立つように表示してくれるので、その場所へ移動しやすくなる。
スクロールバーはページの長さを教えてくれるので読み続けるか判断できるが、ミニマップは「短い記事の後ろに無視していいコメントが何ページも付いている場合」と「そもそも読むには長すぎる記事」を見分ける助けになる。
ただ、自分はコードを 視覚的・空間的 に考えるタイプで、ファイルも必要になるまで分割しないので、ファイルの「形」を見て素早く移動する助けになる。特にファイルが明確なセクションに分かれているときはそうだ。
大きな画像や地図についても同意する。ほとんどの画像エディタにはそうしたビューポート機能があり、細かな作業をするときかなり便利だ。
用途は分かるが、かなり wild だ。テキストを選択すると リアルタイム更新 され、ほぼ同じコンテンツに向けた別個のビューポートのように見える。
ユースケースや含意について考えているところだが、offscreen や
overflow:hiddenのトリックで隠された要素にも動作させられる。とはいえ、知る限りライブラリなしでその要素を画像に変換する方法はまだなく、おそらくプライバシー保護のためだろう。MDNのページがかなり短いので疑問が多い。CSSフィルターや歪みを要素に直接適用できるのだろうが、これが背景のように扱われることで新しい可能性が開けるのだろうか。かなり前から存在していたのに初めて聞いたし、こういう機能がCSS候補に入っているとは思わなかった。Firefoxだけを対象にしてChromeは気にしないとした場合、ビューポート複製以上の用途がどれほどあるのか気になる。
たとえば編集用途にも使えるし、見落としているユースケースも多そうだ。根本的に必須の機能ではないが、それぞれなりにクールではある。
毎日 Chromeでしか動かないサイト に出くわす。そろそろ反撃の時間だ :)
先月American航空の国際線チェックインをしていたとき、Firefoxでは必要なチェックボックスが表示されずチェックイン手続きを完了できなかったが、Chromeでは見えると分かってようやく進めた。
Vanguardのより obscure なページでコンソールエラーが出て壊れるのを経験し、Chromeに切り替えると動いた。
Firefoxで問題なく動いていたページが今では動かないことをよく目にし、時々ほかのブラウザを起動しなければならない。本当にそういうことではないと願っている。デフォルトではFirefoxを使っている。
Firefoxでは
element()が2011年から-moz-付きで完全にサポートされていたのに、他のブラウザでは部分的なサポートすらないようで驚いた https://caniuse.com/css-element-functionクロスブラウザ対応さえあれば、ミニマップ以外にもいくつか強力なユースケースが思い浮かぶ。ChromeやWebKitチームにつながりのある人がいたら、その理由が気になる。単に関心が薄いのか、性能よく実装するのが難しいのか、厄介なセキュリティ問題があるのか知りたい
element()の役割の一部を果たす**-webkit-box-reflect**がある https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-box...具体的には要素の反射を処理する。個人的には、
-moz-elementの最大のユースケースもまさにその反射だと思うミニマップもかわいいが、タブを3分間idle状態にしておくと起動するスクリーンセーバーのほうがもっと面白い
Webにまだこういう遊び心が残っているのがうれしい
これは、右クリックでの画像保存やテキスト選択のようなブラウザの基本機能をわざと壊すサイトにひどく悪用されそうな機能に見える
ページ全体を背景画像としてレンダリングしてしまえば、コンテンツを検査したり保存したり翻訳したりできなくなる。これは最初に思いついた例にすぎず、この関数で読者を困らせる悪質なやり方はいくらでもありそうだ
たいていのWebサイトがそんなことをしない理由は、能力がないからではなく、実際にそうする気がないからであり、ひどいWebサイトには人々が競合へ離れていくという経済的な罰が伴う
ただし、企業のイントラネットポータルやひどい地方自治体サイトのように自由市場ではない領域では、この原理はあまり機能せず、ユーザーに敵対的なものがより頻繁に現れる。一般に、Webサイト運営者を意図的に制約すればWebサイトの質が上がると考えるのは誤りで、実際には逆だ
長い記事でミニマップがどれほどうまく動くのか印象的だ。適当にクリックしていたら https://www.stefanjudis.com/notes/should-responsive-images-w... にたどり着いたのだが、ミニマップが即座に表示され、テキスト選択のような操作にも同期して更新されて、ちょっと魔法のように感じる
Sublime Textのようにミニマップを操作してスクロールできないのは少し残念だが、Webサイト作者の立場では実装がもっと難しそうだ。それでも、Webでこういうことができるのはとてもすごいし、この複雑なCSS機能をChromeやSafariでサポートするにはどれほどの作業が必要なのか気になる
GPUとChromeの動画デコードの間に妙な非互換があって、この1年はFirefoxを使ってきた
フレームドロップが起きて、YouTubeの画質も下がった。Firefoxでは本当に良いWeb翻訳機がないこと以外、大きな問題は感じていない。
-moz-elementはよさそうだし、他のブラウザにも来てほしい主な理由は、フォルダを見るだけでプロファイルを見つけられるポータブル版を標準提供していて、同期にとても便利だからだ。だが遅すぎる。CPUを食いまくるメールやフィードを切っても速くならず、Firefoxに戻って整理してみるとあまりに軽快で、
normal、dev、mediaの3つのプロファイルとブックマークで残りを処理するほうがよいと思ったVivaldiのUIオプションと設定可能性はすばらしいが、Tree Style Tabsやいくつかのアドオン、UIのCSSハックまで加えると、またFirefoxをメインブラウザにして、何事もなかったかのように振る舞っている
ただ、Firefoxにはコンパイル済みWebGLシェーダーをキャッシュしてほしい。その点だけはChromeが圧倒している。設定で調整できるのかもしれないが確認はしておらず、デフォルト状態ではシェーダーの多いページを再読み込みすると、Chromeはモバイルでもほぼ即座に終わる一方、Firefoxはシェーダー次第で時間がかかることがある
これからは「Chrome/Edgeで最もよく動く」ではなく、Firefoxで最もよく動くを見られるなら悪くないと思う