[13] [[文書]]の表示方法 (装飾) に関する直接的な記述を避け、
[[文書]]の構造のみを記述し、表示方法はその構造の表示規則として'''間接的'''に記述した方が[[可搬性]]が高く利用しやすい、
というのが [[GML]] 以来数十年にわたり[[マーク付け言語]]の設計者達が信じてきた基本原理です。

[EG[
[14] 例えば、雑誌原稿を後から単行本化することを考えると、
[[見出し]]部分に「フォントサイズ ○ポイント、書体 ○○」のような記述を書き込むより、
ここは「見出し」であるとだけ書いておき、
他に「見出しはフォントサイズ ○ポイント、書体 ○○」
という設定を用意する方が手間が省けます。

[15] また、[[Webサイト]]を[[デスクトップブラウザー]]の[[利用者]]にも[[モバイルブラウザー]]の[[利用者]]にも等しく見やすく表示するため、
本文と関連情報を左右に並べて表示する方式と、
本文の下に関連情報を続けて表示する方式を用意し、
[[画面]]の幅によって切り替えたいことがあります ([[レスポンシブデザイン]])。
そのためには[[文書]]自体に表示位置を書き込むのではなく、
「[[文書]]のこの部分をここに表示する」との指定を選択的に適用できる仕組みが必要です。
]EG]

[16] [[マーク付け言語]]を含む[[文書]]記述システムの歴史は、
そうした間接的な記述と、直接的な記述との綱引きの歴史でもあります。
平均的知識レベルの[[ワープロ]]の[[利用者]]が「太字」や「フォントサイズ大」
のような直接的な記述から間接的な記述へと移行するためには、
大きな学習コストが必要です。しかも、一度制作完了したら他の目的に再利用しないような多くの[[文書]]にとっては、
無駄なコストともいえます。間接的な記述にした方が同じ組織内の文書の体裁を整えるのが容易、
といったようなメリットもあるにはありますが、その程度であれば [[WYSIWYG]]
な[[ワープロ]]ソフトウェアで人の目で調整しながら編集するので十分ともいえます。
ですから、どちらの方式を採用するべきなのかは、文書の用途やどんな人が利用するかによっても変わるのでしょう。

[17] [[HTML]] はもともと [[SGML]] の流れから間接的な記述を志向していました。
これは色々な機種・[[OS]] で動作する [[GUI]] や [[CUI]] の[[ブラウザー]]が混在していた
1990年代前半の計算機環境に非常にマッチしていました。
しかしその後の [[WWW]] の爆発的な普及により、
非専門家を中心とする幅広い[[著者]]層が[[デスクトップブラウザー]]を中心とした[[利用者]]に[[文書]]を提供するようになった
1990年代後半には、[[ワープロ]]や [[WYSIWYG]] システムの影響を強く受け、
[CODE(HTMLe)@en[font]] や[[テーブルレイアウト]]などの直接的な記述に大きく偏るようになりました。
その弊害に気づいた人達は、[[装置独立性]]や[[表現と構造の分離]]のような原理を掲げて
「正しい [[HTML]]」の復権を求めました。

* 一般化マーク付け

- [1] Generalized markup。←→[[固有マーク付け]]。
- [2] [[SGML]] の ''GML''。文字の大きさとか色とかを直接するのではなく、もっと一般化・汎化して、それは見出しである、とか強調である、とかを[[マーク付け]]する手法のこと。
- [3] [[物理マーク付け]]に対する[[論理マーク付け]]と同じ概念。
- [4] >>1 [[JIS]] の用語では[[一般化マーク付け]]ですね。
- [5] >>3 だけど少し違っていたりする。 SGML の概念 (というか当時の技術的限界による合理的な考え方の限界) では、今の論理マーク付け論のように文章の構造を分析して、とか意味を機械可読に、とかいう高尚な考え方はなかった。ただ、当時広く行われていた、機種や環境でばらばらの表示出力書式を直接扱うと可搬性を損ねるから、共通形式を定めよう、共通形式はその出力機器の性能に見合って上手くやるには文書の構造を扱う方がいいだろう、という程度の認識だったようだ。
- [6] >>5 当時の技術的な性能では、とても [[DOM]] のように文書木を保持しているなんてできなかった。 [[SAX]] 的に文書のマーク付けを舐めながら、(一般化)マーク付けをその環境の書式 (固有マーク付け) に変換しつつ出力、というのが想定されていた処理モデルだ。
- [7] >>6 のような時代から、ちょっと性能が上がって手の込んだことが出来るようになってきて、 [[DSSSL]] とか [[HyTime]] に向かっていったんだな。。。。

* 記述的マーク付け

[8] ([TIME[2015-10-03 01:25:24 +09:00]] 版)
<https://www.jstage.jst.go.jp/article/jsik/18/4/18_4/_pdf>

* 表現と構造の分離

[31] 
[CITE[W3C Journal]], [TIME[2024-09-11T13:58:12.000Z]], [TIME[1999-05-01T19:31:12.561Z]] <https://web.archive.org/web/19990501192705/http://w3journal.com/5/s3.walsh.html>


[9] [CITE[yohei-y:weblog: Javascript+HTML のデザインパターン]] <http://yohei-y.blogspot.com/2005/09/javascripthtml.html>
([[名無しさん]] [sage] [WEAK[2005-09-19 02:33:43 +00:00]])

[10] [CITE[Standards for Life: Standards in a Nutshell II]] <http://www.standardsforlife.com/standards-in-a-nutshell-ii>
([[名無しさん]] [WEAK[2006-11-16 00:02:08 +00:00]])

[11] [CITE[楽天の店舗の中の人へ楽天Webサービス利用者から愛をこめて]] ([TIME[2007-02-10 22:00:39 +09:00]] 版) <http://neta.ywcafe.net/000718.html>
([[名無しさん]] [WEAK[2007-02-11 00:51:47 +00:00]])

[12] [CITE@en-US[Separation of semantic and presentational markup, to the extent possible, is architecturally sound]]
( ([TIME[2003-07-22 07:28:12 +09:00]] 版))
<http://www.w3.org/2001/tag/doc/contentPresentation-26.html>

* Separation of concerns

@@

* 言語


[33] 
[[GML]], [[SGML]], 
[[HTML]],
[[GNU Texinfo]], [[LaTeX]]


* メモ

[32] 
[CITE[Multi-purpose publishing using HTML, XML, and CSS]], [TIME[1998-06-15T11:56:42.000Z]], [TIME[2024-09-14T07:43:56.956Z]] <https://www.w3.org/People/Janne/porject/paper.html>


[18] [CITE@ja[HTMLページの構造の階梯(かいてい)]], [TIME[2021-04-25T07:02:18.000Z]] <http://deztec.jp/x/10/faireal/d10911.xml>

[19] [CITE@ja[naoさんはTwitterを使っています: 「こんなCSS書くような奴、ロクなもんじゃねえ。 信じられるか?これHTMLに書いてあるんだぜ・・・。 https://t.co/ebh4fouJH2」 / X]], [TIME[午後7:07 · 2023年8月3日][2023-08-03T10:07:25.000Z]], [TIME[2023-08-04T04:32:57.000Z]] <https://twitter.com/nao_web_/status/1687042478615261184>

[20] >>19 の返信が興味深い

- [21] 糞だと共感するタイプ

普通の感性

- [22] [[Tailwind]] と同じじゃん何が悪いのタイプ

一応態度は一貫している

- [23] これはひどい、 [[Tailwind]] を使えタイプ

いやいや...

[24] 
昔はよく見たという反応が多数あるのも興味深い。
昔よりこういうのが減ってる実感はあまりないし、 [[Tailwind]]
のせいで増えてる印象もあるけど、逆に思ってる人もいるのか。
統計データがないと全体的な動向はわからないなあ。


[25] 
[[table layout]] 時代によく見たという証言はさすがに記憶の劣化、混濁ではないかなあ。
[[table layout]] 時代なら [CODE[font]] 使っていた、 [CODE[style=""]]
使っていたという方がしっくりくる。
そうでなければ局所的な現象かなあ。
[[table layout]] の方が書きやすいという謎感性と
[[CSS]] に分離するべきという時代の流れの強制力が同時に働いた時期もまあなくはないのかもしれないが...


[26] 
元々 [[SGML]] は雑誌連載を単行本化するような原稿流用を楽にしたいとか、
新書を今度は文庫本で出したいというときに便利ですよという感じのを売りにやってたんですよね。
それが
[[HTML]]
で見ている人の環境が違ってもそれぞれにいい感じに表示させられて便利じゃんと実証されたもんだから、
[[HTML4]] が思い切り風呂敷を広げちゃった。どんな環境にも適応できる。何なら画面表示だけじゃない。音声読み上げだってできる。
将来登場する未知のデバイスにも対応できる。ってね。

[27] 
それで [[HTML]] は特定の環境での見た目を前提に書くべきではないとか、
表現方法は [[HTML]] には一切書いてはいけないとか、
どのブラウザーでどう見えるかを気にしてはいけないとか、
わけのわからないことを言い出す原理主義が台頭してきてしまったのです。
まあそれはどのブラウザーでも[[ピクセル単位で表示を制御したい][pixel perfect]]とか、
自分達が見た目を確認したブラウザー以外は締め出したいとかいう別方向の[[カルト思想]]への対抗で出てきたという側面もあるのですけど。

[28] 
実際には [[HTML4]] の目論見はほとんど完全な失敗で、ぎりぎり [CODE[print]] 
が今でも使われているくらい。
[CODE[handheld]] が紆余曲折を経て [CODE[viewport]] という新たな[[おまじない]]を生み出してしまったのはまだマシな方で、
[[音声読み上げ]]方面に至っては [[CSS]] を使わない [[ARIA]] という魔物を生み出してしまって、
技術的にはまったく真逆の方向に進化してしまいました。
[[表現と構造の分離]]、 [[HTML]] から [[CSS]] への表現構造の追い出しの大きな夢は、
[CODE[font]] と [CODE[frame]] と [[table layout]] を消し去ったくらいのところで潰えてしまいました。

;; [29] 実務上は [[table layout]] とそれに伴うバラバラ画像の悪習が消滅しただけでも御の字ですけどね。

;; [30] [CODE[font]] はなくなっても [CODE[style=""]] があるので大差はなく。
[[table layout]] も [[div厨]]に変わっただけですけど、
[[table layout]] の無駄な構造と独特のレイアウトモデルが [[CSS]] の[[箱モデル]]に置き換えられたのは大きな進歩です。




