気ままなネットサーフィンとネットショッピング等を一つのブラウザで共用するのは、プライバシー及びセキュリティの観点から少々心配です。
ブラウザを一つに定めずに２つ以上を使い分けることで、プライバシー及びセキュリティの「リスク分散」ができます。
ちなみに「ブラウザを支える技術」の節で詳述しているように、Chrome/Edge と Safari と Firefox/SeaMonkey はそれぞれ異なる実装なので「ブラウザのセキュリティホールも異なる」ことがかなり期待できます。
すると、例えば以下のクラウドサービスをさまざまなブラウザで上手に活用できます。
size\Cloud Google Drive MS OneDrive iCloud DropBox Adobe DC Amazon CD 計
size/free 15 5 5 2 2 5 `${cells.slice(1)[0].slice(1, 7).reduce(function(a,b){ return parseInt(a)+parseInt(b); })}`
一つ一つはそれなりの容量ですが、合わせればかなりの容量になります。
また、大容量を本格的に使いたければ、サブスクリプションで月に約千円でテラバイトが利用できます。
モジラ財団の Firefox は他と同じく最新技術を追うブラウザです。しかし、企業など安定性を求める延長サポート版 ESR (Extended Support Release) もリリースしています。
実は、同じくモジラ財団の SeaMonkey はこの ESR 版をフィードバックしてリリースされています。SeaMonkey の最新版ならセキュリティ修正などはきちんとされるので安心です。
最新の HTML/CSS や Javascript の規格に未対応などの些細な不便はあるのですが、安定性を求めるブラウザとして特に企業などにお勧めです。個人ユースでも、余計な流行り廃りに振り回されたくないという方には向いていると思います。筆者もメインではないですがこれを使っています。
但し、サードパーティの拡張機能などは、SeaMonkey は開発の主流ではなく修正が放置される傾向があるので、導入しないことをお勧めします（Firefox の拡張機能とは仕組みが全く異なるのです）。
クッキーは、例えるなら、サイト運営者が閲覧者の顔を覚えるための仕組みです。実際には「顔」ではありませんが「あ、この前、来客された方だな」という「店主の記憶」に相当します。クッキーを完全オフにしてしまうと閲覧そのものが成り立たないサイトの設計も多くあります。
そのときの来訪記録がブラウザとサイトで共有され、再び来訪すればかつて設定した状態などが復元されます。あくまで便利にサイトを閲覧するための仕組みです。そのサイトで個人情報を了解して渡して初めて、その情報がブラウザとサイト間で紐づけられます。
一方で、サイトは閲覧者の IP アドレスは分かるので、その情報だけでも所在地は推測できてしまいます。だからと言って、プロクシを通してそのサイトを閲覧すれば「目出し帽を被って来店」するようなもので、返って目立ってしまいます。
よって、ネットショッピングなど適切に最小限の個人情報を了解して渡しているときは、次に紹介する方法などせずに「普通に」ブラウザを利用すればよいのです。
問題は、ネットショッピングなどせずに、何か興味の赴くまま気楽に検索したりしてネットサーフィンするときだと思います。
普段使いでは「一見さんモード」で閲覧することをお勧めします。これはクッキーが一時的なものになります。ブラウザごとにモードの名称が異なるので、以下にまとめておきます。
ブラウザ 「一見さんモード」名称と使い方 Safari プライベートブラウジング Chrome シークレットウィンドウ IE インプライベートブラウズ Edge インプライベートブラウズ Firefox プライベートブラウジング
これは、「一見さんモード」起動時から新たなクッキーが保存されるというだけで、何か情報を秘匿するというわけではありません。例えるなら、このモードのときはいつも「一見さん」としてサイトを訪れるということになります。
このモードのアイコンはたいてい「仮面舞踏会の変装」のようなデザインになっていますが、変装しているというより初めて来訪した閲覧者ということです。IP アドレスと照らし合わせれば「変装しているかも」と推測はできるでしょう。
バーチャル空間とは言え現実と同じく常識的な振る舞いをしなければならないことは言うまでもありませんが、「プライベートモード」はその上で「私は一見さんで、しかも、顔を覚えてもらわなくて結構です」という意思表示と言えます。
また、ブラウザのタブを閉じない限り生成されたクッキーは使い続けられます。よって、タブを閉じたりブラウザを終了したときが「お店から退出」ということを意識しましょう。
その上で少々心配なのが、広告運営会社によるトラッキングです。サイト運営会社と広告運営会社がまったく無関係で、サイトポリシーが広告運営会社に及ばないケースも多分にありますので、「一見さんモード」でも心配になることもあるかと思います。
そのときは、ブラウザの「トラッキング拒否」機能を「確認」しましょう。あくまで既定値にしておくことをお勧めします（つまり、拒否をわざわざ宣言したりしない）。あまり強固にすると返って目立ってしまいます。
ブラウザ 「トラッキング防止機能」名称と使い方 Safari サイト越えトラッキング防止 Chrome トラッキング拒否 IE インプライベートブラウズ Edge 追跡防止 Firefox トラッキング拒否
確認して安心する程度のことぐらいしかやりようがない、ということが分かると思います。しかし、それぞれ書いてあることを読むと、Safari と Firefox のバランスのよい機能が利用者にとって合っている等はあると思います。メインのブラウザをどれにするか、などの判断基準につかえるかもしれません。
ここでの指南は万人にはお勧めしかねますが、以下の「広告ブロッカー」をブラウザの拡張機能で使います。ここでは、筆者が信頼できると判断したものに限ります。
これらの拡張機能のセキュリティホールに注意を払う必要があるので、そういった手間を厭わない方なら検討すればいいと思います。
また、特にスマートフォン向けに「偽物の広告ブロッカー」が出回ったりしていますので注意してください。
位置情報には「大まかなもの」と「ピンポイントのもの」の２通りあります。結論として以下のようになります。
ピンポイントな位置情報はスマートフォンの GPS でサービサーに知らしめる地球上の緯度・経度・高度・移動速度などです。閲覧者が位置情報を渡すことに同意して初めてサービサーに伝わります。道案内など位置情報を知らせる必要があるときのみ同意しましょう。
大まかな位置情報とは、インターネットで通信をサーバとやり取りをする際に必ず必要となる IP アドレスから得られる所在地となります。スマートフォンであればキャリアが利用者を収容する割り当てられた IP アドレスとなり、少なくとも日本などの国単位は簡単に判明します。PC であればプロバイダが利用者を収容する IP アドレスとなり「市町村」ぐらいまでは実は分かってしまいます。
IP アドレスをわかりにくくするには、よく刑事ドラマなどで聞き及ぶ「犯人は海外のサーバを経由してて云々」の「怪しいプロクシーサイトを通す」方法がありますが、プロクシーサイトそのものがすべての情報を握るわけなのでかなりリスキーな手段となります。より高度な手段に匿名化接続経路 (Tor: The Onion Router) を使う方法がありますが、ドメイン名の問い合わせに匿名化されていない DNS は使われるものですから、DNS 管理者にはその IP アドレスの利用者がどのサイトにアクセスしているか分かりますし、大まかな位置情報も分かり得ます。これらはそもそも「真っ当じゃない通信を行ってます」と宣言しているようなもので、返って目立っています。
よって、サイト管理者やサービサーに IP アドレスとその大まかな位置情報が分かってしまうことは「当人も了解」しているものと理解してください。むしろ、悪意ある第三者にそれが漏洩しなければ幸いとしなければなりません。それも利用者の不注意（悪意ある広告などをクリックしてしまうなど）でなければ、利用者本人が努められることは皆無なので、利用しているサイトに脆弱性がないことを信じるほかありません。その意味では「広告ブロッカー」で余計なサイトアクセスを予め防いでおくことは極めて効果的です。
ウェブサービス上の「ログイン」とは、ある程度のプライバシー情報を渡すことを了承して利便性を享受するサービスと捉えてください。よって、先の「一見さんモード」と名付けたプライベートブラウジングとは両立しません。
よって、ブラウザのプライベートブラウジングのウインドウ・タブからは決して「ログイン」しないようにしましょう。
「広告ブロッカー」は併用可（不便があれば広告ブロッカーの設定を緩和することも可能）
万が一「ログイン」してしまったとしても即時に何か不都合があるわけではありませんが、利便性を享受するための機能の一つである「クッキー」をブラウザの起動毎に忘れてしまうわけですから、不便になってしまいますし、長期的には意図しないプライバシー情報を「ログイン」サービス提供元が保持することにも繋がります。
そして、「ログイン」サービス提供元のユーザ管理画面で、プライバシー情報を編集・削除などができるか、利用の早いうちに確認しておいた方が懸命です。少なくとも大手 Apple, Google, Mozilla, Amazon はそういった管理画面は用意されています。本当に削除したかは中の人ぞ知るのみで、ここは信用するしかありません。
しばしば、情報漏洩のニュースなどは見聞きしますが、一般ユーザは、パスワードを適切に管理する以上のことはやりようがないので、そもそも不必要なサービスへのログインの登録は控えた方が懸命です。無論、信頼できないサイトでのログインなど言語道断です。
この節は専門的なので、コンピュータ技術者の方以外は読み飛ばして構いません。
ブラウザソフトウェアを支える中核技術について簡単に表にまとめておきます。必要とされる技術が似るウェブ技術実行環境である Node.js などについても比較として併記しておきます。
browser\engine HTML/CSS Javascript CG Konqueror KHTML KJS cairo+DirectX+OpenGL Firefox Gecko+Servo SpiderMonkey cairo+DirectX+OpenGL Chrome Blink V8 skia+DirectX+OpenGL Edge EdgeHTML﹥Blink Chakra/V8 cairo+DirectX+OpenGL Safari WebKit JavaScriptCore Quartz+OpenGL+Metal IE Trident JScript9 DirectX Opera Presto﹥WebKit﹥Blink Presto﹥JSCore﹥V8 * runtime environment Node.js - V8(|SpiderMonkey|Chakra) - Deno - V8 -
大まかにしか記せませんが、マイクロソフト Edge 及び、ブラウザシェアが皆無になってしまった Opera の動向をみると、ウェブ技術が Google による Blink (HTML/CSS 処理系) と V8 (Javascript 処理系) に集約されつつあると同時に、Netscape 起源の Mozilla 財団による Gecko+Servo (HTML/CSS 処理系) と SpiderMonkey (Javascript 処理系) が対抗馬として大いに貢献しているといえます。
役割を終えた Internet Explorer 起源の Chakra (Javascript 処理系) も ChakraCore としてオープンソース化され存在感を残していますが、現状ではセキュリティ修正が主な進捗のようです。
ウェブの健全な成長には、決して Google による寡占状態は好ましいとは言えず、Mozilla や Apple が対抗馬として期待され、マイクロソフトが Edge にて独自開発を諦め Google によるオープンソース技術を採用した現状、Unix 系 KDE による KHTML (HTML/CSS 処理系), KJS (Javascript 処理系) とその子孫である Apple らによる WebKit (HTML/CSS 処理系), JavaScriptCore の発展が何より欠かせません。ちなみに、Google の Blink の祖先は KDE の KHTML であるので、Mozilla 系の Gecko, SpiderMonkey が絶えてしまうと、事実上ほぼ Google の寡占となってしまいます。
とは言え、同じ祖先をもつ Blink と WebKit は袂を分ち、既にほとんど別物と言えるかもしれません。得意とする処理がまったく異なるエリアで棲み分けられている感触はあります。例えば、Chrome は動画などマルチメディアが絡むと快適な印象で、Safari は印刷やフォントで堅牢な印象があります。比較ついでに、Firefox はオールマイティで安定して高速で、かつ、マルチメディアが絡んでも爆速ということは無いのですが、レンダリングの品質も常に高いという印象です。（あくまで筆者個人の印象です。）
ブラウザとウェブサービスの双方を開発しているベンダーの様子をみてみるとウェブ技術の一端が覗けます。
ブラウザ\付加価値 ウェブアプリ ウェブサービス Chrome Docs/Sheets/Slides Google Drive Safari Pages/Numbers/Keynote Apple iCloud Edge Word/Excel/PowerPoint Microsoft OneDrive
実は、これらのほとんどが相互に利用できます。多少、Safari が他のベンダーの対応状況が遅いといった印象です。また、規格が競合している技術、例えば、絵文字の OpenType やウェブフォントで、Chrome と Safari で相互に絵文字が印字されないなどのバトルはあったりしますが、ほとんどのサービスはどこでも動作します。そして、Firefox がこれらの利害関係にないのでオールマイティに対応しているというのが現状です。
ウェブコンテンツ開発者がマイクロソフト IE による独自挙動に悩まされる黎明期は終わりを告げ、Google Android と Apple iPhone によるモバイルインターネットがコンピューティングの主流になっています。
モバイルで劣勢なマイクロソフトとは言え、自社オフィス製品を主軸とした OneDrive のクラウドサービスにおいて依然強みを発揮しており、Google, Apple も同様にクラウドサービス Google Drive, iCloud をモバイルでの強みが十二分に生かされています。
一方、ウェブ技術はブラウザベースにデスクトップからモバイルを経て、Node.js, Deno などから伺えるように、今度はまたサービスベースにブラウザからデスクトップへと回帰しつつあります。開発者としては、デスクトップもウェブサービスも利用者には区別しない・させない時代を迎えてつつあるのだと実感しています。
簡単にできるので、ちょっとしたプログラム体験をしていただきましょう。
世界中のネットコンテンツを保存する WayBackMachine に行って、無くなってしまったページの URL を打ち込めばよいです。
ここでは、その作業を「ブックマークレット」というブックマークの機能でいつも使えるように便利にします。題材として、筆者の出身大学のかつて存在した研究室のページを使います。
このリンク http://www.bes.d.dendai.ac.jp/~taiji/index-j.html 「アクセスできません」を後で踏んでもらいます。今踏んでもよいですが、ブラウザのエラーページからここに戻ってきてください。
さて、WayBackMachine に行って URL を打ち込むことと「等しい URL」とは一体なんでしょうか？これはサイトごとに異なるのでやってみて調べるしかないのですが、結局 WayBackMachine では、https://liveweb.archive.org/http://www.bes.d.dendai.ac.jp/~taiji/index-j.html とすればよいことが分かります。普通に探すと https://web.archive.org/web/*/http://www.bes.d.dendai.ac.jp/~taiji/index-j.html となり、これでもいいのですが、カレンダーが表示されて日付と時刻を選ぶ必要があり面倒です。
この操作をブラウザのプログラミング言語 Javascript で実現するには以下が動作すればよいことになります。
javascript: location.href = 'https://liveweb.archive.org/' + location.href; // 新たな URL = https://liveweb.archive.org/元の URL
この location はブラウザのウィンドウが持っている変数で、その中のプロパティ href が URL になります。ですから、先の「アクセスできません」状態のウィンドウでこの Javascript を発動させればよいことになります。
このままではブックマークに登録できませんので、ブックマークレット用 Javascript コードを URL 化 するページでこのコードを「一行」に変換します。それが「WayBackMachine に行く」ブックマークレットです。
そして、「アクセスできません」のページにて「WayBackMachine に行く」ブックマークレットを選びます。かつてのページが表示されれば成功です。
リンク切れになった URL がトップページ一つなら手動で WayBackMachine に行って探すことも面倒ではありません。
しかし、表題のように、古い記事でせっかく貼られているリンクがことごとくリンク切れだった場合は大変です。題材として、このページとここで貼られている URL 群を使います。
つまり、見えているページのすべてのリンクの頭に https://liveweb.archive.org/ を付けてしまえばいいのです。
少し難しいですが、その古い記事のリンクすべてを先の例と同様に、以下のように書き換えてしまいます。理解するには HTML の DOM (Document Object Model) と CSS のセレクタの知識が必要ですが、まずは雰囲気が分かれば十分です。
javascript:
for (const e of document.body.querySelectorAll("a[href^='http']")) {
e.href = 'https://liveweb.archive.org/' + e.href;
}
void(0);
謎な箇所だけ先に説明します。末尾の「void(0);」は、ブックマークレット自体が「返り値」を返してしまうと、その状態を示すページに遷移してしまうのです。ここでは、直前の中括弧の中身の代入が値をもつので、それが返り値として有効な状態です。それを無効化するために末尾の「void(0);」が必要になります。
中括弧は繰り返し構文 for 文の中身を表していまして、この文書のすべてのリンク、セレクタで表すところの「a[href]」すべてを繰り返しで処理します。
どのように処理するかというと、先の例とほぼ同じで、e.href = 'https://liveweb.archive.org/' + e.href; とリンクを書き換えています。
このままではブックマークに登録できませんので、ブックマークレット用 Javascript コードを URL 化 するページでこのコードを「一行」に変換します。それが「WayBackMachine で復活」ブックマークレットです。
そして、このページにて、ここで登録したこのブックマークを選びます。見た目には何も変わった様子はありませんが、ポインターをかざして先の「アクセスできません」の URL の頭に https://liveweb.archive.org/ が足されているはずですし、クリックして WayBackMachine のそのサイトに飛べば成功です。
余談ですが、サンプルコードを単純に保つために、https://archive.org/ に https://archive.org/ を足してしまわないようにする工夫は省略してしまったのですが、驚いたことに WayBackMachine のサイトは自身のサイトの過去も保存していることに気づいてしまいました。
手前味噌になりますが、拙作ブックマークレット集を用意しておきましたので、活用するなり、Javascript の教材に使うなり、参考にしてください。
本稿ではブラウザを中心に以下を取り上げました。
ブラウザシェアが高ければよしとする切り口では物事の本質は捉えきれません。高すぎるシェアはユーザに不利益をもたらす事実は歴史から学べます。かつて IE が市場を独占した結果がセキュリティ問題の蔓延でした。そして、Chrome が IE を駆逐し、我々は IE の独自仕様から解放されました。自社の過去の製品の互換性を大切にするマイクロソフトが IE を辞め、他社との共存に舵を切り直しましたのです。
他社との共存と言えば、ここでのブラウザの話題にほとんど登場しなかった Adobe の動向が重要です。いつの時代でも Adobe は重要な役割を演じてきました。かつての PostScript フォントや macOS 前身 NeXT の Display PostScript などがそうです。
Adobe は興味深いことに競合する企業を買収して、しかも、時にはそこの製品をきっちり終わらせてしまいます。買収した macromedia の Shockwave Flash は好ましくない成長をしてしまったことから、利用者が多かったにも関わらず、代替のウェブ標準の確立と成熟を見届けてサポートを終了させました。「終わりよければすべてよし」とは少々違っていて「引き際が肝心」ということだと思うのですが、なかなか出来ることではないと思います。
特に注目なのは、Google と共同で開発した東アジアのフォントをオープンソースで公開したことです。この遠因は日本の IPA フォントにも少なからず繋がるのですが、紙媒体の利用が少なくなるとは言っても字体の需要はなくならないわけですから、フォントのような基盤技術をもった Adobe は戦わずして常に勝者といった印象です。
そして、新たなフォント技術である「さまざまな軸」という概念をもつ Variable フォントの登場です。ラテン文字から漢字まで省スペースなのにリッチなフォントがモバイルやウェブを中心に発展していくことは間違いありません。今やスマートフォンからデスクトップへと軽量化した技術が逆輸入する時代です。
そして、時流の機械学習なども援用して、業界のあり方さえも変えてしまう面白さと怖さも潜在していると思われます。
また、フォントのグリフに「色がつく」なんて筆者は想像もしてなかったのですが、日本のガラケーから Google らによる現在の「絵文字 (Emoji)」、そして Apple による「アニ文字」です。フォントのグリフが動くということではないようですが、どんでもない発想が規格になったりと現実は想像を超えてくるので、先の Variable フォントとも大いに関係してきそうですし、技術者としてはまったく油断できません。このように、一見くだけた用途が大真面目な応用に化けたりするのがウェブの世界だったりするので、今後も目が離せません。
下記はこちらの記事の転載であるが、クロスチェックに必要なので、しばらくそのままにしておく。
ここの話題は CSS 変数（カスタムプロパティ）とその寿命に関係する。
さて、table[border] つまり、テーブルの border 属性が HTML Live Standard で廃止ということで、ブラウザが事実上サポートを続けるかもしれないが、準備はしておきたいと思った。
本節の末尾で紹介するクラス付きテーブルスタイル table.border を使うと、border 属性付きテーブルとほぼ等価な見栄えになる。左がブラウザ既定、右がこのスタイルによる実現である。
| 0,0 | 0,1 | 0,2 | 0,3 | 0,4 | 0,5 | 0,6 | 0,7 |
|---|---|---|---|---|---|---|---|
| 1,0 | 1,1 | 1,2 | 1,3 | 1,4 | 1,5 | ||
| 2,0 | 2,1 | 2,2 | 2,3 | 2,4 | 2,5 |
| 0,0 | 0,1 | 0,2 | 0,3 | 0,4 | 0,5 | 0,6 | 0,7 |
|---|---|---|---|---|---|---|---|
| 1,0 | 1,1 | 1,2 | 1,3 | 1,4 | 1,5 | ||
| 2,0 | 2,1 | 2,2 | 2,3 | 2,4 | 2,5 |
これで実用的には十分なのかもしれないが、多少汎用性を持たせよう。border="2" と指定したときのようにスタイルファイルで見栄えを実現する。そのために CSS 変数を活用してみよう。インラインスタイル定義としてテーブルの属性 style="--table-border-width: 2px;" を付記すればよい。左がブラウザ既定、右がこのスタイルによる実現である。
| 0,0 | 0,1 | 0,2 | 0,3 | 0,4 | 0,5 | 0,6 | 0,7 |
|---|---|---|---|---|---|---|---|
| 1,0 | 1,1 | 1,2 | 1,3 | 1,4 | 1,5 | ||
| 2,0 | 2,1 | 2,2 | 2,3 | 2,4 | 2,5 |
| 0,0 | 0,1 | 0,2 | 0,3 | 0,4 | 0,5 | 0,6 | 0,7 |
|---|---|---|---|---|---|---|---|
| 1,0 | 1,1 | 1,2 | 1,3 | 1,4 | 1,5 | ||
| 2,0 | 2,1 | 2,2 | 2,3 | 2,4 | 2,5 |
Firefox, Chrome, Safari それぞれが異なるのでまったく同じにはならないが、むしろより自然な様相になってると思う。
さて、せっかくここまで再現できたので、少し調子に乗って他によく使われる table[border][rules='all'] だけはサポートしておこうと思った。
本節の末尾で紹介するクラス付きテーブルスタイル table.border_rules-all を使うと、border, rules='all' 属性付きテーブルとほぼ等価な見栄えになる。左がブラウザ既定、右がこのスタイルによる実現である。
| 0,0 | 0,1 | 0,2 | 0,3 | 0,4 | 0,5 | 0,6 | 0,7 |
|---|---|---|---|---|---|---|---|
| 1,0 | 1,1 | 1,2 | 1,3 | 1,4 | 1,5 | ||
| 2,0 | 2,1 | 2,2 | 2,3 | 2,4 | 2,5 |
| 0,0 | 0,1 | 0,2 | 0,3 | 0,4 | 0,5 | 0,6 | 0,7 |
|---|---|---|---|---|---|---|---|
| 1,0 | 1,1 | 1,2 | 1,3 | 1,4 | 1,5 | ||
| 2,0 | 2,1 | 2,2 | 2,3 | 2,4 | 2,5 |
素晴らしい！実用上、これらの属性（但し、rules='all' のときのみ）がブラウザで廃止されても困らない。
一応、border="5" としたときの対応として、インラインスタイル定義としてテーブルの属性 style="--table-border-width: 5px;" を付記したものも実現しておこう。
| 0,0 | 0,1 | 0,2 | 0,3 | 0,4 | 0,5 | 0,6 | 0,7 |
|---|---|---|---|---|---|---|---|
| 1,0 | 1,1 | 1,2 | 1,3 | 1,4 | 1,5 | ||
| 2,0 | 2,1 | 2,2 | 2,3 | 2,4 | 2,5 |
| 0,0 | 0,1 | 0,2 | 0,3 | 0,4 | 0,5 | 0,6 | 0,7 |
|---|---|---|---|---|---|---|---|
| 1,0 | 1,1 | 1,2 | 1,3 | 1,4 | 1,5 | ||
| 2,0 | 2,1 | 2,2 | 2,3 | 2,4 | 2,5 |
rules='all' 以外のクラスもいずれ作成しておくかもしれない。
さて、ここで style="--table-border-width: 5px;" などを付記しているので、万が一次のテーブルで枠線が太いままだったら困る。最初の例の表をそのまま載せてみる。
| 0,0 | 0,1 | 0,2 | 0,3 | 0,4 | 0,5 | 0,6 | 0,7 |
|---|---|---|---|---|---|---|---|
| 1,0 | 1,1 | 1,2 | 1,3 | 1,4 | 1,5 | ||
| 2,0 | 2,1 | 2,2 | 2,3 | 2,4 | 2,5 |
| 0,0 | 0,1 | 0,2 | 0,3 | 0,4 | 0,5 | 0,6 | 0,7 |
|---|---|---|---|---|---|---|---|
| 1,0 | 1,1 | 1,2 | 1,3 | 1,4 | 1,5 | ||
| 2,0 | 2,1 | 2,2 | 2,3 | 2,4 | 2,5 |
流石に変数が上書きされてしまうようなことはない。からくりは CSS 変数はスタイルの継承によって参照・定義されるので、この場合、これらは要素の継承関係にはないので、意図しない変数の変更には至らない。至極当たり前のことなのだが、実際に確認してみて納得できた次第である。
では、最後にこのスタイルファイルを紹介しておく。
table.border {
border-color: darkgray;
border-style: outset;
border-width: var(--table-border-width, 1px);
border-collapse: separate;
border-spacing: var(--table-border-spacing, 2px);
}
table.border > :is(thead, tbody, tfoot) > tr > :is(th, td) {
border-color: darkgray;
border-style: inset;
border-width: var(--table-td-border-width, 1px);
}
table.border_rules-all {
border-style: outset;
border-width: var(--table-border-width, 1px);
border-collapse: collapse;
}
table.border_rules-all > :is(thead, tbody, tfoot) > tr > :is(th, td) {
border-style: solid;
border-width: var(--table-td-border-width, 1px);
}
但し、SeaMonkey ではセレクタ :is() が働かないので多少工夫を要するのだが、時間が解決する問題だと思うのでそのままにしておく。