-
Notifications
You must be signed in to change notification settings - Fork 4
/
25.txt
72 lines (57 loc) · 6.08 KB
/
25.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
[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>
* 表現と構造の分離
[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
@@