少し時間が経っていますが、遅ればせながらコメントさせていただきます。
トピックタイトルは「Webページの保存方法について、お尋ねします」なので、その部分を中心に書きますが、文面を拝見すると話が多岐にわたっているように感じられ、ぼくの能力では要点をつかみきれません。ご期待にそわない話になってしまったらごめんなさい。
aoibara さんが書きました:
Webページの保存方法について、お尋ねします。
ブラウザが Web ページを保存する際の "標準仕様" があるのかどうか、といったことは存じませんが、エンドユーザーとしての使用体験から、だいたい次のようなことを把握しています。
ブラウザの Web ページ保存における [Web ページ、完全] 形式(ブラウザウによって表記は若干異なりますが)は、そのときブラウザが表示しているコンテンツの構造を、HTML ファイルとして書き出し、HTML 内で直接定義されている外部のリソース(画像、CSS 、JavaScript などのファイル)を、対応するフォルダ内に書き出します。
そして、ローカルに構成された HTML ファイルとフォルダ内のリソースの関係に合わせて、HTML ファイルの当該箇所の URL が書き換えられます。(ただし、HTML 内で定義されていても反映されない例外もあります。)
ただし、この動作は HTML から読み込んだ外部の CSS や JavaScript 内で定義されている別のリソースにまでは及ばないようです。
HTML 内で定義されている外部の CSS ファイルや JavaScript ファイルは保存されますが、その CSS ファイルや JavaScript ファイルの中で定義されている外部のリソースは保存されませんし、CSS や JavaScript の当該箇所の URL も基本的には書き換えられません。
一方、HTML 内の <style> や <script> タグでまとめ書きされたり、個々にインラインで指定された CSS などに含まれる外部のリソースは、ローカルに保存されますし、それに応じて HTML 内の当該箇所が書き換えられるケースもあるようです。
[Web ページ、完全] 形式でのページ保存におけるこの動作は、Firefox に限らず他のブラウザでもおおむね同じで(*)、ベースとなる HTML ファイルからたどれる範囲が限られているようにみえます。もちろん、サイト側の作りに影響されることもあるでしょう。
これが意図した "仕様" なのか、現時点での "制約" なのかは知りませんが、動作としてはそういうことになっているのを、経験の範囲で知っています。
(*)ブラウザの保存結果について
Firefox などの Gecko 系、Iron や Opera などの Webkit / Blink 系、Internet Explorer などの Trident 系、それぞれのレンダリングエンジンを持つ複数の現役ブラウザで [Web ページ、完全] 形式での保存を実際に試した結果、現行のメジャーなブラウザで、HTML からたどる CSS やさらにその先の CSS など深い階層で指定された画像データを保存できたものはありませんでした。
唯一、Presto 時代の Opera 12 が、[Web ページ、完全] 形式に相当する [画像付 HTML ファイル] 形式で、外部 CSS などに指定された画像を保存でき、ブラウザ単体でのページの保存・再現性は抜きん出て高かったです。
【CSS で背景画像を指定する際の工夫について】CSS 内に 画像ファイルの URL を指定する方法もありますが、ご質問にある「メニューボタン」の背景のように小容量で随所に使われる画像を配するケースでは、"Data URI scheme" で CSS 内に埋め込んでしまう方法もあろうかと思います。
これだと、HTML からたどって CSS ファイルが保存されれば、画像データも同時にローカルに取り込まれるわけです。
ブラウザの Web ページ保存の動作というよりは、CSS の作り方にフォーカスした話になってしまいますが、制作者側のこうした工夫でより多くのユーザー環境に対応できることもあります。どうしても画像ファイルを直に URL 指定しなければならいご事情があるのかもしれませんが、参考までにひとこと述べさせていただきました。
(補足)
いわずもがなですが、Web ページを構成する要素のうち、メインとなる情報・コンテンツは HTML に記述するのが原則で、装飾的要素は CSS 、さらに動的な効果や付加的な機能は JavaScript が使われます(サーバーサイド・スクリプトの働きは割愛)。
画像も、それ自身が情報として意味を持つもの(例:「商標」や「製品見本」の写真とか)であれば、HTML 内で指定するのはご承知のとおりです。背景とかアクセントとして用いる装飾的な画像は CSS で扱うのが望ましいわけですが、装飾的要素とはいってもアクセシビリティやユーザビリティの観点から重要度の高いものは、扱いにも工夫が必要になる、というのが上述の話です。
ユニバーサルデザインの観点からいえば、画像が保存できないとか読み込めなかったといった些細なトラブルでただちにページのナビゲーションに支障をきたすようなデザインは、あまり好ましいものとはみなされません。例えば広告表示の抑制などで画像をブロックしているユーザー環境では、制作者が指定した画像も意図せずブロックされてしまうことがあり、地の背景とテキストのカラーがかぶって可読性が損なわれるようなケースが生じうるからです。
あらゆる閲覧条件に対して 100 %の完全さは望めませんが、多様なユーザー環境に対して可能な限り共通のサービスを提供できる堅実なデザインが重視されます。そういう視点から、ページのナビゲーション上基本となるメニュー部分は、シンプルで確実性の高い仕様が求められることが多く、そのためボタン類に画像の背景が使われるケースが少ないのではないでしょうか。表現意図があって画像を使う場合も、ブロックボックスの背景色とか周辺要素にもプラスアルファの配慮がされることが多いように感じます。【ブラウザの Web ページ保存機能をテストする際に注意すること】これもご承知かと思いますが、ローカルに保存した HTML や CSS などで指定された外部の要素は、それ自体がローカルに保存されていなくても、HTML や CSS 内に含まれる指定状態によっては、オンライン状態のブラウザで保存ファイルを開いたときに外部から読み込んでしまうケースがあります。わかりやすい事例では、絶対 URL で指定されているケースなどでしょうか。
また、ブラウザがすでに保持しているキャッシュデータが使われてしまうこともあります。
具体的な挙動はブラウザやユーザーの環境設定にも依存するはずですが、こうした挙動は [Web ページ、完全] 形式だけでなく Web アーカイブ形式(*.mht)でも同様のことが起こります。
このような事情から、保存したデータとその表示状態をできるだけ正確に把握しようと思えば、ブラウザをオフラインで動かし、そのつどキャッシュをクリアする心がけが必要になります。その上で、オンライン状態での表示などもつかんでいけば、各段階での状態を切り分けていけるはずです。
(ぼくも昔、これで失敗したことがありますので、念のために書かせていただきました。上述のテストもこのやり方でおこなっています。)
ぼくからのコメントは以上です。
ぼく自身は Web の開発者やデザイナーではない一介のエンドユーザーに過ぎません。強いていえば、発注者側の一員として Web サイト構築のコンセプトワークに参加することが、ごくたまにある程度です。なので、技術的に正確とは言い難い部分があると思いますから、そのあたりは他のユーザーさんから訂正や補足をいただけるとありがたいです。