History of my homepage

最初は・・・

HTMLを完全手書きしていた。(ホームページ作成ソフトを使ってHTMLを自動生成させるのではなくて、テキストエディタでHTMLをタイプするということ。決して紙にペンで書きだすということではない。）
そして、スタイルのほとんどはHTMLタグの属性値として指定しており、CSSでは全体の背景画像を指定している程度、といったことだけであった。後述するが、これは本来の（理想とする）HTMLとCSSに分担させた記述ではない。

そこで自身のCSSの知識を現代風に増強させ、本来の両者の分担（構造と装飾（デザイン、表現、体裁）の分離と言われる）での記述にしてみようと思い立った。
また、せっかくなので、レスポンシブ対応（表示させているデバイス・画面の大きさの違いによって表示スタイルを変え、デバイスごとに最適と思われる表示に切り替わること）にもチャレンジしようと思った。さらに、動的ページ（ページ内の操作によってページ内容が変化すること）のいくつかのテクニックを習得しようとも考えた。

とっかかりとして、無料で使えるテンプレート（ある程度のデザインとレスポンシブ対応済のCSSやJavaScriptが組み上げられているもの）を採用し、その中身を読み取り理解しながら、一部を自身のコンテンツに書き換えていくことから始めようと思った。
カッコよいページを手軽に作ることを目的としてるわけではないので、ホームページ作成ソフトは使わずにあくまでテキストエディタによる手書きは継続である。

方針

方針を明記しておくことは大切である。
とまどったときに、そもそも何をしようとしているかを見失わず、複数の選択肢がある場合に一貫した選択判断の拠りどころとするためである。

HTML/CSS/JavaScript全般

HTMLとCSSとの役割分担
HTMLには文書の構造にかかわるものや意味論な情報をタグにてマークアップして、コンテンツのみを書く。（もちろんハイパーリンクによるコンテンツのリンクは含める）
例えば、これは見出しである、これは単なる記述である、ここからここまでが段落としての塊である、これらの文章は箇条書きである、この部分は強調が必要である・・・などである。
一方で、大きめに、右に寄せて、色を変えて・・・などの文書の装飾にかかわるものは書かない。それらはCSSに書く。
(過去の経緯からHTMLにはそれらも指定できる仕様が残っているが、それらは過去の名残りであってCSSを組み合わせた現代では避けるべきである)
時には迷いも生じるであろうが、MDNのリファレンスを参考としながら、徹底していきたい。
CSSとJavaScriptとのトレードオフ
レスポンシブ対応、動的ページに関して、CSSだけでできることは安易にJavaScriptに逃げず、まずはCSSだけで頑張ってみる。
若干の機能差異（機能不足）であれば、CSSだけでの実装に妥協してよい。（将来自身のスキルが向上し、こだわりがある部分はそのときに着手することとする）
JavaScriptの量
安易にJavaScriptの量を増やさない。（多機能・便利といったことはあろうが、そららもまたページのロード性能とページの書替え性能に悪影響があることを忘れてはいけない）
IE(Microsoft Internet Explorer)向けの回避（新しい仕様への未適合やIEそのもののバグに対する回避）処理は書かない。（IEでの表示乱れは気にしない）
（今後も必要に応じて追加していく）

HTML個別

要素名、属性名は小文字で記述する。
リンク（<a>）要素にtitle属性は書かない。
（title属性に設定した文字列はマウスオーバした際にツールチップにて表示されるため便利に思われるが、タッチデバイスでは表示されることはない。よって、必要な説明は本文にて記述することとする。）
画像（<img>）要素にalt属性（何らかの事情で画像が表示できない場合に画像が表示されるべき箇所に表示される代替テキスト）を必ず書く。ただし、本文にて画像を説明している場合には不要とする。
装飾目的の画像（背景画像や装飾画像など）はHTMLの<img>要素ではなく、CSSにて設定する。どうしてもHTMLにて設定する場合には、alt属性は不要とする。
（この場合には、スクリーンリーダに読み上げてもらう必要はないものであるため）
<img>要素のtitle属性は書かない。（上記リンクにおけるtitle属性不要の理由と同じ）
コンテンツとして必要な画像では、<figure>を使い、かつ<figcaption>による図のタイトルを記載する。
<iframe>タグによるフレームには、必ず境界線をつける。
（引用したページの記載をあたかも表示中のページの本文として勘違いさせてはいけない）
<table>をページのレイアウトのために使うことはしない。純粋に表としての記載が適切と考える場合にのみ使用する。
（ページ内のレイアウト・整形はCSSにておこなうべきである）
<blockquote>をインデントつける目的のためだけに使うことはしない。純粋に「引用」を表現する場合にのみ使用する。
MDNのリファレンスにおいて、「非推奨」とある要素、属性は使用しない。（多くは、スタイルを指定するものであり、現代ではCSSで指定することが推奨される）

CSS個別

PCなど大きなウインドウでもページの画面幅は最大1200pxとする。そのときウインドウ内部のページの水平位置はウインドウの中央とする。
これは、<body>にて最大幅を指定するのではなく、その内側の要素（例えば<body>の直の子として用意した<div id="maincontainer">）に指定する方が良いようだ。
サイズ指定の単位は、em（親要素のfont-sizeからの相対値)を積極的に使う。
（全体のフォントを変更するときに、親の1か所の変更で済むように）
breakpoint（画面幅による表示の切換えの閾値）は、~~800px~~820pxと480pxを基準とする。

ブラウザでの表示テスト

手持ちのデバイス(PC, iPhone, iPad)の範囲での表示テストは極力行う
PCでは、Google Chrome, Microsoft Edge, FireFoxを対象とする
iPhoneでは、Google Chrome, Safari, Microsoft Edgeを対象とする
iPadでは、Google Chrome, Safari, Microsoft Edge, FireFoxを対象とする
ブラウザのバージョンは、自身のアップデート最新状態でのテストとし、過去のバージョンでのテストはしない

悩みごと・やっていきたいこと

現在保留としている悩みごと一覧である。発生したら追加して、解決したら消していく。
歳のせいか、あれやろう、これやろうと思い立っても一度にはできないし、まして、思い立ったことを忘れてしまったりするので。

HTML/CSS/JavaScriptでのインデントは、タブ文字か空白文字か、そしてその幅は何文字が適切か。（世の中空白文字2文字が主流の模様。大抵のプログラミング言語ではタブ文字を使い4文字幅が主流で、それに慣れている）
ひとまず、HTML:2文字分の空白文字、CSS:4文字分のタブ文字、JavaScript:4文字分のタブ文字、で進めている。
HTMLにおけるインデントはどういったときに付ける？子・孫すべてをインデントつけするのが正解か？（つけすぎるとテキスト編集の際にテキストが横に広がりすぎて読みにくくなることを懸念）
コメントはどの程度書くか？（通常のプログラムでは結構書く。しかし、HTML/CSS/JavaScriptはテキストファイルとしてコメントも含めてブラウザに読み込まれるファイルであり、ファイルが大きくなると、ブラウザへの読み込み性能に悪い影響を与えるので）
とは言え、現代のページでは画像ファイルの容量がおおきな比率を占める。よって、それなりのコメントをHTML/CSS/JavaScriptに入れることはあまり影響しないと考えられるため、あまり気にせずにコメントを書くこととする。
始めたころから、タグやidにスタイルを適用したものを多く書いている。それらを排除してclassにスタイルを適用するようにしていきたい。
classの命名規則をきちんと決めておきたい。[urgent]（スタイルを再利用しやすいように。でも長すぎる命名では支障がでてくることとのトレードオフ）
~~classの命名規則に従って、いつでも使うであろうclassをまとめて、1つのCSSファイル（再利用前提）にまとめてみる。~~
縦に長いページにおける「ページ先頭に戻る」ボタン（トップページはテンプレートにて実装されたもので内容は未解読。その他は自身でつけているもので常時表示させている）
これ、ちょっと不具合が・・・一度「ページ先頭に戻る」を操作したあと、ブラウザの「戻る操作」やページに用意した「戻る」を押すと、期待値である「前のページに戻る」ようには動作せずに、さっき「ページ先頭に戻る」を押した箇所に戻る動作になっている。期待値通りに動作するように改善したい。改善済
無料のレンタルサーバーでSSLが使えるサーバーが登場した。（シン・クラウド for Free）サイトの実体をそちらに移転し、SSL対応したい。
同様に、PHPやMySQLを（無料で）使えるということで、つぶやきのバックナンバーを、データベースに格納し、そこから生成したページにしたい。（現在は、つぶやきの追加に伴い、HTMLファイル間の記述の移動という手間をかけている）
同時に、サーバサイドプログラムによって、カレンダー表示、カレンダーの日付をクリックされたときにそのデータをセットしたページを返すなどとしたい。そう、世の中のブログサービスページがそうなっているように・・・。

こんなことをしてきた

まずは無料のテンプレートを利用。自分の画像や自分の言葉に差し替えただけ。不要な部分は表示されなくしただけ。
このときは、まだテンプレートの記載(CSS)をすべて理解しているわけではなかった。わからない記載をネットで検索しながら理解を深める。
トップページの上部の写真は、福井の東尋坊、石川の金沢駅鼓門、富山の海王丸・新湊大橋からの立山連峰に差し替えてはいるものの、その仕組み（アニメーション）の理解はいまひとつの状態

メニュー選択した後のサブページを徐々にCSSでのスタイル指定に変更。徐々にCSSの知識と理解深まる。

スマホサイズの場合の全体的なフォントサイズの調整（スマホサイズのときに別のフォントサイズでの表示とする）を当ててみた。

リンク集にあるMDNのサイトにて、一部自身のおさらいもかねて、当サイトのHTML, CSS, JavaScriptの説明を一通り読んでみた。当サイトのコンテンツはとてもすばらしいと思う。

外部リンクに「外部サイトへ出ていくよ」マークを付加してみた。（マークの画像を自身で作成し、CSSの設定に「<a>タグのhref属性に"http"を含んでいる場合には外部サイトへのリンクである」との理屈で、マークを表示するようにしてみた）→下記でさらに更新している。

「NEW」とか「工事中」の付加の仕組みを、個別の文字列の装飾としてではなくて、CSSによる特定のクラスへの疑似要素として実装してみた。
（<span>にclass指定した上で文字列（NEWなど）を書いて、そのclassで装飾をするとしていたものを、もとのタグにclass指定して、そのclassの::afterで文字列追加と装飾をするように変えてみた。これはこれで実装としてはかっこ良いが、アクセシビリティの観点では良くないのかも）

つぶやきのバックナンバーのページに、俗にいう「アコーディオン」スタイルを当ててみた。（HTMLの<details>タグのみでの実装であり、CSS/JavaScriptは使っていない）

ひととおり、サブページも含めてHTMLの整理とCSSでのスタイル指定を完了。しかし、まだ細かいところで不満は残っている。
ミニミニ英会話のページでは、「アコーディオン」をHTMLとCSSの組み合わせで実装してみた。

ファビコン（ブラウザのタブなどにページごとにデザインされたアイコン）を追加してみた。

自身のページに共通する（であろう）クラスの定義と、それらクラスの設定値をまとめたCSSファイルを作成した。そして、それに含まれないページごとのCSSファイルを分離して整理した。
同時に、各ページにおける、HTMLファイルの標準構成を考察し、それぞれのHTMLファイルを自身の標準構成に従うように整形した。

ページトップに戻るボタン操作後のブラウザの「戻る」や自身で用意した「戻る」ボタンの操作にて、期待に反してページトップに戻るボタンを操作した位置に「戻る」動作となったいた点を解消。
それは、ページトップに戻るボタンの操作時点で、操作した表示状態がhistoryに記録されることによっていた。よって、「スクロールしてページトップには移動する」ものの、「ページトップへリンクを進める」という動きにはしないようにした。（詳細はページのソースを見ると違いが解る。）

ページ内部ではなく、ページ外部の設定の話になる。Yahooドメインの設定にてtamamori.comをXFreeにあるホームページサーバttamamori.html.xdomain.jpへのリダイレクトするようにしていたのを、以下の設定に変更することによって、tamamori.comが直接XFreeにあるサーバに向くように変更した。（図解を交えた説明）

Yahooドメイン側：（簡易な「ホームページ転送」設定は削除し）DNSレコード直接設定にて、tamamori.comとwww.tamamori.comのIPアドレスをXFreeのサーバのものにする（Aレコードの追加）
XFreeドメイン側：既存のttamamori.html.xdomain.jpに加え、tamamori.comをドメイン追加指定。（このとき、認証方式を「Aレコード認証」とする。これによって、ttamamori.html.xdomain.jpとは別にtamamori.com用のエリアが確保される）
ttamamori.html.xdomain.jp用にエリアにおいてあったホームページのフォルダ・ファイル群を、tamamori.com用のエリアに引越し
（2つのエリアを同一に維持・管理するのは手間だし混乱のもとなので）ttamamori.html.xdomain.jpへアクセスされた場合には、tamamori.comへリダイレクトする様にし、かつその設定だけにした

ページトップに戻るボタンの実装を変更した。<a>タグとonclick属性でのjavascriptにて実装していたものを、単なる<div>タグとそれをクリックした場合のイベントリスナーを別ファイルに記述したjavascriptに記載するとともに、window(ブラウザ)のスクロールイベントをキャッチするイベントリスナーによってボタンそのものを「初期表示なし。ある程度スクロールしたら登場させる」ようにした。

外部サイトに出ていくよマーク、Google Material Symbols and Iconsのサイトから"Open in new"のアイコンを入手し、適用しなおした。

同一ページ内での移動（ページヘッダやメニューなどで用意したページ内の記述箇所へのジャンプ）を、id指定のアンカー要素（<a>）ではなく、<button>とそのonclickで動作するJavaScript関数scrollIntoView()にて実装してみた。これによってページ内の移動ではブラウザの履歴への追加を抑制している。

ふと、iOSのEdge(Microsoft Edge)で、<a href="https://example.com" target="_blank">example</a> としているにも係わらず、別ウインドウ（別タブ）で開かずに、元のウインドウ（タブ）にてリンク先のページに書き変わる事象が観測された。ネットでいろいろ調べて、rel="noopener"の属性指定をしていなかったことが影響していたのかと一旦思ったのであるが、結論はブラウザのバグだったようだ。Edgeを最新バージョンにアップデートしたら解消した。（観測されたバージョン：114, 116、解消されたバージョン：119）
その調査の中で、rel="nofollow"を知り、自身のサイトのページではない外部のサイトへのリンクに対しては、nofollowを追記することとした。（これらの詳細はWEB実装Tipsに書き残す）

ブラウザキャッシュ（ページのhtmlファイルなどをブラウザがローカルPC内に保存し、次回の表示の際には、サーバへ取りにいかずにローカルPC内に保存しておいたファイルを表示に使う高速化技術）について少し調べてみた。
このブラウザの振る舞いは以前から知るところではあった。しかし、自身がページ内容を更新し、サーバにアップロードした後にブラウザで見ようとしたとき、更新前の状態が表示されているということが起きることを解決したかった。自身がそうであるから、ましてやページを見に来てくれるユーザに対しても最新ではない状態で見えているということはとても好ましくない。
このことはWeb開発に係わる技術者だけではなく、広く一般に知られていることではあるものの、だからと言って「ページの更新操作してみてください」といったアナウンスだけで済ますというのもカッコ悪いかなと思った次第だ。万全ではないしページの表示性能への悪影響もある程度覚悟した解決方法ではあるが、対処してみた。（Web実装Tipsに書き残した。

・・・（徐々に続けていく）

気づき

気づきは、Tipsと合わせて、WEB実装Tipsにまとめて書くことにした。

その他

当初はホームページの置き場として、としあきが契約していたISP(Internet Service Provider)が提供してくれるホームページ容量とメアドなどを使用していた。あるときにそのISPは解約してケーブルTV会社のネットサービスに切り替えたときに、ホームページサービスやメールサーバサービスなどが無かったために、いろいろ模索した結果として現在の運用（ドメインの取得、ホームページ置き場としてのレンタルサーバ（無料）の契約、別途のメールサービス（無料）の契約、そして、それらへの転送の仕組みの設定）を選択している。

Yahooのドメインサービスにかかる費用は約3000円/年である。これを高いと感じるか安いと感じるかは、人それぞれだと思う。
でも、ドメイン名は使われていない文字列の早いもの勝ちで取得できるものであり、一旦離してしまうと二度と取得できない（他者にとられちゃう）かも知れないと考えたとき、維持し続けることを選択している。
特に、gTLD(generic top level domain)と呼ばれるドメインであること、そのなかでもメジャーな .com のドメイン名であることから、せっかく取得できているものを手離し難いという思いが強い。（この先、息子にオーナーを引き継いででも我が家で代々維持し続けたいくらいに思ってる。）

ホームページ転送以外にも、メール転送の機能も提供されていて、こちらの方はもっと有用・有効だ。
xxxtamamori.comなどの仮想のメアドをいくつも作成して、そのメアド宛のメールを裏にあるホントのメールサーバに転送してくれる機能だ。
ネットの時代だからいろんなところにメアド登録してたりするよね。裏のホントのメールサーバを将来変更することになったりしてホントのメアド変わったときでも、いろんなところに登録したメアドは変えることなく、メール転送設定を変えるだけで済む。
また、家族用にそれぞれ yyytamamori.com とか zzztamamori.com とかも作成して、それぞれのホントのメアドに転送させたり、複数のメアドを一つのホントのメアドに集約して転送させることもできる。