超現実的異世界「月本國」を創造するぶろぐ

　テキスト関連の呪文で他に多用するのは、中央に配置するcenter、色を変えるcolor、太字にするboldだろう。centerとfontは廃止されたのでcssでやるしかない。bタグは今も有効だが、使うならば単独で用いる場合に限った方がよい。他に複数の術式を並べる必要があるならば、多重に囲むよりもcssでクラスをまとめて唱えた方が分かりやすい。
　ところで今更ながら、現代のhtmlは最低限cssができてナンボである。昔は多くの人が、100%タグ打ちで個人サイトを運営していたものだった。既にリンク集のページはレスポンシブ工事が完了しているが、当然ながらその際に一つ一つリンクをチェックしたのであった。既に閉鎖されたサイトや移転したかもしれないサイトは、音信不通なので削除するしかあるまい。長年更新されずに放置されているサイトは広告が虚しく目立っていたが、ガチでタグ打ちのみというのが目に見えて分かるものであった。
　こうしたサイトは、まだまだネット上に星の数ほど散らばっている。今後も放置され続ければ、サーバーの運営上の都合で、いつかは消えるかもしれない。だが、cssやレスポンシブに対してハードルが高いように思えて、更新を投げ出してしまったサイトも多数あるのではないか!?ここでダラダラ書いているように、最低限のことをやるならば決して難しいことではない。過去に有力な情報を提供していたサイトが数多く埋もれてしまっているのは、何だかもったいない気がするのである。

　テキスト文は自動的に改行されるので、それがメインのページならば、結界を張るだけで最低限のレスポンシブは実現する。だがビジュアル的にレイアウトが乱れまくりだし、テキストのサイズもまとまりが無くて、あまりにも強引過ぎる。それらが解決できれば、現在議論中のtableのあるページにも応用できるだろう。
　まずは文字の大きさである。どんなブラウザでも共通のようだが、デフォルトサイズだと通常の見出しぐらいの大きさなので、スマホでは大き過ぎる。PCでは読みやすさからすればちょうどよいかもしれないが、レイアウトを組む上ではやはり大き過ぎる。
　いずれにせよ、一回り小さくしないと扱いにくい。タグのみで制御していた昔の個人サイトでは、誰もがfontタグでコントロールしていただろう。だがそれが廃止された現在、フォントサイズを調整する方法はcssを使うしかない。これは昔に比べると面倒になったということか? 主観的にはそうとも言えない。他の呪文と混ぜて唱えるとなれば、むしろ合理的で扱いやすくなったという印象である。
　では今の時代において、フォントサイズを控え目に設定するにはどうすればよいか? cssでタグに対して、font-size:80%程度の呪文をクラスで渡せば合理的に解決する。クラス名は何でもよいが、これは多用するので簡単なのがよいだろう。従来はテキスト文を細かくfontで囲って面倒なことをしていたものだが、極端な話、レスポンシブで唱えた外側の結界に対してこいつを唱えるだけで、結界の内部全体に有効なわけである。だけどレイアウトを考えれば、そこまで大雑把にする必要も無いか…。

　さて、これはあくまで「手っ取り早く」というのがテーマであり、外観が最重要視されるプロの仕事レベルの話ではない。結局のところ、レスポンシブ化を手っ取り早く進めるカギは、横幅を320px程度まで縮めても、中身をはみ出さないようにすることである。そのために最も手っ取り早く済ませるには、ページの外側に大きな結界を張り巡らせて、その幅をディスプレーに応じて制御すればよい。
　html5以降では、ページ内のブロックの位置付けを明確にすべく、header・main・footerというタグが存在する。単純にページ内で頭・胴体・足に相当する部分を明確にすべく用いられるわけで、1ページ内にそれぞれ1個ずつしか唱えられない。それに対してdivは昔からあって、今も多用されるタグだが、これは1ページ内で何度も唱えられる。良い意味で融通が利くが、悪い意味でページ内の構造が理解しづらくなる。
　では外側に結界を張る呪文は何を唱えるべきか? 単純に動けばいいというのであれば、万能型のdivで問題無い。だが、時代の流れに則するならば、セオリー通りに頭から足まで、きちんと役割ごとに分担して唱えるべきであろう。
　いずれにせよ、レスポンシブにするためには、これらの結界に対してメディアクエリでブレイクポイントを設定して、その値に応じてクラスで受け渡せばよい。横幅に制約のあるスマホは全開といきたいところだが、縦スクロールバーとかち合わないように96%ほどに抑えるのがよいだろう。PCは横幅を広く活用できるものの、広げ過ぎると外観がもっさりするし、ノートパソコンの需要も考えれば、1000px程度に抑えておくか…。後は常に真ん中に配置されるように、margin:0 autoを唱えておけば、とりあえず最低限の外面はどうにかなる。かくして、どんな横幅にも対応できる簡素なレスポンシブの完成である。

　月本國のレガシーコンテンツの中では、tableタグが結構多用されていた。これらを全部フレックスボックスに変えるのは非常に面倒である。プレビューする限りでは、表計算ソフトのセルぐらいの小さなブロックによる表組であれば、スマホ画面でも問題無く閲覧できそうである。てなわけで、レイアウトとして用いるのは非現実的ながら、本来の表組として使うならば継続使用はできそうである。
　外観はそのままだと昔のタグ打ち時代の野暮ったい印象は強いが、構造はしっかりしているので問題無い。かつてはブロックの内側にfontタグを用いてちまちまと文字サイズを調整していたが、tableやtrタグにスタイルを唱えれば、範囲内はすべて有効になるらしい。これでタグもかなりスッキリしたのであった。
　ところで、tableの継続使用を決定付けたのは、月本國設定資料の都道府県一覧であった。こいつを全部書き直すのはあまりにもダル過ぎる。だけど横方向のcolspanの数を維持するのは、スマホ画面では無理があり過ぎではないか!?そこは漢字と読みをまとめて減らしてから、改行を増やしたりフォントサイズを小さくしたりして、最後は強引に収めたのであった。何だかんだでtableの横幅自動伸縮機能は、レスポンシブの時代でも融通が利いて便利である。

　実は月本國のリニューアルよりもずっと前に、標識の方はレスポンシブの大半は済んでいた。そちらも開設当初はtableを多用していたが、リニューアルした時点で使いづらくなって撤廃して、レスポンシブの基礎は自然に組まれていた。
　ところで、今ではレスポンシブに応じた表やレイアウトを組むならば、tableに代わってフレックスボックスにするのが現実的である。それは縦横無尽にブロックを並べるのに柔軟に対応できるからに他ならない。
　とはいえ、単純に縦方向だけにブロックを羅列するならば、フレックスボックスを導入する必要も無い。外側にdivを唱えて大きく結界を張って、その内側にwidth100%のdivを羅列するだけでよい。これは最低限の呪文ではあるが、縦方向のブロックの羅列はこれだけで基礎は完成するのである。
　この方法は、標識サイトの詳細やリンクで、ずっと前からやっていたことであった。かくして、月本國のリンク集にも流用することで、すぐにレイアウトは仕上がったのであった。

　引き続いてリンク集を更新。こちらのレイアウトは長い間tableを唱えて組んでいた。この呪文は、かつては表組やレイアウトの構成で多用されてきたが、今でもこの廃止されることなく、一応タグ自体は有効である。
　だが、レスポンシブの時代においては、tableの使いどころが無い。こいつは基本的にtrタグの中に子要素のtdタグを複数並べて、横方向へ複数のブロックを生成するために用いるものである。だが横幅の狭いスマホでは、そんなことをするわけにいかない。幅が詰まり過ぎて、レイアウトが乱れてテキストが縦書きになってしまうオチである。
　レスポンシブを考えると、スマホに対して横方向へブロックは並べられない。単純に縦方向へブロックを羅列するしか選択の余地が無いのである。もはや本来の表組としての機能を果たせない。
　tableには、外枠がスクリーンの幅の伸縮に柔軟に対応する、唯一とも言える長所はある。だが、そもそもブロック内部のタグに対して地味に制約が多くて、案外融通が利かない。よって、わざわざ縦方向のブロックの羅列をtableでやる必要すら無い。完全にお役御免といったところか…。

　ブログの前身で、開国から1171回続いた旧：月本国政府広報の過去ログが更新された。今までは3ヶ月単位で季節ごとに分割していたが、すべて1ページに1171回分の記事を延々と羅列する構造になった。横方向はレスポンシブでスクロール不要になったが、縦方向が異常に長くなったので、ページ内リンクを付けて途中や最後で巻き戻すことも可能にした。そして共通のナビゲーションメニューも取り付けた。
　従来は昔の毎日更新の順序に従って昇順に並んでいたが、それをすべて降順に並べ替えて、1～1171までナンバリングを付けた。記事1回単位のタグは共通なので、術式の修正はエディタの置換機能であっという間に終わった。だが、並べ替え作業に王道は無いので、1回分の範囲をドラッグしては、移動させる作業をちまちまちまちま繰り返すしかなかった。
　かくして20年ぶりにざっと読み返したのであったが、今のブログに比べると、今となっては随分こっぱずかしい記事が目立つものである。自転車で1日100km以上走ることは、今は到底やらない。RPGツクールを通した横のつながりが多かったせいか、文章に活気があるような気がする。20年以上も月日が経てば、更に地味さが増したものよ…。

　TOPが片付いてタグの整理も付いたので、いよいよ古いページから一つずつ書き換えている。その中でも、月本國法のページは最も重要な部類に入るだろうから、最優先で取り掛かるべきであろう。だが、いざ取り掛かると20年以上も放置されていて、何とお粗末なことよ…。この手のページは検索ロボットにはスルーしてもらった方がよいので、noindex,nofollowの呪文を唱えておいた。
　標識サイトの方では先行していたが、今回の更新では、リンクバナーの他にQRコードを新たに用意した。これの目的はリンクとして貼って頂いてもよいのだが、スマホのブラウザの履歴にこのページを残しておければ、誰かにサイトを手っ取り早くアクセスして頂くのに便利であろう。是非とも宣伝のために使って頂ければ大変有難い。こんな便利なものが手軽に用意できる時代が来るとは…。株式会社デンソーウェーブ様はノーベル賞に値する功績を残したのではないか!?
　20年もの間そういう場面には幾度と出くわしたが、毎回検索エンジンでテキストを入力させたりするのでは面倒なので、何か方法は無いものかと議論になっていた。今ではほぼ誰もがスマホを持っているだろうから、これでひとまず解決したであろう。もっとも、最近身内で最新のスマホの使い方が分からず、ぼやいている場面に遭遇したのであった。さすがにそこまで当局は関知できないので悪しからず…。

　何はともあれ、TOP向けの画像を二つ用意したわけだが、こいつがかなり面倒な作業であった。いかんせん面積がでかい。1200×630なんていったら、昔ならばデスクトップPC、今でもモバイルPCのフルスクリーンぐらいのサイズは十分あるではないか…。実際にSNSの画面で表示されるサイズなんてのは、スマホに収まるサイズぐらいにしかならないはずである。スマホ画面はブラウザの幅こそ小さいけれど、何気に解像度はしっかりしているから、表示した際の画質が結構よい。こいつがWeb管理者にとっては、手を抜くとすぐにバレるのがキツイところである。
　そしてこのサイズの面倒臭いところは、何故にこんな中途半端な値なのやら!?1200と630の最小公倍数が30ってのは嫌がらせか!?もっと大きな値で割り切れてくれないと、画像編集ソフトのグリッドが細か過ぎるし、レイアウトが1px単位で端数が出まくるしで超絶面倒臭い。メートル法の時代にマイルとかフィートとか当たり前に使っている欧米人に合わせるのは非常に難儀ということである。
　そんなこんなで注文通りに仕上げたわけだが、月本國の方は空想地図を一通り並べて、標識の方は画面いっぱいに標識を並べたわけで、予想以上に時間がかかった。作者はSNSのアカウントを持っていないので、仕上がり具合を試すには専用のツールを使うしかないのだが、画像編集でスタミナ切れなのでやっていない。もし不具合があったら連絡して頂ければ有難い。アクセス解析でリンク元がt.coってのは大手SNSらしいから、その数である程度感知できるだろう。

　OGPとは、Open Graph Protcolの略らしい。今やインターネット回線の大部分はSNSに支配されているではないか…。もはや当局にとってはOideyo GAPAN Projectと略すべきなのか!?まあそうしておこう。
　さてこいつはどうやって唱えるものなのか? 内容自体は、従来の検索エンジンのロボット連中に感知させるような、meta name タグのdescriptionやkeywordsなんかと同様らしい。それらをSNSのAI共が理解できるように、別の術式を重ねて唱えろというわけである。よって、大半は中身が使い回しで、術式を調整すれば済むらしい。そう考えると、悪い意味でSNSのAI共は舌が肥えているわけで、Web管理者からしてみればどうにもわがまま小僧な印象である。要するにほぼ二度手間ではないか…。
　そこへ新たに大きな注文を付けられたのがog:imageである。これは動画のチャンネルのサムネイル画像のようなものを宣伝向けに用意しろということだが、そのサイズは1200×630が推奨だとか…。ていうか推奨とは名ばかりで、ほぼこの規格通りで強制じゃんか!!サイトが二つあるということは、最低でもTOP向けに二つは用意しなければならない。とはいえ、OGPはサイト内のメインコンテンツに向けても個別に設定できる…というか、結局それも義務な気がする。てことは、画像の数もそれだけ用意しろってことか!?

　スライダーの設置工事が完了して、TOPページの外観はこれで最終形態となった。やっぱりどこから見たって地味過ぎるが、設置予定だった機能はすべて取り付けた。とにかく今までと比べれば、ずっとマシになったかもしれない。
　では引き続きサイト内のページに取り掛かるのか? その予定だったのだが、まだまだ作業は終わっていないらしい。ヘッダの術式を!DOCTYPE htmlから書き直したとはいえ、古いまんまの術式が全然整理できていなかった。それに加えて、現代のWeb環境に対応すべく、新たに出現した術式も唱える必要があるらしい。やれやれ…ただでさえ言語が異世界のものだというのに、20年以上もやっていると、更に見たことも無い呪文ばかりではないか…。
　かくして、まずは完全に時代に取り残されていた術式がOGPである。メタタグでこいつを唱えておかないと、SNS上では確実にディスられるらしい。いや、それは閲覧者の評価の話ではない。SNSで働くAIがバカだから適当な情報を流してしまうようである。自分ではSNSをやっていなくても、サイトの情報がSNSで正確に発信できなければ、古いサイトにとっては大迷惑な話ではないか…。これでmeta propaty=”og:〇〇”…の術式が何行もダラダラと追加されることになった。

　スライダーはslickというjqueryで動くものを使うことにした。扱いやすくてサンプルも多いという評価に素直に従ったまでである。早速必要なファイルを入手して、簡単なサンプルをコピペして動かしてみたのだが…ありゃ!?ウンともスンとも言わない。大抵こういう場合はどこかで単純な記述のミスがあったりするものだが、術式は一字一句正しいのにそれでも動かない。やがて容疑者が特定された。ヘッダのscript srcによるjsファイルの呼び出しは、jqueryの後にslickを並べなければならないらしい。原因は呪文を唱える順序のミスであった。やれやれ…こういう間違いはなかなか気付くものではない。改めてテストしたら、今度はちゃんと動いた。
　さてこのslickだが、評判通り簡単で使い勝手はよい。オプションが色々あって、サンプルを漁って試してみたら、とりあえず希望通りのものがすぐにできた。これで後はレスポンシブに対応してレイアウトを変えれば、完成は近いはずである。
　プロのwebデザイナーの間では、最近はjquery自体がディスられているらしい。だが当局はプロではないし、時間も無いのでなりふり構っていられない。こいつは有難く使わせて頂くことにしよう。

　webにおけるスライダーとは、複数の画像を同じ領域内で切り替えて表示させる画面演出のことである。一般的には横スクロール、要するに横方向に紙芝居のようにスライドさせることから、そういう名称が付いているのだろう。だけど画面切替の演出は他にもあるわけで、縦方向にスクロールさせたり、コマ送りにしたりと様々である。今では広い意味で、これらを総称してスライダーと呼ばれている。
　さてこいつをどう組み込むか? 0から自作する案もあったが、作者はプロではないので、面倒な作業は極力避けたいところである。それでもなるだけ軽く動作させたいわけで、まずはcssのみで試作した。いつも通りにサンプルを漁ってコピペしてアレンジしてみたものの、どうにもうまく動かない。それ以前にもしも動いたところで、やはりcssのみだと簡素な演出にしかなりそうにない。
　TOP画面はサイトの宣伝において重要なので、もっとインパクトが必要であろう。そもそもTOP画面では、アクセス解析とカウンターと日付表示でjavascriptを用いているわけだから、今更動作うんぬんでケチる必要はあるまい。かくして、ここはjavascriptを導入することになった。手っ取り早く済ませるにはCDNの導入だろうが、ネット上に数多く散らばるものからどれを採用すればよいやら…。

　スイッチの切り替えでナビゲーションメニューの表示と非表示を切り替えるわけだが、ここではラベルと同じ階層にメニューを組み込まなければならない。それはlabelタグの中にメニューを入れろという意味ではない。navとかdivとかで一つの大きなブロックを用意して、その中にラベルとメニューを両方入れろということである。それに気を付ければ、ハンバーガーの三本線と×の切り替えと同じ術式で、メニュー表示の画面位置を定めればよい。
　ところで、画面外表示における横スクロールバーの問題はどうなった?スクロールマップでは、はみ出した領域はoverflow:hiddenを唱えて隠している。だけど今回のメニューのように単純な構造ならば、もっと簡単な方法が見つかった。横スクロールバーはメニューを画面の右側へ出すと憎らしくも出てしまうのだが、何と画面の左側へ出すとバーは出ないではないか…。てことは、位置座標がマイナスの値を取る場合は出ないということなのか!?
　メニュー表示は画面の右端にしているので、右側の画面外から出し入れすると、かなり遠くからのスクロール演出にはなる。色々突っ込みどころはあるだろうが、これで何とか未解決事項はすべて解決したのであった。これにて正式にアップロードして、TOPページにはハンバーガーとナビゲーションが追加された。そして見れば分かるように、TOP画面には工事中の領域が存在する。ここには新たにスライダーを設置する予定である。

　二つの未解決事項のうち、何はともあれハンバーガーのスマホタップができない問題を解決しないことには、その先へ進めないと判断した。従来はサンプルに従ってjqueryを用いていたが、どうせ動かないのだからjavascriptは使わずに、動作の軽いcssを用いたシステムに作り直すことにした。
　cssでハンバーガーメニューをやるには、inputのチェックボックスを非表示にして、外見を三本線のハンバーガーにして、見えていないチェックボックスに対してラベルで紐付するという方法がセオリーである。それについてはどのサンプルを参照しても記されているので、ここでダラダラと書くことはしない。ただ、スイッチのON/OFF切り替え後の制御が少々ややこしい。その術式は、#チェックボックスに付けたID名:checked~制御するクラス名　…でほぼ共通だが、今後のために覚えておく必要があるだろう。この「~」が今まで見慣れない術式でかなり苦労した。
　ハンバーガーの三本線と×印の切り替えは最初のサンプルを流用したが、どんなサンプルでも制御は共通しているだろう。三本線を真ん中に重ねて、1本は45度、1本を他の1本に重ねるか又は透明にして、残りの1本を-45度にすればよい。ちなみに45度回転の呪文はtransform:rotate(45deg)である。transformの呪文はメニューを出し入れする際や、動作に演出を持たせるためにも用いられる。
　今回は段階を踏んで、正常に動いたところでアップロードしながら、スマホで動作テストをするという流れで細かく進めることにした。かくして、三本線をタップして×印に変化するところまでは成功。未解決事項の一つはようやく解消された。