このウェブサイトは，HTML + CSS + Javascript という，（もうすぐ後期高齢者の私にとっては）今風と思われる構成を持っています．というか，いまやそれが必須というか当たり前なわけで．そういうサイトを構築することになるとは，“アカデミックスタイル” の HTML ページを書いていた現役時代にはまったく考えもしませんでした．2021年6月から開始されたその開発の履歴を，以下に残しておきたいと思います．
・これは，だいぶ前にある不純な理由で『自分にも作れるはず』と作ってみたもので，画像切り替え等の操作ページに紹介していましたが，アーティクル内で実際に使うことは今までありませんでした．
・仕組みとしては簡単なもので，スライドさせる画像を横に連結させておき，transformx=translate(offset) というビルトインのプロパティを使ってその横位置を移動させるだけです（overflow=hidden にしておく）．画像ごとの移動量（offset）は簡単に計算できます．
・この仕組みを，レイアウト上の “空白多すぎ問題” が多い私的・北海道地質百選ページを改善するのに使えるのではないかと思い立ちました．しかし，この仕組みは当初単なるデモ版に過ぎなかったため，スライド画像を『１ページに１セットしか置けない』という決め打ちものでした．これでは実用にはなりません．
・この点を改善するには『各画像セットも配列にする』必要があります．各画像セット中の画像は二次元配列となります．話は複雑に見えますが，実際はそれほどでもありませんでした．
・なお地質百選ページではデモ版と異なり，キャプションや移動ボタンが画像の下にあります．移動ボタンは “画像幅の左右に別れて一行で表示” したいところです．これは当初不可能と思われましたが， CSS の機能：
display: flex;
justify-content: space-between;
．．．を親要素に適用することで実現できました．CSS の奥は深い．
・このバグはもしかするとフィックスできた『かも』しれません．
・console.log を仕掛けて捕捉し推測できたのは，“画像の高さなどのプロパティがコード実行のタイミングによって正常に取得できていないようだ” ということでした．仮にそうだとすると，取得を遅延させてやればよいはずです．
・詳しいことはスペースの関係で書けませんが，要するに画像の高さなどのプロパティを，load イベント・リスナーを使って画像などの読み込み完了後に遅延取得させるようにしました．
・修正スクリプトをアップロードしてテストしてみましたが，今のところは問題が出ていません．もともと出たり出なかったりという現象だったので，本当にフィックスできたかどうかはまだ判断できませんが．
⇒ その後２日間に渡ってバグ・フィックスのテストを行ってみましたが，どのページでも一度も問題が生じていません．仮に完全にフィックスしていなかったとしてもこの頻度であれば『許容範囲』でしょう．この件はクローズとします．
・下でフィックスしたと書いてしまったマウスホイール・ズーム機能ですが，条件によって『ズーム操作した画像の表示サイズがゼロとなり消えてしまう』という怪現象が起きています．
・この現象はローカルでの開発中には起きておらず，それをWebサイトにアップロードしたものだけ (@_@) に見られます．ブラウザの種類には関係せず，Edge, Chrome, Firefox すべてで出ています．
・現象が常に出るわけではなく，console.log をあちこちに仕掛けていますが再現条件は不明です．一度うまく動いたものはそのままずっと問題が出ません．ページの再読み込みをかけると治る場合が多いのですが，確実ではありません．
・Javascript 自作コードにおける致命的バグというわけではなく，なんらかの『動作タイミング』あるいは『変数の変化するタイミング』による nasty なものではないかと思われます．もしかすると，イベントリスナーを複数設定していることと関係しているのかもしれませんが，不明です．
・CoPilot から Javascript 内の処理と HTML 解析の前後関係ということもあると教えてもらったので script の遅延処理（defer）を入れてみましたが，やはりダメでした．
・これがフィックス・回避できるものかどうか，まったく展望は持てていません．
・2024/06 に導入した表記機能は非常に便利（・有効）なものですが，画像が中央寄せ・横幅 100 % の場合，① ズームしていくと画像とそのコンテナの大きさが泣き別れてしまう，② ズームをリセットすると再度ズームした時の初期サイズがおかしい，③ ある画像をズームしたまま他の画像をズームすると，初期表示が前にズームした画像の倍率から始まってしまう，といった問題がありました．これらの flaw は実は最初から気づいていたのですが，なんとなく放置していました．
・② の問題は簡単なもので，リセットルーチンの最後で変数を初期化するのを単に忘れていただけでした．お粗末．
scale = initialScale;
heightH[i] = initialHeightVH[i];
widthW[i] = initialWidthVW[i];
・③ の問題もややお粗末というか，『ズーム倍率の変数を画像ごとに設定していなかった』＝配列変数にしていなかった（！）．これも簡単にフィックスできました．
・しかし，① の問題は単純なものではありませんでした．詳細を述べることはスペースの関係でできませんが，要するに画像とそのコンテナの高さを意味の異なる別個のパラメータで制御していたためでした．あれこれと試行錯誤した結果，この方法をやめて画像のスケールを変更するだけにしました．コンテナの高さはそれにしたがって（ブラウザ側で）自動的に調整されるので制御の必要はありませんでした．スキルの不足した者が妙に考えすぎていたということです．よく『下手の考え休むに似たり』と言いますがそのとおりでした．
・この開発履歴も 2024/07 以降更新されていませんでしたが，そのあいだ開発をまったく行っていなかったというわけではありません．．．が，サイトの根幹はほとんど出来上がってしまい，手を入れるところはあまりなくなっているのもたしかです．
・ところが，関係している某NPO法人サイトでフォトギャラリーを構築したのをきっかけとして，自分のサイトでも立ち上げてみようと思い立ちました．法人サイトで構築したものにさらに機能・表示を加えていき，現在も開発は進行中です．
・ウェブ上のフォトギャラリーを一から造るというのはとても無理筋なので，いろいろなツールを試した結果，Web Album Generator という古いフリーウェアを使って作成したものを，CSS・Javascript で今風 HTML に改造することにしました．
・改造のポイントは大小いくつもありますが，もっとも大きなものは『表示をピクセル固定から相対サイズ可変にする』ということでした．レスポンシブ・デザインはその結果として自然についてきます．言うまでもありませんが，固定サイズの HTML, CSS を可変サイズに改造するには，HTML ソースの広範な書き換えが必要になります．HTML 数はまだ数十程度ですが，それでもギャラリーを更新するたびにその書き換えをエディタで手動編集するというのは，とても不可能に近いものがあります．ましてや，これからまだまだ増えてくるのですから．
・この問題を解決してくれたのは，有名な秀丸エディタのマクロ機能による『複数ファイルに対する複数個所の正規表現置換の自動実行』でした．これなしではとても不可能なことです．その詳細は，とてもここでは書ききれないので割愛しますが，例えばその一部は次のようなものです．
grepreplace
"(?#maxlines:999)<table>([\\s\\S]*)(\n\t<tr>\n\t\t<td colspan=[\\s\\S]*</td>\n\t</tr>)\n\t</table>",
"<table>\\2\\1</table>",
"index*.html",
regular;
・ これで魔法のようにすべての index*.html ファイルの当該部分の位置が移動するのですから，コードの世界というのは実に素晴らしい．．．
・テスト環境では問題が出なかったため見逃していたのですが，トップページのトピックスのヘッドライン行が，ブラウザの表示幅とヘッドライン行の長さによっては，スクロールボタンの動作が全然おかしなことになっていました．つまり，スクロールすべき行がスクロールできないという状況になる場合がありました．
・理由は簡単で，『ヘッドライン行をスクロールすべきかどうか判断する式』の判断基準が，行表示の最大長さではなく，ブラウザの表示幅となっていたのです．お粗末．
if (browserWidth >= headlineWidth) {}
↓
if ((browserWidth * headlineMaxWidth) >= headlineWidth) {}
・よくある，画像をマウスホイールの回転でズームイン・アウトする手法を導入しました．元コードはウェブで拾ったものですが，それを複数画像で可能にするため class 対応とし，ズームリミットを設けることができるように改造しました．
・しかし，画像の表示されるフレームサイズが固定されていると，ズームによって表示範囲が非常に狭くなり，全然よくありません．そこで，ズームに連動してフレームのサイズを変更する仕組みも導入しました．画像ごとに初期表示の大きさが違うので，それを記憶しておいてズームの最小リミットとする必要もあり，Javascript 初心者の私にはけっこう難物でした．
・ついでに，ズーム画像のダブルクリックでズーム状態をリセットするルーチンも入れておきました．
・当然のこと（？）ですが，この機能はスマホ・タブレット等のタッチディバイスでは動作しません．ピンチアウト・イン操作でも，画面全体がズームイン・アウトするだけです．なにか手がないのかと調べてはみたのですが，現在のところお手上げです．
・下で導入した画像の両方向ドラッグスクロールを『縦のみ』『横のみ』のスクロール画像にも拡張しました．
・下記サイトから借用した両方向スクロールのコードは，自分には難しすぎていまだにどんな仕組みか分かっていないのですが，このファンクションを縦のみ（Ｙ方向）と横のみ（Ｘ方向）に改造したものと，イベント・リッスンする対象クラス名を加えただけでちゃんと動作しています．罰当たり改造？！
・今まで，大きな横長・縦長画像をスクロールして表示するのに，横スクロール・縦スクロールを使用していました．今回，縦横に大きな画像をスクロールのために両方向スクロールを導入しました．それ自体は overflow:scroll を適用するだけなので開発というほどのものではありません．
・しかし縦横スクロールとなると，１方向スクロールとは違い，二つのスクロールバーをそれぞれ個別にドラッグする必要があり，しかも矢印キーが効かないので，非常に鬱陶しい点があります．
・そこでマウスドラッグで全方向にスクロールできないかとネットを漁ってみたところ， jquery を必要としないバニラなコード があったので，そのまま借用しました．非常に便利なものです．したがって，自分で開発したというわけでは全然ありませんが．
・Swiper を 10.2.0 ⇒ 11.0.7 にバージョンアップしました．
・いつの間にかメジャーバージョンアップがされていました．しかしこれも正直何が変わったのか分かりません．テストしてみたところ問題はなにも見られないので，念のためアップデートを行いました．
・これは，昨年12月にやっていた変更ですが，開発履歴に記録するのを忘れていました．2023/11 の項に『クリックで閉じない方がよい場合もあるような気がします．両方の動作を選択できる仕組みを考えてみようかと思いますが実現するかは未定』と書いたものを実現してみました．動作選択の方法はボタンをダブルにするとかいろいろ考えたのですがあまりうまくいかず，結局 “ボタンクリックの際にシフトキーを押している場合” という判定にしました．
・手法としては，①メニューをクリックしたときにメニューを閉じるかどうかという menuClose という変数をグローバルに置いておき，②ボタンクリック時にシフトキーが押されているかどうかを event.shiftKey で判定して menuClose を設定する，③メニュー項目が押されたときに呼ばれる関数内で menuClose の値により閉じるかどうかの動作を選択する．ついでに，シフトが押された時に出てくるメニューの色を変えて，どっちが出ているか分かるようにしました．（ただし event.shiftKey では右シフトキーは認識されないようです）
・で，最近になって気づいたのですが，この方法には『ブラウザ互換性』の壁があります．つまり，Edge, Chrome, Opera ではこれで良いのですが，FireFox では左シフトキーを押してクリックすると “何も起きません”．デバッグ用の console.log() をばらまいてみましたが，シフトキーやボタンクリック自体はちゃんと認識されているので，なぜ動作しないのかワケワカです．もしかすると Javascript 以前の CSS で input のチェックを判定している時点でダメなのかもしれません．多くのブラウザではシフト＋クリックは『新ウィンドウでリンクを開く』というショートカットになっていますので，それとのなんらかのバッティング？！ とりあえず自分のスキルの無さということで，どうにもならない状態です．Safari など他のブラウザではどうなのか．．．？
・この時代にいまさらアクセスカウンターでもないのですが．．．まあそれなりに役立っています．この PHP スクリプトは PHP 工房 というところで公開されているテキスト版をそのまま使っていたのですが，自分としては不満点が一つありました．それはＩＰアドレスのフィルタ機能がないという点です．作成したウェブページの確認などで自分でアクセスすると，それもカウントされてしまいます．つまり，このサイトのカウンターのおそらく半分程度は『自分』なのです．PHP に関しては経験がないので，上の作者に要望しても良いのですが，その程度のことを人に頼むのは気が引けます．ということで，自前で改造することにしました．
・“改造” といっても，単に１行を変更するだけです．
if ($remoteAddr != $reg_remoteAddr) {
↓
if (($remoteAddr != $reg_remoteAddr) && ($remoteAddr != $ignoreAddr)) {
とても改造というほどのものではありませんが，自分にとっては PHP 初体験で緊張しました．動作確認は実際のウェブサイト上でやるしかないので，テスト用ダミーフォルダを作ってそこでテストしました．
・今のところは除外アドレスは１個だけなのでこれでよいのですが，将来的にそれを増やすとなると，この方法では判定行がとんでもない長さになってしまい，すぐに行き詰ってしまいます．そこで，除外アドレスを配列に格納し，それを implode() で単一文字列に連結し，アクセスＩＰの部分一致を preg_match() で判定するというのを考え，それも問題なく動作しています．
・なお，この PHP スクリプトには，アクセス履歴を集積的に保存する機能がありません．その実装は簡単なのでしょうが自分にはまだ荷が重いです．レンタルサーバー上のアクセス解析機能というのもありますが，無駄な情報が多すぎて実態がつかめません．そこで，Windows 上の Rainmeter というスクリプトツールを使い，count.dat を定期的にモニターしてアクセスＩＰと逆引きホスト名・アクセス数などをローカルに保存しています．
・今までＰＣブラウザ表示では，select コントロールを使った『ドロップダウン』メニューでしたが，これを list コントロールを使った『ドロップメニュー』に変更しました．
・というか．．．実はこれはスマホ表示の際に切り替えて使っていたものをＰＣブラウザでも使うようにし，表示の位置や大きさを adapt しただけです．
・なぜＰＣブラウザ画面でも使うことにしたかというと，『書式設定の自由度が高い』からです．一例をあげると，select コントロールでは（驚いたことに）option 部の文字色等を自由に設定できません．背景色は設定できるのに信じられないのですが，いくらやってもそうだし，ネットで調べてもそうでした．その他にもいろいろあり，自由度の高い list コントロールに変更しました．
・この仕組みの導入理由は更新履歴ページに書きました．仕組みそのものはウェブのどこかから拾ってきたもので，特にどうということもありません．チェックボックス・コントロールとリスト要素を使ったもので，既に導入済のスマホ表示のテーマ変更ドロップダウンメニューと大差はありません．ただしそちらは『ドロップダウン』ですが，今回のは『スライドイン』であるという違いがあります．
・要するに，画面外にメニューを置いておき，隠しチェックボックスがクリックされたら transform: translateX() を使ってそれを水平に移動し画面内にスライドインする，というものです．
・開発テスト版では，ネットからコピペしてちょっと修正するだけで問題なくできましたが，いざそれを実際の地質アーティクルページの左上隅に移設すると，特に position: のあれこれで，意図通りに動くまで非常に苦労しました．自分自身がよく分かっていないのが原因ですが．
・自分的に独自に作ったのは，『ジャンプメニューに三つの階層を設ける』『クリック・ジャンプでメニューを自動的に閉じる』の二つです．前者は <li></li> と <a href=""></a> との書式指定関係に，どうもまだよく分かっていないところがあり，試行錯誤でした．
・後者は要するに <li></li> 内の <a href=""> 要素を配列にし，それぞれにクリックイベントのリスナーを設定して，イベント発生でチェックボックスのチェックを外しメニューを閉じる，というものです．しかし考えてみると，クリックで閉じない方がよい場合もあるような気がします．両方の動作を選択できる仕組みを考えてみようかと思うのですが，実現するかは未定です．
・黒歴史ページの執筆というか，CSS の開発は 2021/06 ころからはじめて，2022/02 あたりに終了しています．その開発には Blue Griffon という HTML エディタを使用しましたが，このエディタには構文チェック機能がありません（と思う）．Javascript の実行機能もなく，要するに開発環境ではなく単なる HTML エディタでした．
・Visual Studio Code に移行し HTMLHint という構文チェッカーを入れていますが，黒歴史ページをたまたま開いてみると CSS 構文エラーの嵐でした．詳細は恥なので書きませんが，自分が CSS の基本を分かっていないためのものでした（今もそうですが）．よくこれでページが表示されていたものだと感心します．HTML + CSS という仕組みは案外 tolerant なものだったのでしょうか？
・ついでに，HTML4 風の deprecated な構文も遺っていたので今風に修正しました．なお，これらの修正によるブラウザでの表示・動作の変化はまったく無く，今までと何も変わりません（やる必要なかった？！）．
・Swiper を 9.2.0 ⇒ 10.2.0 にバージョンアップしました．
・しばらく Swiper サイトを見ていなかったら，いつの間にかメジャーバージョンアップがされていて，しかもマイナーバージョンも 0.2 上がっていたということなのですが，正直何が変わったのか分かりません．サムネールの挙動がなんとなく変わったような気もしますが，気のせいかも．テストサイトでは（9.0 の時のような）大きな問題は特に見られないので，アップデートを行いました．
・スマホでトップページを表示した場合，表示テーマを変更するドロップダウンはＰＣブラウザと同じでした．で，そのドロップダウンをタップすると，巨大な別ウィンドウでしかもなぜかラジオボタンによる選択メニューが表示されていました．これはもちろん意図的にそうしているわけではなく，少なくとも Android 上の Google Chrome では，ドロップダウンはそう表示されるものということらしいです．iOS や他のブラウザでどうなのか，なにか回避設定等があるのか．．．は知りません．
・それはそれで別に構わないのですが，やはりなんとも納得できないので，ドロップダウンメニューをリスト要素を使って自前で作成しました．デザイン上の自由度は上がるのですが，ビルトインのドロップダウンでは普通に出来ていることを実装するのに，非常に苦労しました．
・これは内部的なもので，まったく表からは不可視のことですが．．．これまでは各ページで使用する自作関数ライブラリやテーマ設定のための js ファイル，さらにはそこで使用する CSS ファイルを，各ページごとにそのフォルダに置いていました．詳しいことは省略しますが，それはもちろん理由があり，そのおもなものは『ページごとにリソースに到達するための相対フォルダ指定が異なるため』でした．
・そうすると，もうお分かりと思いますが，各フォルダに似たような内容の js, css ファイルが散在し，始末に負えません．js ファイルの場合は，関数の処理を変更するたびに，すべての当該 js ファイルを更新しなくてはいけません．まったくタコな話です．
・そこで解決策ですが．．．その “相対フォルダ指定” を共通関数にパラメータで渡してやれば良い．小学生でも考え付くことですが，私はやっとその手を考え付いたわけです．
・とは言っても，大量にある HTML で現在の個別処理を一気にサイトグローバル化するのは，かなり面倒です．とりあえず，トピックスページにこの手法を導入し，あとは更新のタイミングを見ながらぼちぼちとやっていくこととしました．
・ ⇒その後，思い切って『地質アーティクル』『その他のアーティクル』ページをサイトグローバル化しました．１時間程度で終了し，思ったより簡単でした．なお，黒歴史シリーズはテーマ固定なので対象外．北上アルバム・写真ギャラリーは外部ソフト作成なのでテーマは変更できません（というか，面倒なのでやらない）．復刻版ページは，そもそも Javascript やスタイルシートなど使っていない．ということで，関数・スタイルのサイトグローバル化はこれで完了ということに．
・下に書いたように，この機能でスイッチできる画像は『一つの HTML 内で導入できるのは 10箇所まで』『一つの画像で切り替えられるのは３枚まで』でしたが．．．スクリプトのアルゴリスム（大げさ）を見直して，この二つの制限を撤廃できました．何か所でも何枚でもスイッチできるようにできました．①配列変数への格納をダイナミックにしたのと，②画像を進めるロジックをスマートにした，というか今までが超タコロジックだったわけですが．
・なお『戻る方法が無い』というのは．．．それを実現するアイデアがまったくありません．HTML の onclick= には “右クリック” を判定する方法がないみたいなので，そのへんの判定をスクリプトで入れることができなければ永久にダメかも．
・ ↑ 上の件，“shiftキー押下状態” を検出するルーチンを入れて前進・後退を行うようにしてみました．しかしなぜか，クリック初回と２回目以降で挙動が異なるという謎現象が発生．スキル・知識不足で解消方法が分からず．．．結局 VisualBasic や Rainmeter でよく使った『フラグ変数』を導入し初回と２回目以降で動作を変えるようにして回避しました．なんともスマートではないどころか “どんくさコード” ですが，なにはともあれ意図通りに動作しています．ただしいまのところ２枚切り替え以外の画像はないので，shift+click しても違いが分からない状態．そのうち３枚以上切り替え画像を入れてみたいのですが．
・これまで表示画像の内容を変化させたい場合，APNG (animation PNG) を作成してアニメション表示していました．もちろんこれは APNG 作成時にアニメ・タイミングを固定値で指定するので，視聴者が自由に切り替えるすることはできません．見ているうちに次に切り替わってしまうとか．．．腹が立ちます．
・また当然ですが，画像は可逆圧縮の PNG 形式になるので，写真とかの自然階調画像ではファイルサイズがかなり大きく（10 MB 以上とか）なってしまいます．現在は画像サイズを節約しさらに “256色パレット形式” にするとか，いろいろ工夫していますが，JPEG を使えればそれに越したことはありません．
・そこで，JavaScript を用いて，画像をクリックすると切り替わる仕組みを導入しました．仕組み自体は innerHTML を使うもので，取り立てて複雑なものではありませんが，ファンクションを共通化して一つで済ませたいため，あれこれを勉強する必要がありました．
・現在のところ，『一つの HTML 内で導入できるのは 10箇所まで』『一つの画像で切り替えられるのは３枚まで』『３枚目をクリックすると１枚目に戻るが，３枚目から２枚目に戻る方法は無い』という種々の制約があります．スキル不足です．
・なんとかリベンジでフィックスしました．詳細は書きませんが，トピックス項目のダミー文字列をはるか画面外に生成し，その幅を getComputedStyle() で取得，その値とブラウザ表示幅からスクロール方向を制御するというものです．また，ブラウザ幅が十分で文字列がすべて表示されている時はスクロールボタンを押しても何も起こらないようにしました．
・ただし，“項目文字列がすべて表示されている状態でスクロールボタンを押してしまいその後ブラウザ幅を縮めた場合” というケースだけ最初のスクロール動作がおかしいのですが，対応処理が複雑になってしまうので，普通ないレアなケースということで放置します．
・なお，項目行に ellipsis を設定すると，スクロールバーによるスクロール時にまったくおかしな挙動になってしまいます．またスクロールバーをよく見ると，表示領域が全然合っていません．おそらくスクロールバーも文字列と一緒に左にはみ出しているのだと思われますが，これでは意味がありません．理由（・回避方法）は不明ですが，スクロールバーの表示はとりあえずやめることとしました．
・トップページの地球科学トピックス項目は，右側にあふれた部分があることは『…』(ellipsis)で分かるようにしていましたが，その後ろの表示はできずクリック操作もできません．そこで，ボタンを押して項目行をスクロールできるようにしました．右端までスクロールされると今度は左に戻れるようになります．手法自体は Javascript でスクロールの方向を制御するだけで，簡単なものです．
・しかし．．．この手法は，『不定長の項目長さ』と『ブラウザの表示幅』に対応できていません．そのため，項目が増減した場合やブラウザ表示幅が推奨幅（900-950ピクセル）と異なる場合，非常にヘンなことになってしまいます．この対応についてはいろいろと探ってはいますが，スキル不足によりまだ見通しは立っていません．
・結局この動作の見通しが立たないため，あきらめて『普通の横スクロール』に変更しました．情けないのですがしょうがありません．いずれリベンジ．．．か？！
・下で『そのうち直るかどうかも分からない』と書きましたが，昨日リリースされた 9.0.5 でこの問題は解消されていました．というか，9.0.5 はそのためのフィックス版でした．
・Swiper 9 では 8 から色々と変更を受けている部分や機能追加がありますが，それらについてはこれからゆっくりと adjust していく予定です．
・それにしても，こんな明白なバグが 9.0.0 リリース時に把握されていなかったとは．．．
・“できなかった” というネガティブな話です．Swiper のバージョンが 9 に上がっており，さまざまな機能追加や変更が行われています．それではさっそくアップデートを．．．と思ったら，scrollbar で大きな不具合があります．要するに，スクロールバーの現在位置を示す部分（drag）が二重に表示され，本来の位置にある drag は以降のスライド移動に追随せず，その下に分離して表示されている drag もどきだけが追随する，というもの．
・Swiper の変更履歴や 8 ⇒ 9 移行ガイドにはこの部分に関する記述はないので，初期設定の方法が変わったということでもありません．要するに Swiper 9(.0.4) のバグと思われます．ネットを漁ってみても当該現象の報告はなく，したがって解決策もありません．そのうち直るかどうかも分かりません．しょうがないので，当面アップデートせず Swiper 8 のままで行くことに．
・印刷実行ボタンのあるページでそれをクリックすると印刷用のスタイルシートが読み込まれるので，印刷実行後には，ページを再読み込みしてレイアウトや表示テーマを元に戻す必要があります．これを，自動的に再読み込みが行われるようにしました．具体的には，ファンクションの最後に window.setTimeout('location.reload();', 2000); の１行を加えただけですが．
・具体的には，ブラウザ高さが 720 px より小さい場合，ヘッダフッタの固定表示を外すこととしました．もちろんその意図は，スマホ等で見た場合，上下に邪魔なヘッダフッタをスクロールアウトさせるためです．
・技術的には，単に @media screen and (max-height: 720px) {header {position: static;}} のようなものを加えただけで，単純なものです．
・それにしても，レスポンシブ・デザインというものは，終わりの見えないものだとつくづく思います．あっちを直せばこっちが崩れ．．．要するに定型というものが無く，試行錯誤の毎日．もちろんPCブラウザ上でスマホ画面をシミュレートできるわけですが，結局は修正したらスマホでキャッシュを削除して確認してということになります．それも自分のスキルの無さということなのですが．
・これは正確にはなんと呼ぶべきか分からないのですが．．．重なった二つの写真の境界線上のつまみをスライドすると，二つの写真が広がったり狭まったりというアレです．jQuery を使いたくないので，スタンドアローンで動作するものを探していたら，BeerSlider というライブラリが見つかりました．2018年のものでそんなに新しいものではなく，既に開発も終わっているようですが，問題なく動作します．オプションは少なく実質的に『スライダの初期位置』だけです．
・いまのところ導入したのは，エッセイその他のデジタル写真技術のページだけですが，他にも使えそうなページはありそうなので，随時拡大していきたいと思います．
・バグや不具合ということではありませんが，ちょっと気付いたので．．．本サイトをブラウザで印刷しようとすると，なぜか『見えている部分だけ１ページ』しか印刷できません．いろいろやってみた結果．．．ヘッダとフッタを固定しページ本体をその間に表示するために position:fixed を指定していることが原因でした．この指定を外すと，すべてのページが印刷できるようになります．Edge・Chrome・Firefox すべて同様なので，ブラウザ依存の問題ではなく仕様ということでしょう．以前はそういうことはなくヘッダとフッタに挟まれたすべてのページが印刷できた，と思うのですが．．．記憶違いかもしれません．
・いずれにせよ，閲覧者側ではどうにもならないことです．印刷用の CSS を用意して切り替える，といった手は考えられますが．．．このサイトを印刷したいなどという閲覧者はいないだろうということで，このまま放置か？
・このまま放置か．．．と書きましたが，現在作成中のページで印刷用の CSS を用意して切り替える機能を用意することにしました．サイト全体に波及させるかどうかは決めていません．なお，この過程で Microsoft Edge の印刷ルーティンに『CSS の clear:both に対応していない』というバグがあることに気づきました．そのため印刷では，その部分でレイアウトが大きく崩れてしまいます．Chrome, Firefox では問題なく clear されるので，まったくしょーもない．公開する際には excuse が必要でしょう．
・下に書いた nasty なバグを解消しました．やはり 私自身のせい でした．詳細は省略しますが，空行を表示・非表示にする部分の for ループの終わり値が誤っていた（！）ためでした．情けないのですが，バグというのはそんなものです（開き直り）．
・これははっきり言って，『追加した』ではなく『追加しようとしている』という現在進行形です．つまり，バグがありそれを解決できていません．
・“スライド・コントロール” というのは自分の勝手な造語で，正確には Swiper の Pagination と Scrollbar です．これらは Swiper の組み込み機能で，その表示処理部分は Swiper の内部の深い部分にあり，少なくとも初心者にはまったく手が出せません．
・“スライド・コントロール” を表示・非表示にすること自体は，当該エレメントに display: 'block' と 'none' を設定するだけでまったく簡単です．ところが，Swiper のスライド・コントロールはスライド下部に重なって表示されるもので，スライドが画像だけだったら，それで済みます．しかし，本サイトのスライドは画像の下に説明文があります．Swiper は文章も画像も区別せず，それを合わせて要するに１枚のスライドなのです．そうすると，説明文の上（？）にスライド・コントロールが重なってしまい，はなはだ具合が悪いことになります．
・本サイトでは，この問題を “ある方法”（あえてその詳細は省略する）で回避しています．これがまた姑息なもので，それがバグの遠因です．つまり，表示・非表示を設定すると，文字の上に重なり合わないようになっているはずのスライド・コントロールが，な・ぜ・か・！．．．重なってしまうのです．逆に不要な空白部が残存する場合もあります．それらの現象がなぜ起きるのかは，私にはまだ分かりませんが，Swiper 内部の Pagination, Scrollbar の表示モジュールにおける処理と何らかの関係があるのではないか？というのが現在の私の 妄想 です．つまり，未熟なのに “私のせいではない” と言いたいのです．
・手法自体は，他のところで使っているのものの応用なので，特に新しいことはありません．しかし．．．Swiper エレメントの構成の問題があり，キャプションのスタイルだけを表示・非表示とするのは意外に難題でした．要するに，そのエレメントは一意な id= ではなく，多数（＝スライドの数だけ）存在する class= なのです．もちろん，実際に表示されているのはそのうちの一つなのですが．
・結局その解は，取得した class オブジェクト配列要素のスタイルを，for ループを用いてすべて変更するという荒業（？）でした．Javascript 中～上級者なら簡単な話なのでしょうが，初心者にとっては．．．まあしかし，ちゃんと実現しました．
・これも外からの見かけはとしては，なにも変わりません．見えていないのですから．しかし，スライドショー非表示時にも “複雑な ” Swiper + 自作スクリプトが意味もなく動いたままというのは，パフォーマンスに与える影響もそうですが，なにより『サイト構築者・スクリプト開発者として許し難い』ためです．
・Swiper を無効・有効にする機能は，Swiper 自身に内部メソッドとして用意されているのですが，Swiper の収まっている child iframe 側にあるメソッドを，外側（parent）から操作する方法を見つけるのに少しだけ手間取りました．
・見かけはほとんど変わりませんが，スライドショーの内部構成を大幅に変更しました．詳細は省略しますが，今まで index.html の中と，iframe の中で開かれる slideshow.html の中とに散在していたスライドショー関係の設定部分を，すべて slideshow.html に移動しました．これで，ぐちゃぐちゃだった制御関係を合理的に整理できた．．．はず．
・そのため，数多くの CSS, javascript ファイルの構成・中身を大幅に変更・整理する羽目となり，かなりの大手術となりました．その結果，ちょっと不審な点も残っていますが，大筋は問題なく動いているようです．問題点は徐々に解決していく予定．
・またもやバグ．．．この機能というか設定は本来，レスポンシブ・デザインということで，CSS の中に @media screen and (max-width:420px) {} として記述されていて問題なく動いていたものですが．．．下に書いた Javascript でスライドショーの表示を on/off する機能と完璧にバッティングしていました．要するに，CSS でせっかく off にされた表示が，その後の Javascript で再表示されていたということです．
・CSS の読み込みをディレイさせるとかいろいろ考えましたが，どうもうまくないので，結局 Javascript そのものの中にブラウザ解像度によって表示を on/off するようにして解決しました．
・またもやバグ発生です．ページ読み込み時に，表示されるスライドに対してサムネールが一つ前にずれてしまいます．スライドが切り替わると正常に戻ります．いつからこうなったのかは不明です．スライド遷移効果を設定可能にしたあたりからと思うのですが．．．Swiper ライブラリのバージョンを上げたりいろいろやっているので，正確なところは分かりません．
・バグの原因ですが，情けないことに今のところ皆目分かりません．直感的には loop モードあたりかなとは思っているのですが，バグの発生状況になにやら inconsistent なところもあり，単純なものではなさそうな感じがします．ということで，対処もできない状態ということです．
・しかし．．．上に書いた直感を信じて loop: false, にしてみると，サムネールのずれが無くなりました．原因は分からないのですが，とりあえず loop モードを切り，スライド切り替えルーチンを最適化しました．
・その後いろいろデバッグしてみた結果，この現象は自分のスクリプトのバグではなく，『 iframe 内で loop:true モードの Swiper を動かしたときの thumbs API における Swiper のバグ』としか考えられません．あくまでも今のところの見方ですが．で，デバッグの過程で得られた回避方法は『サムネールを loop: true に，スライド本体を loop: false にする』ということでした．なぜそれで回避できるかは不明です．
・方法自体は，あちこちで使っている手法の援用なので，特記すべきものはありません．
・ただし，表示を off と言っても，単に表示を消しているだけで，Swiper そのものを終了させているわけではなく，バックグラウンドでそのまま動いています．この程度ではブラウザ（・パソコン）のパフォーマンスに影響することはないとは思いますが，いずれはきっちりと停止させ再開するというようにしたいです．Swiper には，ちゃんと swiper.disable(), swiper.enable() というメソッドが用意されているわけだし．しかし．．．なにしろこの自作システムは Swiper だけを停止・再開させるだけでは済みませんので，かなり面倒な予感がします．
・あくまでも内部的なものですが．．．ページ読み込み時に if 分岐を使って Swiper の切り替わり効果を設定しているわけですが，どういうわけか if 節の中に new Swiper () そのものを置くと，オブジェクト生成でちょっとした問題が起きます．また，同じような new Swiper () を二つ書くというのもスマートではないので，それを if 分岐の外に追い出し，if 節の中ではその効果設定部分の変数を代入するだけにしました．ソースを示さないと何のことだかさっぱり分かりませんが．．．興味ある人は Developer Tool とかで見ることができるでしょう（見ないで欲しいのですが）．
・切り替わり効果は Swiper 自体に備わっているものなので，そういった処理を自分で作成して加えたというわけではありません．ただし，二つの効果を選択し保存可能とする自前の処理を加えました．その方法は，これまであちこちで使っているものの使いまわしですが．．．Swiper には，効果をダイナミックに変更するという機能は用意されていませんので，設定を行うと『ページ・リロード』となってしまい，スライドショーはリセットされます．いまいちスマートではありませんが，しょうがない．
・なお Swiper には，今回設定した２種類（スライド・フェード）以外にも様々な効果が備わっていますが，このページのスライドショーとして使えるのは，この２種類だけと思われます．
・今まではスライド画像自体にこの機能を割り振っていましたが，どうもスマートではありません．そこで，専用ボタンを設置して切り替える仕組みにしました．
・それ自体は，既にあちこちで使っている手法の流用なので簡単．．．と思ったのですが，画像の相対パス指定と Javascript からの CSS プロパティ設定の罠に引っ掛かってしまい，少し手間取りました．
・これは一体いつから入ったバグか分からないのですが．．．スライドショーで『デフォルト・シーケンシャル』のモードを選択すると，スライド切り替えが完璧にバグっていました．要するにカウンターが２回分回らないと切り替えが実行されない．．．まったくとんでもないバグです．自分は普段ランダムモードしか使わないので，気づきませんでした．
・で，このバグの真の原因がまだ把握できません．おそらく，１）loop モードの“実際の” スライド番号が HTML の当該セクションから導かれたスライド番号と合っていないのと，２）スライド切り替えカウントルーチンとイベント感知ルーチンとの競合が原因と思われますが，事態は非常に複雑で，console.log() をあちこちに仕掛けて探っているが正直まだよく分かりません．つまり，完全にバグが解消したわけではありません．現時点では，『よく分からんがこうすると，とりあえずうまく動く』という状態です．なんとも情けないのですがこれが現実．
・その後，サムネール表示と loop モードの問題に関連してスライドの index やその移動についての部分を最適化し，このバグは解消された．．．と思います，多分．
・Swiper の CSS, js ライブラリを 8.3.0 → 8.4.4 にアップデート．Swiper の履歴を見ても特に自分に関係のある改善・変更はないようですが，一応ということで．
・当然ですが，スライドショーの全機能は問題なく動作している（ようです）．
・白状すると，Swiper 導入直後は，いろいろなカスタマイズを，これらの Swiper ライブラリに対して加えていた．もちろんコメントを付記しての上ですが．．．これをやると，ライブラリのバージョンが上がった時，その中に自分が行った変更箇所を組み入れるのが非常に困難になってしまいます．途中でそれに気づいて，変更やカスタマイズはすべて Swiper 本体から分離して別 CSS, js で行うこととしました．これで，ダウンロードしたライブラリで手元のそれを上書きするだけで済むようになりました．．．なんとも初心者のやることであると嘆息します．
・ここで，“ん？！ライブラリをアップデートって？”と思った方もいるでしょう．知っている人は知っていますが，Swiper には三種類のインストール方法があり，『NPM を使って import する』『外部サイトから読み込む』『ライブラリをダウンロードして自分のサイトに置き読み込む』というものです．私は “full assets (*-bundle)” をダウンロードして三番目の方法を使っています．２番目ならアップデートとか気にしなくてもよいのにとも思うのですが，ライブラリをネットをまたいで読み込むというのがどうも馴染めません．アタマが古いのでしょう．
・この機能は，Swiper に用意されている Thumbs API を使っただけで，特段難しいことありませんでした．アクティブなサムネールのスタイルを設定するのに，その class 表記にちょっと手間取りましたが．
・しかし，このトップページのスライドショーは iframe 中の別 HTML になっているので，スタイルをアジャストするには，かなり多岐にわたる編集が必要でした．ちょっとまだ不審な点がありますが，とりあえず問題なく動作しているようです．
・ついでに，サムネールの表示を on/off する機能もインプリメント．その表示状態も localStorage に保存し，設定が保持されるようにしました．これらの方法は，既に他の場所で使っているものを利用するだけなので，比較的簡単でした．
・下に書いたように，これまでは CSS で label + input を使ってメニュー開閉を行っていましたが，どうも CSS 記述が冗長でした．また :checked や + や ~ で動作を制御するというのが，ambiguous でどうも私には馴染めません．Javascript で記述すれば，そのコード記述で処理構造も明瞭に見えることになるわけで．
・実際にやってみると，ポップアップよりもかなり複雑でした．一つは CSS と Javascript 間のプロパティ表記の差異です．例えば max-height のようなハイフンを含む CSS プロパティは Javascript ではエラーとなります．じゃどうすんの？！と言いたくなりますが，ちゃんと回避方法が二つ用意されています．しかしどちらも，そんなことしていいのか？と思いたくなるような代物でした．．．もう一つは，ある div の中の特定のタグ要素を選択して変更するにはどうすればよいか．．．結局，それらを document.querySelectorAll() でオブジェクト配列に入れて，forEach を使うことでしたが，Javascript 初心者にはかなり敷居の高い話でした．
・こうして苦労して実現した Javascript 化でしたが，動作は前と何も変わらず見た目は同じです．はぁ？ じゃなんのために？！ 下には『Javascript化の恩恵』などと書いてあるが．．．？ まあいいか．transition はちょっと変わってしまっていますが，これは原因というか，前と完全に同じにする方法をまだ見つけていません．
・なおこの変更はトップページだけで，黒歴史シリーズや北上アルバムの目次ページでは従来の CSS + label 方式のままです．変更が面倒だからではなく，記念と動作比較のために残しました．
・下に，CSS で label + input を使ったポップアップの仕組みを導入したと書きましたが，これでは（今は一つしかありませんが）ポップアップごとに同じような（名前だけ違う）CSS 項目を並べなくてはならず，どうもスマートではありません．そこでちょっと考えて，label + input を使わずに，Javascript でポップアップを表示するように変更しました．これだと，ポップアップのエレメント名をパラメータで関数に渡せるので，処理部分は一つで済みます．
・同じような label + input で実現している “アコーディオンメニュー” も，いずれ Javascript 化することをトライしてみたいです．こちらはたくさんの当該 CSS 部分があるので，Javascript 化の恩恵が大きいはず．
・某隠しページに遷移する部分に，私としてはこのサイトで初めての『ポップアップ』の仕組みを導入してみました．仕組みとしては CSS で label + input，それに選択肢に button を使ったもので，動作分岐には Javascript を使いました．ぜんぜん複雑なものではありませんが．
・これらのページでは，今まで本文（#whole）の表示位置をフィックスしていなかった．そのため，ヘッダ・フッタを含めたページ全体に縦スクロールバーが出てしまっていました（と思う）．これを地質アーティクルのページと同じように position:fixed; とし，縦スクロールバーの表示を本文に限定させ，下に書いたスクロールバーのカスタマイズを施しました．
・今まで，トップページや地質アーティクルのページでは，縦スクロールバーを意図的に消していました．その方がすっきりするからねということでしたが，更新履歴とか縦方向に長いページの場合，ページのどこらへんにいるのか？ページの最後までどのくらいあるのか？が分からないので，ちょっと不安でした．また当然，スクロールバーがないのでスクロールはマウスのホイールを回すか↓↑キーを押す必要があり，一気にスクロールしたい場合など不便でした．
・標準のスクロールバーでは面白くないので，少しばかしカスタマイズしてあります．また表示テーマ変更に従って，バーの背景とつまみ色を反転しています．なお，このカスタマイズは Edge, Chrome 対応であって，Firefox では無効です．
・スマホ等ではスクロールバーは不要ということで，今までどおり消しています．
・内部的なものなので見かけ・動作はまったく変わりません．ただし，オプション文字列形式を変更したので，初回アクセス時には “設定消去” を行う必要がありますが．
・何を変更したかというと．．．今までインタフェースの切り替えには（テーマ変更と同じく）それぞれ対応する CSS ファイルを用意しておいて，それを切り替えていました．変更するスタイルはたった１カ所だけなので，単に当該エレメントの style プロパティを変更すればよいのであって，まったく無駄なやり方でした．Javascript 初心者なので，まあしょうがない．
・実際に変更を行ってみると，Javascript にとどまらず CSS や HTML に及ぶ広範な変更となってしまい，おまけに色々と予期せぬ問題が発生し，なかなかフィックスせず焦りました．なんで，script タグを置く場所によって（エラーではなく）動いたり動かなかったりするのか．．．？！ 初心者なので．
・Youtube で HTML+CSS の in-place 編集 Tips ビデオを見て，このエディター環境の存在を知りました．『あのかっこいいコードエディタはいったいなんだぁ？！』と．Microsoft 純正（？）の単なる汎用コードエディタですが，同じく Microsoft 製のエクステンションで，準WYSIWYG HTML エディタとなります．
・BlueGriffon は使い続けるつもりではあるのですが，アップデートが３年近くなく，デッドな感じが重苦しいです．WYSIWYG で編集ができるのは素晴らしく，エレメントの構造が分かりやすいのもいいのですが，所詮それだけのようにも思えます．Javascript に非対応で，フォームコントロールも表示だけで実際に動かないのも，今となっては力不足のような．日本語 word wrap がおかしい上にレスポンスの異様に遅い内蔵エディタのタコさ加減と，余計な自動インデントやタグ自動挿入も鬱陶しい．．．って書いてくると，良いところがなにも無いように聞こえますが，もちろんそうではありません．
・．．．と書いてはみたのだが，その後 BlueGriffon を使う場面は二度と来ませんでした．Visual Studio Code + Live Preview は，変更を反映させるとプレビューがページの最初に戻ってしまうのが困りものなのですが，これは Edge も Chrome も同じなので（Firefox はそうならない），Chromium ブラウザベースである以上しょうがないのでしょう．それ以外は，コードエディタとしてちょっと格が違うというか．．．結局 BlueGriffon はアンインストールしました（2023/01）．
・ヘッダ文字がはみ出たり，折り返しでヘッダ高さが変わらないようにしました．
・スマホ等で表示幅が狭くなると，なぜかページ表示が右へはみ出ていました．％指定による誤差なのかもしれませんが，正確な理由はいまのところ不明．とりあえず body 幅を微調整してはみ出ないようにしました．
・スライドショーとサイト内検索を，スマホ等では不要なものとして非表示にしました．
・メニュー行の間隔を空けてタップしやすいようにしました．
・Edge の Device Emulation 機能を使って確認しながら CSS を作り込んでいるわけですが，まだまだ不十分な状態であり，場所によっては適切な方法がどうやっても見つからない場合もあります．どうにもならず HTML レベルから作り直さざるを得ないことも．レスポンシブ・デザインとは，（初心者にとっては）手探り・試行錯誤であると痛感します．
・しかし，実際に自分の Android スマホでテストしてみた限りでは，多少不細工ではあるが特に大きな問題は出ていません．所詮自分のスキルでは完璧は望むべくもないので，あまりこだわらず，この程度でとりあえずよしとし，ぼちぼちとやっていきたいと思います．
・この再デザインは，下に書いたレスポンシブ・デザインの準備段階の一つです．これでやっとレスポンシブ・デザインを進めることができるようになりました．
・地質アーティクルには，学術論文・雑誌と同じように，『テキスト回り込み画像』と『その下に付随するキャプション・テキスト』が必須です．しかし，地質アーティクルを書き始めた 2019 年当時には，自分にその CSS スキルが無く，画像はすべて中央寄せの回り込みなしでした．その後 CSS スキルを向上させ回り込み手法を身に付けましたが，それは固定表示幅で，別エレメント内のキャプションの位置と幅を calc を使って計算するという回りくどい？ものでした．これではレスポンシブになりません．
・そこで今回，回り込み手法を根本的に見直し，図とキャプションを同一エレメント内に置き，その表示幅を相対指定に変更しました．
・長年の懸案だった『スマホ対応』にやっと着手．ただしその道のりはまだ始まったばかりで極めて限定的です．とりあえず，スマホでの表示で ①テキストサイズを縮小・②アクセスカウンターを非表示，の２点のみから始めました．ブレークポイントは，これもとりあえずですがスマホ用に width:420px のみとします．タブレットは，いろいろテストしてみた限りではＰＣブラウザとほぼ同じ表示となり問題なさそうなので，当面対応しません．
・適用範囲はトップページと “地質アーティクル” だけです．それ以外のページは，その構造上適用が非常に困難で，今のところ対応予定はありません（というか，できません）．
・レスポンシブ・デザインを導入する理由になったのは，もちろん『スマホでも見やすいように』というのが第一の理由ですが，これを導入しないと Google Search で『優遇されない』どころか『 Issue として扱われてしまいインデックスされない』というのも大きいです．なんだか納得できないのですが，これも時代か．
・トップページだけだった表示テーマ設定機能の範囲を拡大しました．
・なお，地質屋 “黒歴史” シリーズは『黒歴史固定テーマ』とします．北上写真アルバムについてはその構造上，テーマ変更は非常に困難です．地質ブログおよび MAK_KAWA のページは，そもそもスタイルシートを使っていない化石ページなので（一から書き直さない限り）対応できません．これらについては対応の予定はありません．
・このサイト全体を，某法人サーバーから個人契約のレンタルサーバへ移設しました．そうしなければならなかったという理由は特にないのですが．．．某法人サーバにせっかく用意した個人サイトが自分一人だけという現実に我慢ならなかったから，というのが第一です．あと，自分のレンタルサーバならあれこれ制限無く好き勝手にできます．
・しかし最大の要因は，レンタルサーバーで個人サイトを開設する費用がこんなに安いとは知らなかった！！ということに尽きるでしょう．これが年間２万とか３万だったら，某法人サーバにいつまでもお世話になっていたでしょう．
・このサーバー移行でテクニカルに変更しなければいけなかった部分はほとんどありません．唯一，スライドショーの iframe 関係でイベントのクロスオリジンを設定していた部分は変更が必要でしたが．
・頑固な固定幅ページからやっと脱却したと言いたいところですが，“黒歴史” ページで多用している回り込みテキストを設定した画像＋キャプションの場合，CSS での表示位置計算に大きな問題があり，今のところ可変幅の適用ページは限定的となっています．そのうちなんとかしたいと思っています．
・サイトの表示や機能には何の関係もないことですが．．．トップページに導入したスライドショーのソースは，index.html にそのまま埋め込まれていました．その場合，スライドショーのコンテンツを追加・変更するたびに，トップページ自体を編集する結果となり，そのソースもずらずらと長くなってしまい鬱陶しいです．そこで，スライドショーを別 HTML ファイルとし，iframe タグを使ってトップページに埋め込む形式としました．
・この場合，以下のような大きな問題が発生します．① トップページの表示テーマを変更してもスライド（の背景）には反映されない．② スライドによって表示領域の高さが変わるが，iframe 部分の高さは一定となってしまう．そのため，スライドの下が切れてしまったり，余白ができたりする．．．まったくよろしくありません．
・これらを解決するために，Javascript の “クロスサイトメッセージング” によって，親ウィンドウと子ウィンドウ間で情報のやり取りをおこない，それをトリガーとして互いに必要な動作を行うシステムを開発しました．同一のサイト内なのにフルＵＲＬ記述のクロスサイトとはいささか大げさです．サイト内（・ウィンドウ間）でメッセージングする仕組みはあるようなのですが，まだ追求していません．動いてるから，まあいっか．．．ということで．
・某法人サイトのトップページのために開発した機能ですが，そちらでは評判が悪かった（というかその fun がそもそも理解されなかった）ので，あっさりと削除し，自分の個人ページに導入しました．
・なおこの機能は，もちろんスタイルシートの切り替えによるものですが，それを実現するために Javascript を使い，設定状態保存のために HTML5 の（？）LocalStorage を利用しています．
・ウェブ上のスライドショーを『jQuery ライブラリを必要とせず CSS，Javascript のみ』で構築する仕組みとして有名な Swiper を使ったもの．導入後，自作 Javascript コードを使って大幅にカスタマイズしました．
・“カスタマイズ” と書きましたが，実は Swiper の自動切り替えという主要な機能はオフにしてあり，切り替えやそのモード・インターバルなどはすべて自作 Javascript コードから Swiper のメソッドを呼ぶことによって実現しています．Javascript を書くのは，自分としては初めてのことでした．いまだにその記法には慣れていませんが．
・Swiper に独自 Javascript でかぶせた機能は以下の通り．
① スライド切り替えの残り秒数タイマー表示を設置．
② スライド切り替えの間隔設定機能．
③ 三つのスライド切り替えモード設定．
④ 切り替えモードがランダムの場合，ランダムな次スライドに飛ぶ機能．
⑤ 現在の表示スライド番号とスライド総数インジケーターを設置．
⑥ スライド上にマウスをホバーするとスライド切り替えカウンターが一時停止する機能．
・それ以外に，Pagination のバレットや next-previous ボタンなどを CSS 上でカスタマイズしています．
・CSS に関するさらなるスキルアップを志し，とりあえずメニュー項目を折り畳んだり開いたりする仕組みを導入しました．あまりたいした意味はないのですが．
・このころには，現在のサイトの原型が多分固まっていたと思われます．CSS を使ったヘッダ・フッタの固定やスクロールバーの消去など．しかし，なぜか開発履歴がまったく残っておらず，その正確なところは不明です．
・これは，ある意味自分にとっては大きな一歩でした．現役時代，いくつかのホームページを勤務先のサーバー上で作成管理してきましたが，それらはすべて『HTMLのみ』のレガシーな（と言えば聞こえは良いのですが要するに obsolete な）ものでした．つまり，この個人ページは，自分としては初めての，スタイルシートを使った up-to-date な（？）構造を持つホームページとなりました．
・当初は，所属法人のHPからリンクされた単なる個人紹介ページであって，特に内容もデザインも気持ちの入ったものではありませんでした．CSS は使っておらず，たまに style タグを使ってインライン・スタイルを設定していた程度でした．