当IT規則 2020年代

「何らかの不便があっても直さん!」という説明。
現代まだまだ応急適応案ばかりで、遵守に値しない。

世間にコードが多種あるのは、まだ最終解へは到達していないから。
即ち、多経路を冒険中のここ現代。

機械、自然、どちらも設計図というコードで出来ている。
コード研究はいつか魔法陣を生み出すようなもん。
化学反応の成体『鉄』にコードと電気を刻み、巨大図書館(星)を浮かべることが、設計図の終着点なのかもしれない。
鉄で機械作ってる我ら人間は、まさに、その設計図通りに操られている最中。

まぁつまり…。
「如何なる不便もいつか自然解決するさ」

なるべく永久化

地球上の如何なるサービスも、永久ではない。
都度バックアップは勿論、どうしても永久化したければ冊子化 PDF化 ログサービス登録などが挙がる。

で、今回はそれ以前の話。

世の元来体制⇒「レンタルサーバーに独自ドメインでHP建てる」
これ俺はやらん。
・レンタルサーバー会社にGoogle級社は少ない、つまりサービス寿命差がある。
・いつかは免れない「独自ドメイン解約」で、そもそもURL停止。

俺の安定案↓

尤も、どの中小企業がGoogleを突然超えるかは、誰にも分からない。
皆さんは「推し社」を見込んであげよう。

特にアフィ収入目指すなら、『エックスサーバー(とエックスサーバードメイン)』、またはその系列社の『スター8』などに即決すりゃいい。
・ドメイン価格に変な手数料が上乗せされたり…が無い。※初年価格と延年価格はさすがに違う。
・『スター8』は、ドメイン購入特典で、無料サーバー5G付き。※2020年代時点。
・管理画面にファイルマネージャー付き。
・商用HP含むあらゆる用途のHPが可。※アダルト以外。
こうも最適解ペラペラ明かしても、俺には無用だから損無し。

ファイル命名

・1ossan1
・1ossan2golf
・1ossan3end
・2obasan1bakusyou
・2obasan2
・2obasan3
・2obasan4end1t ←トゥルー
・2obasan4end2b ←バッド

Windows始め現代OS多数にて、綺麗に並ぶ。
番号管理でありながら、内容(golfなど)も分かる。

機械&人間の両者にひとまず納得してもらえる、和平ラベリング。

テキトーに入手したdraftファイルには「0draft1」「0draft2fish」などで。
最悪、命名せず初期名でも、上記オッサンオバサンに並べば判別可。

なお、数字をも文字扱いする原初COMには伝わらない。
例えば1の次が2ではなく10(イチゼロ)となってしまう。
だが原初こそ、魔法陣化において将来向き合うべきヒント?
まぁ「ひとまず」の話。

どうしても原初COMに合わせるなら…。

CSS外観

世のIT事情は知らんけど、俺はこれがいい。
[画像] 我がveindent方式のCSS外観

詰め詰めだが「図形を見る脳」で読解。

必要最低限のスペース数と改行数。
さすがにコロンくらいは人間目視するし、そもそも「カラーホワイト(例)」という塊で認識するから、これでいい。
となればスクロール激減。

※コードである以上はどう書いてもゴチャゴチャ。あくまでマシってこと。

スペース区切りを多用しない。
本当に必要なスペースと判別付く。
相対的に、スペースに大きな意味が宿る。
・「width: 10px; height: 10px;」
・「width:10px; height:10px;」
…どちらが見やすいかだ。

カッコだけの1行独占をしない。
僅かこれだけで視認性が上がる。
※従来は、閉カッコが左端にあり、視覚的に題と同列で紛らわしい、おまけに余分スクロール増。

自由記述/**/の1行独占は、大題のみ。
他は必ずコード後ろ。

ただのパディング設定

bodyにパディング設定すると、中のheader 階層nav main(h1やp) footer全てに掛かる。
mainにもパディング設定すると、本文がさらに内寄りに。
※mainにパディングが無きゃ、境界と本文端が引っ付いてしまう。
※境界は視認性に必須。

もしブロック辺と文字が近すぎると↓
・「こ」が「に」に見えたり、「記号付き文字」のように見えたり。
・文頭探しで、目が境界にぶつかる、または文頭と境界の「狭い余白」を凝視して実感しようとする。

mainにマイナスパディング設ける方法がある。
けど明らかに根本策ではない。

bodyに一切パディング設けず、内容物それぞれに個別パディング設けた。
「デザイン同じとは限らないもの」を個別設定していくこの体制がそもそも良い。
けどこれも根本策ではない。

未来予想。
header main footerなどは、いつかbody内要素(=他者)ではなくbodyセクション要素(=body自身の一部)になるのでは?
となればh1 h2 h3もmainセクション要素になってほしい。
そう信じ、今は設定漏れがあっても無理には直さない。

「幅いっぱいにh1を広げたい 他は内寄りにしたい」は俺だけの要望じゃない筈。

階層記号

見たまんま。

URLやフォルダは「順スラッシュ」で区切られている。
/1ankoku/1start.html

p>

だからこうした↓

・親子⇒(順スラッシュ)
・同層⇒(垂直)
・子親⇒(逆スラッシュ)

こんだけの話。
・親ページ/子ページ
・子ページ1|子ページ2|子ページ3
・子ページ\親ページ

例えばtitleを「当IT規則\葉王リーフ」としている。
どっかのネット風習の「キターーー」みたいになってるけど慣れろ!

最適化不足1

ヘッダーとフッターを強引に「呼び出し式」にした。
厳密には「埋め込み」のiframeコード。

phpかssiでパーツ合成式にしろ?無理。
前者は適応力(←遥か上述)があるほうだが、偶然にも当環境では専用機能経由させられ断念。
後者は徐々に廃絶中。
とにかく「フォルダ投げるだけでHP仕上がる」を根底としたい。

js使え?無理。
js不使用と言い張りたい方針。
仮にいつか「js統合化の時代」が来ちゃったら、まぁ知らん。

ていうかcss仕様側が悪い。
css 画像 動画などは呼び出せるのに、txt htmlは呼び出せないもん。

いっっっつも記事毎に同じヘッダーフッダー記入。
これが現css標準。
「固定内容にしろ」とSEOは煩いのに、固定呼び出し手段が標準搭載という。
修正箇所があれば全記事修正せなアカンわけ。原始人すぎ。

SEOに反してでも、フィードバック提唱として、このiframe式を断固譲らない。

最適化不足2

例えば、当HP内[/1fksg/0ikusei1]にあるボタン。
目次に巻き戻る、そう、巻き戻るから『天刻』。
この謎ボタンに誰もが驚いたことだろう。

これ、タブレット機には最適化不足。
演出が自動解除されず、わざわざ他の場所(どこでも)をタップする必要がある。

察しの通りhover(ポインタ)アクションの処理。

世間的にも、タブレット用HPにはタップ演出が少ないだろ?
『ポインタ』は現代時点ではタップと長タップに統一されている。コントローラー操作時はカーソル乗せれるけど。
且つ、タップ放してもこのポインタ判定が永続する謎仕様

これに合わせて最適化、つまり演出消す、またはPC時タブレット時とで挙動分けコード?
…やらん。

明らかに謎仕様のせいなんだから、いつか自然解決されるだろうと期待。
そうなれば、挙動分けコードはいつか異物(=バグ要因)になりかねないし、俺とて永久に手直しできる保証は無い。
だから最適化不足でええねん。

各自で演出解除する1タップ手間について了承あれ。

目次