Japanese version of this post is also available.

The 2nd topic in the series, “Rethinking ScrapBook’s Browser Context Menu”.
This time, I kick around the [Capture Frame] menu which apprears with [Capture Page] when we click in a frame / inner-frame. In the Firefox’s standart context menu, all menus related to frame are submenus inside the [This Frame] menu. Hence [Capture Frame] should be inside the [This Frame] menu in a similar way.

Contorary to that, the standpatters might have such viewpoints:
Additional menus of extensions should not scatter and should be placed in one place.
It is easier to choice between [Capture Page] and [Capture Frame].

As a developer, I have a following viewpoint. [Capture Frame] inside [This Frame] is surely sensible, however, I’m afraid some people mistakenly thought that [Capture Frame] was gone!

Please let me hear your thoghts or comments.

Current: [Capture Frame] and [Capture Page] are in parallel position.

Alternative: [Capture Frame] should be the submenus inside [This Frame].

Japanese version of this post is also available.

The 1st topic in the series, “Rethinking ScrapBook’s Browser Context Menu”.
First time, I kick around the most popular [Capture Page] and [Capture Page As…] menus.
Today we have these menus at the bottom of the browser context menu. However, the feature of [Capture Page (As…)] is similar to Firefox’s [Save Page As…] one, so they should be ‘neighborhood’ each other. At least, both should be placed in a same category between two separators.

Contorary to that, the standpatters might have such a viewpoint: additional menus of extensions are below Firefox’s standard menus in rank.

Please let me hear your thoghts or comments.

	Current We have [Capture Page (As…)] at the bottom.
	Alternative [Capture Page (As…)] and [Save Page As…] should be placed in close position.

English version of this post is also available.

ScrapBookのブラウザ上のコンテキストメニューについて見直すシリーズ、その２。
今回はフレーム上で右クリックしたときに「ページの取り込み」とともに表示される「フレームの取り込み」メニューについての比較検討である。Firefoxの標準のコンテキストメニューでは、フレームに対する操作はすべて「このフレーム」というメニューのサブメニューとして表示される。したがって、「フレームの取り込み」メニューは「このフレーム」メニューのサブメニューであるべきだと言える。
逆に、現状維持派の言い分としては、「ページの取り込み」と「フレームの取り込み」が並んでいる方が直感的にわかりやすく、二者択一しやすい、あるいは、拡張機能による付加的なメニューはあちこちに分散すべきでない、一箇所にまとめるべきだ、といった見解がだろうか。
また、開発者の言い分としては、確かに代替案の方が理にかなっていると思うが、今頃になって突如メニューの配置を変えるとなると、それに気付かずに「フレームの取り込み」機能が無くなってしまったのかと勘違いされるのが嫌だ、というのが一番大きい。

▲現状 「フレームの取り込み」は「ページの取り込み」と並列関係にある。 ▼代替案 「フレームの取り込み」は「このフレーム」のサブメニューとすべき。

English version of this post is also available.

ScrapBookのブラウザ上のコンテキストメニューについて見直すシリーズ、その１。
まずはもっともポピュラーなメニューである「ページの取り込み」「ページの詳細な取り込み」の位置についてである。現状では、これらのメニューはコンテキストメニューの最下部に表示される。しかし、ScrapBookの「ページの取り込み」機能はFirefoxの「名前を付けてページを保存…」の類似機能であることを考慮すると、これらのメニューは近い位置、少なくともセパレータで区切られた同一のカテゴリ内にあるべきだと言える。
逆に、現状維持派の言い分としては、拡張機能による付加的なメニューは標準で備わるメニューよりも位が低いのでより下の位置にあるべきだ、といった見解だろうか。
ぜひともScrapBookユーザの方々の意見をいただきたいと思います。

	現状 「ページの取り込み」は最下部にある。
	代替案 「ページの取り込み」は「名前を付けてページを保存…」に近い位置であるべき。

ScrapBookのページ保存機能ではCSSから参照される画像は無条件でダウンロードされる。たとえば、CSS中に

#hoge { background-image: url('foobar.png'); }

というルールがあれば、たとえ現在のページ中に id=”hoge” が存在しないとしても foobar.png はダウンロードされる。
この仕様だと確かに保存機能の精度は高くなるが、場合によっては無駄なファイルが大量にダウンロードされる。特に最近はCSSを利用したデザインが多い傾向にあるようで、不要な画像ファイルをダウンロードすることによるデータサイズの肥大がかなり気になってきた。
そこで、CSSからは参照されているが、実際のページ(HTML)からは参照されない画像をダウンロードしないための方法を考えてみようと思う。

ロジック:

• CSSのルールから参照される各画像について、それがHTMLから参照されているかどうか判別する
• 現在表示しているHTMLから「実際に」参照されている画像をリストアップし、CSSから参照されている画像のリストと突き合わせて不要ファイルを検出する
  →現在表示しているHTMLから「実際に」参照されている画像のリストアップは「ページ情報」の「メディア」に相当するので、これが参考になるかも？

ユーザインタフェース:

• [設定]の[取り込み]タブに、試験的なオプションを追加する
  →十分なデバッグの後、正式採用する
• 編集ツールバーに[不要ファイル削除]機能を追加する（ボタンまたはメニュー）
  →DOMイレーサーなどでページから削除された（＝参照されなくなった）画像を物理的に削除する機能としても使える