個人運営のHTML手打ちの静的サイトとしての覚書。サイトを構築・リニューアルする時用に。思いつくままその都度書き足し、長くなればそれを別エントリにまとめる作業をします。
調査によると現在、Webサイトブラウジングの80%程度はスマホやタブレットだそうだ（適当）。よってまずは当然、このユーザーをメインターゲットとしてサイトデザインをするわけだ。
PCでの閲覧者は全員パソコン大先生なので勝手に見やすい環境を整えて見る。よって特別な配慮は不要で、余力がある場合に考える程度で良い。わざわざ手間のかかる2カラム3カラム対応や凝ったレスポンシブデザインにせず、1カラムで構築する。CSSで最大幅max-width:だけは決めておいても良い。
暫定的な結論: サンセリフ体（ゴシック体）
body {
font-family:
Verdana,
"Hiragino Kaku Gothic ProN W3",
"Hiragino Sans W3",
sans-serif;
}暫定的な結論: セリフ体（明朝体）
body {
font-family:
Georgia,
“Times New Roman”,
Times,
"Hiragino Mincho ProN",
"Yu Mincho",
serif;
}フォントはCSSで指定するが、シンプルにするなら以下の指定でミニマルな俺かっこいい、と最近までは思っていた。
body { font-family: sans-serif; }あるいは…
body { font-family: system-ui; }しかし、いろいろな問題があることが分かった。
例えばMacやスマホはデフォでそれなりに美しいし、また無理に固定するのはユーザビリティ的にマイナスだし、好きにローカル環境のフォントで見てくれたらいいという考えが基本だ。
ただ詳しく調べてみると、個人的な感想としてヒラギノですらアルファベットが欧文フォントと比べて美しくない。例えるならたまに見る日本語対応した中華フォントのような違和感を英語圏のユーザーは覚えるのではないか。よってfont-family:の設定では先に欧文フォントを読ませてヒラギノと合成させるのがベストだ。
ただし、例えばHelvetica NeueとArialはよく使われるが、前者は特に、日本語と合わせると小さく詰まる感じがありバランス良くはない。以下に（環境が対応していれば）フォントのサンプル。
Hiragino Kaku Gothic ProN W3:
The quick brown fox jumps over the lazy dog. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
0123456789Verdana:
The quick brown fox jumps over the lazy dog. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
0123456789Helvetica Newe:
The quick brown fox jumps over the lazy dog. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
0123456789Arial:
The quick brown fox jumps over the lazy dog. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
0123456789
結論として現時点では、Verdanaを最初に持ってきている。VerdanaはWindowsにもMacにもプリインストールされていて、横幅と字間が広いのでヒラギノ角ゴシックにもメイリオにも調和する。
サンセリフ体とセリフ体の選択はコンテンツを考慮して設定すべきだ。サンセリフ体なら汎用性高いしテック系などカチッとしたコンテンツに合ってるし基本的にはこれで良い。セリフ体はMacや高精細なスマホなら全く問題ないので、テキストをじっくり読ませたいサイトに使えば上品で格調高い印象を醸し出せる。
Windowsユーザー向けとしてデフォでインストールされているゴシック体の「游ゴシック」と「メイリオ」の順をどうするかだが、どちらも入れずにユーザーの個別環境に任せている。そもそもWindowsは今でも（特に日本語の）レンダリングがどうしようもないので、古の時代から入っている、MSで始まるヤバ書体を親切心で外す程度しかやることはないかもしれない。
なお、フォント自体がコンテンツだったり、意図的にデザインに全振りしたサイトなどは当然この限りではなくて、あくまでミニマルな個人サイトではこうするという話だ。サイト名や大見出しなどには個人のセンスを発揮したいだろうしWebフォントなどを使っても問題ない。ただしその場合、日本語フォントは膨大な漢字を含むため、欧文フォントと違いファイルサイズが大きいことを留意する。
だらだら長くまとまりも無いのでこの辺で。Webフォント、サイズ削減の方法、などはまた別で。
フォントサイズについては、メタタグでviewportを設定した上で、サイズ指定はデフォ状態で問題ない。デフォは16px、1remだ。どちらで指定してもいいが、自分は基本remでやっている。0.875remで14px、0.75remで12pxだ。
remはhtmlタグの文字サイズを基準とした相対的な文字サイズなので、入れ子（ネスト）になっても親要素の影響を受けない。サブ的にemを使って調整をする。
もっと凝るならCSSのfont-feature-settings:とletter-spacing:でカーニング（文字詰め）も考えるべきだが、Webでの日本語テキスト表示は皆、カーニングなしにもう慣れてしまっていて、字を詰めると逆に見にくく感じる人が多いかもしれない。それでも見出しなどには使っていっても良いと思う。長くなるのでやり方など後日まとめる。
普段からテキストをMarkdown記法で書いていて、それをHTMLに変換して多少手を加えるというルーチンなので、Markdownが対応していないHTMLタグはあまり使いたくない。手直しすることが増えて手間なのだ。よってHTMLは極力シンプルなかたちになる。もちろん視認性としてもその方が良い。
自分は簡易的に自動変換するマクロ的なものを作っているが、簡単なタグの変換程度なら正規表現で可能なのでテキストエディタなどでも可能だし、無料で変換してくれるサイトもある。ただし変換されたHTMLソースには各々個性があるのでそこは留意。
以下に簡潔化した主な対応表。表の作成はMarkdownでも面倒なのでツールなど使ったほうが良い。
| Markdown記法 | HTMLタグ |
|---|---|
| # 半角SP空ける | <h1> |
| ## | <h2> |
| ### | <h3> …以下同パターン |
| テキスト | <p> |
| *テキスト* | <em> |
| **テキスト** | <strong> |
| [テキスト](URL) | <a href="URL">テキスト</a> |
|  | <img src="画像URL" alt="代替テキスト"> |
| > 引用 | <blockquote> |
| * or - | <ul><li>項目</li></ul> |
| 1. | <ol><li>項目</li></ol> |
| --- | <hr> |
| `コード` | <code> |
| ```コード``` | <pre><code> |
| | 表 | 表 | | <table><tr><td> |
先ほどの続きでもあるんだが、HTMLソースもMarkdownと同じくらいのシンプルさ、視認性を保持したい。よってdivタグは基本的に使わない。idやclassもどうしても必要な箇所を除き付加せず、HTMLの要素そのものやその親子構造の組み合わせなどを活用してCSSでデザインする。自分はそれをパズル的に楽しんでいる。
これは当然、ミニマルな個人サイトだから出来ることであって、ビジネスのサイトやチーム作業を伴う場合は皆が認識できるように丁寧に注釈のようなidやclassを振るのが良いとは思う。
最近考えが変わってきたので追記予定…
先に結論: 色数は抑える
Appleなどのセンスの良いサイトやアプリの配色を参考にする。テキストが読みやすい配色を前提に、明度と彩度を意識して全体のトーンを調和させる。
背景が白黒どちらベースでも基本的に色数は抑える。そのほうがテキストならコンテンツに集中できるし、画像メインのページなら映える。シンプルにいくなら背景に2色、テキストは強中弱で3色、リンクに1色、程度でも良い。
先に結論: 幅1920px または 2800pxでWebP
画像サイズについて。ひとつの案は、幅1920pxの画像にすると一般的なPCに合うし、またFHD=1080pの幅でもあるので転用しやすい。画像メインでないならこれで良いだろう。
高精細な写真等がメインのサイト用にもう一つの案。現時点のスマホのなかで比較的最大級の iPhone 15 Pro Max のデバイスピクセルベースの画面サイズは1290×2796px。12.9インチの iPad Pro が2048x2732px。これをスマホで見る人の最大ピクセルとして、画像を作成、表示する。横画面で見られる可能性や将来性まで考慮し、長辺2800pxがキリの良い数字だろう。もちろん元が小さい画像を無理に引き伸ばす必要はまったくない。
2800pxってそんなサイズは容量クソ重いやろ！と考えがちだが、WebPかAVIFなら元の画質をあまり損なわずにJPEG以上の超軽量化が可能だ。どちらも一般人には馴染みない画像フォーマットかもしれないが、対応状況が確認できるサイトのCan I useを見てもWebPはモダンなブラウザなら全部対応しているし、企業サイトでも普通に使われている。AVIFはWepPに比べてブラウザ対応は少し遅れてはいるが、さらに優れた圧縮率だ。以下にWeb上でどちらにも変換できるサイトやツールを紹介するので試してほしい。
以下の画像はWebPだが、元は2800x4200pxの57MBのPNGファイル。Midjourneyで生成した画像をTopaz Photo AIというツールでさらに拡大させたものだ。これをWebPに変換して307KBになった。ここまで圧縮しても画像の劣化は肉眼ではほぼ確認できないレベルだ。
自分は今のところ、AVIFではなくWebPで統一しているが、Web製作者がどちらを使うかは悩みどころだ。また、より優れた圧縮の画像フォーマットが出てくる可能性もあるので、将来的にはどうなるか分からない。
なお<picture>タグで複数のフォーマットを用意する手法は一応紹介しておくが、手間対効果が悪すぎるのでやらない。
<picture>
<!-- 優先順に書く。type属性はブラウザが未対応フォーマットかどうかの判断に必要 -->
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="画像">
</picture>先に結論: アイコンやロゴはSVG
アイコンやロゴはありすぎても画面がうるさくなるし、基本的にテキストで済むならそれがいいんだが、必要な場合はSVGデータをCSSで表示する。
例えば、NeokiのX ←外部サイトへのリンクという意味で端に付けているこのアイコンもSVGだ。
作成方法の詳細は別エントリで紹介予定。
エントリ日、更新日など、日時表記の項目をコンテンツ内容と別に設けなくてもたいした問題は発生しない。なぜなら日時が重要な話題なら当然本文に書くからだ。まずそこにあるのが当たり前となっている思考を変える。
HTMLファイル名=URLを、アップしたYYYYMMDD形式の日付けを含むようにする、またはそれだけにする。スマホのブラウザ上で見た場合、基本的に画面の上下どちらかにドメインが表示されているが、そこをタップすればすぐ確認できるというメリットがある。
1日に何回もエントリをアップする可能性のあるサイトなら例えば「20240101-01.html」などとすれば良い。自分は更新頻度低いし、また手間なので不要だ。ついでに.htmlの拡張子なしでアクセスできるようにサーバの設定をするともっとシンプルになって良い。
それでも表示したい場合ひとつのアイデアとして、Javasvcript等でHTMLファイル名とファイルの更新日を取得し、簡易的にそれぞれエントリ日と更新日として表示することも可能だ。
以上のことは既にサイトに組み入れているので別項で紹介したい。
先に結論: 不要なメタタグを捨てる
広告も貼っていない個人サイトに過剰な集客要素は不要なので、SEOやSNSを意識したメタタグや更新通知対応は極力なくす。キーワードの羅列、SNS用のOGPメタタグ、などだ。こういう無駄な手間を増やすと結局更新が億劫になってしまう。HTMLの上部にメタタグがだらだら多いのも美的に良くない。今後、アフィリエイトやセミナー開催など魂を売っても集客すべき場合にはメタタグは当然必要となってくる。
残すべき必要なmeta要素はcharset、viewportあたりだ。
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="format-detection" content="telephone=no">まずGoogle Cromeの「デベロッパーツール」や「要素の検証」は使えるので、挙動がおかしいときは確認。
間違いなどがあればXに連絡してください。あとなんか思いついたら書く。