このウェブサイトは，HTML + CSS + Javascript という，（もうすぐ後期高齢者の私にとっては）今風と思われる構成を持っています．というか，いまやそれが必須というか当たり前なわけで．そういうサイトを構築することになるとは，“アカデミックスタイル” の HTML ページを書いていた現役時代にはまったく考えもしませんでした．2021年6月から開始されたその開発の履歴を，以下に残しておきたいと思います．
・テスト環境では問題が出なかったため見逃していたのだが，トップページのトピックスのヘッドライン行が，ブラウザの表示幅とヘッドライン行の長さによっては，スクロールボタンの動作がおかしなことになっていた．つまり，スクロールすべき行がスクロールできないという状況になる場合があった．
・理由は簡単で，『ヘッドライン行をスクロールすべきかどうか判断する式』の判断基準が，行表示の最大長さではなく，ブラウザの表示幅となっていた．お粗末．
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 プロパティ設定の罠にj引っ掛かってしまい，少し手間取った．
・これは一体いつから入ったバグか分からないのだが．．．スライドショーで『デフォルト・シーケンシャル』のモードを選択すると，スライド切り替えが完璧にバグっていた．要するにカウンターが２回分回らないと切り替えが実行されない．．．まったくとんでもないバグである．自分は普段ランダムモードしか使わないので，気づかなかった．
・で，このバグの真の原因がまだ把握できない．おそらく，１）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 のページは，そもそもスタイルシートを使っていない化石ページなので（一から書き直さない限り）対応できない．これらについては対応の予定はない．
・頑固な固定幅ページからやっと脱却したと言いたいところであるが，“黒歴史”ページで多用している回り込みテキストを設定した画像＋キャプションの場合，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 タグを使ってインライン・スタイルを設定していた程度である．