しかし、少なくともいくつかの明確な要素を特定することは可能でした。 たとえば、論文「WYSIWIG-absolute evil」は揺るぎない真実を生み出しました。 これは、TinyMCEなどのWYSIWIG汎用エディターを指します。 以下では、許容される悪の1つとして「制限」エディターに触れます。
WYSIWIGの主な問題は何ですか？ 誰もエディターが開発された統一サイトスタイルに従うことを強制することはありません。 彼（a）は常に背景が有毒な黄色で、見出しがピンク色である理由を自分で言い訳します。 これは概して問題ではなく、サイトの所有者に仕事を楽しんでもらいましょう。 問題は、チームがサイト全体のデザインを更新するために到着したときに始まります。 もちろん、キャップ、メニュー、地下室を変更しますが、コンテンツをどうするか？ 真空の球状のマネージャーがデザイナーの推奨事項に厳密に準拠していても、WYSIWIGエディターによって生成されたHTMLコードについてはすべて同じですが、多くの歯が折れます。
出力の1つとして、特別なWYSIWIGエディターを使用できます。このエディターは、デザイナーがこのプロジェクトで提供したスタイルを除くほとんどすべてのオプションをカットします。 したがって、HTMLコードは完全に「クリーン」に生成されます。 このようなソリューションは、たとえば、潜在的な編集部隊が容赦なく金髪である場合に適用できます。
ただし、「限定的な」WYSIWIGエディターでさえ理想的ではありません。 これには少なくとも2つの理由があります。 まず、すべてのコンテンツ要素がWYSIWIGにできるわけではありません。 あちこちで、ガジェットやその他の非標準要素を挿入するための条件付きマーカーを配置する必要があります。 いくつかのプロジェクトでは、それらの多くが存在するため、疑問が生じます。 すべてのコンテンツをマークする方が簡単ではありませんか？」
「制限」されたWYSIWIGさえ使用しない2番目の理由は、写真、スタイル、ガジェットなどのマネージャーの形で大量のコードを追加する必要があることです。このプロジェクトで必要なものかどうか。 私たちは基本的に何をしていますか？ 古い、よく知られているファイルマネージャー、ブラウザー、およびオペレーティングシステムの他の要素を置き換える、不便な角のある自転車を作成します。
自由度の数を減らしてみましょう。 私たちのマネージャーはコンピューターに詳しい人だとしましょう。 彼らは、ファイルが何であるか、そのアドレスを持つWebページが何であるかを知っており、ディスク上の画像とインターネット上の画像を区別できます。 WYSIWIGとそれらの貧弱な手段との短い鎖でそれらを保つことはより高価です。 彼らは便利で簡潔なラベリングシステムを提供し、自由水泳に解放する必要があります。
ラベルの選択は実際には素晴らしいものではありません。 HTMLは完全に消えます。 神話上の「危険」のためではありません（第一に、フィルタリングは最近では難しくありません。第二に、モデレーター/管理者/サイトの所有者からの入力をフィルタリングする理由です）。 主な理由は、HTMLが冗長すぎることです。 たとえば、キャプション画像などの非常に典型的な要素を作成するには、まともなコードを記述する必要があります。 コピーペーストでも管理者にこれを強制することは完全に正しいとは限りません。 この特定のプロジェクトのHTML標準を拡張し、追加のタグと属性を追加できます。 しかし、一般的に、これはすべて非常に乱雑に見えます。
2番目の選択肢はBBコードです。 実際、これは前の段落で述べたまさにHTML拡張です。 そのため、乱雑さが残っています。 さらに、違法。 BBコードを含むテキストは非常に読みにくいです。 おそらく、同じ角かっことは対照的に、角かっこが文字とあまりにもうまく融合するという事実のためです。 BBコードを生成するWYSIWIGエディターは、他人のジョークが失敗したと考えています。
最後に、記事の最後に到達しました。 はい、MarkDownの最後のバージョン。 一般的に、MarkDownは良い印象を与えます。 簡潔で、ニーモニックで、視覚的に認識されます。 語彙の制限や方言の不一致など、いくつかの欠点があります。 実際、これらの問題はMcDaoによって解決されることを意図しています。
McDao （「mekdao」と発音）は、PHPで記述され、コンテンツ管理システムに埋め込まれるように設計されたMarkDownスタイルのマークアップパーサーライブラリです。 McDaoの主な機能はスケーラビリティです。 任意の文字またはその組み合わせからマーカーを入力したり、標準マーカーを再定義したりできます。 さらに、マーカーの粒度の統一された構文が導入されました。 これは主に、写真やリンクなどのより複雑な要素に関するものです。 ウィキペディアの不協和音の括弧から少し吐き気がする。 パートタイムのウィキペディアエディターは問題ありませんが、他の素人にとっては、これらの山括弧は決してニーモニックではありません。
この粒度の構文は、リンクや画像だけでなく、他の標準または定義済みのマーカーにも適用されます。 この構文がニーモニックの例であるとは主張しませんが、それでもすべてのマーカーと互換性があるという点で優れており、後で説明するように、まったくエキゾチックではありません。
McDaoは 2つのエンティティを意味します。少なくとも1つの空白行で区切られた段落と、インラインテキストです。 実際、ここには新しいものは何もありません。この規則を単純に述べています。 テキストの残りの部分からスペースで区切られた最初の英数字以外の文字（または複数の文字）は、この段落のコントロールです。 インラインテキストについて特別なことを書く必要はありません;誰もがその使用法に精通しています。 これはすべて次のように説明できます。
= =
== ==
** .
おなじみですよね？ 次に、より微妙な質問-角括弧について。 デフォルトでは、写真[picture.jpg]にのみ完全に与えました。 しかし、リンクはどうですか？ 推測できません：_www.example.com_。 しかし、通常の下線はどうですか？ まあ、まず、スタイリッシュで実用的なデザインで、通常の下線を引く場所がありません。 次に、パーサーがリンクを取得していないと判断した場合、このテキストに下線を引きます。
マーカーに追加の属性を導入することで、McDaoダイアレクトの中心になりました 。 このために、[picture] <picture.jpg>や_example_ <www.example.com>のように山括弧が使用されます。 なぜデータはそれほど分散しているのですか？ カスタムマーカーを定義するときは、次のルールを使用することをお勧めします。視聴者が見る（または見る可能性のある）すべてがマーカー内に書き込まれ、技術的な「オフスクリーン」属性が山括弧内に配置されます。 正式には、このルールを使用して、画像のALT属性を指定しない場合、[] <picture.jpg>と記述する必要があります。 はい、できます。 しかし、なぜそれが必要ではない場所で、そしてパーサーが[picture.jpg]を完全に理解する場所でそれを使用するのが面倒なのでしょうか。 最初に、簡潔さとわかりやすい構文の目標を設定しました。
次に、より複雑な例：リンク付きの写真。 2行目から正しくプロンプトを表示するには、_ [] _を使用する必要があります。 ただし、追加の属性がかなりあります。 それらに対処する1つのオプション：
_[alt ]<picture.jpg>_<address>
しかし、非常にぎこちなく同意します。 新しい特殊な2文字のマーカーを定義するだけでよいのではありませんか。
_[alt ]_<src=picture.jpg href=address>
お気づきのとおり、追加の属性が複数ある場合は、名前を付ける必要があります。 この例は、純粋に学術的に重要です。 実際には、もっとシンプルに見えるでしょう：
_[picture.jpg]_<address>
よく考えられたアプローチでは、名前付き属性が必要になることはほとんどありません。
健全な開発者は、サイトの内部ページに絶対アドレスを指定することを許可しません。 そして
_ _<index.php?page=contact>
CNCは発生する可能性があるため、許容範囲を超えています。 これがマーカーの傍受が私たちの助けになるところです。 内部アドレスは、解析されて必要なものに置き換えられる条件付き構文で記述できます。 例：
_ _<contact>
_ _<price,alpha>
一部のガジェットでは、特別なマーカーを定義できます。 たとえば、ビデオを挿入する必要があります。 ビデオの波括弧を選択します。 {j76JvlLbki45c}のような結果になります。 い長さやYouTubeへの完全なパスは、思いやりのあるデベロッパーによってコンテンツマネージャーから隠されています。
また、ページにテキストブロックまたはモジュールを挿入する必要もあります。 タイプインクルード...このようなニーモニックをどう思いますか？ たとえば、たとえば、次のようなニュースモジュールがあるとしましょう：{+ news +}。 中かっこが既にビデオに含まれていることを恥ずかしがらないでください。すべてが正しく処理されます。 注意する必要がありますが、この場合、ビデオではニーモニックとシーケンスの{{video.flv]}のようなものを定義する方が良いでしょう。
同様に、すべてが段落マーカーで機能します。
= - <special>
.
,
.<foobar>
%
«».
:
% {j76JvlLbki45c}
McDaoでは、かなり複雑なオーバーライドを作成できます。 典型的なタスクの1つを次に示します。記事のリストを定義します。 リスト項目は、タイトル、リンク、アイコン、イントロテキスト（ティーザー）です。 McDaoがこのタスクを処理した方法を次に示します（いくつかの追加ルールを設定した後）。
-- 1 [icon1.gif]<link1>
Introduction text blah-blah-blah…
-- 2 [icon2.gif]<link2>
Another introduction text blah-blah-blah…
ご覧のとおり、拡張リストの要素を定義するために特別なマーカー「-」を導入しました。 そして、他のすべての定義は非常に読みやすく、明白です。
McDaoは、次のトークンに対して標準のデフォルト動作を提供します。
= =
== ==
===
--- ( )
-
-
-
#
#
> «>»
>
|= 1 =|= 2 =|= 3 =|
| | | |
| | | |
| | xxx | |
. <p>.
<script>
/* , HTML , */
</script>
事前定義（ただし再定義）インラインマーカー：
**
//
^ ^
_ _
[]
_[ ]_
このライブラリの使用方法に関する技術的な詳細は説明しません。 彼女が興味を持っている人は、ダウンロードしてそれを理解することができます。 一般に、ライブラリは非常に軽量です。 ただし、その作業結果のキャッシュはまだ誰にも妨げられていません（キャッシュはMcDaoの範囲外であり、CMSに依存しています）。
McDaoのアプリケーションのもう 1つの予期しない側面に注意する必要があります。 プロジェクトの1つでは、かなり複雑な構造のデータを保存し、定期的に編集する必要がありました。 正式には、XMLがこれに最も適していると考えられています。 しかし、人間が読めるように開発されたこの尊重された構文は、冗長すぎて非常に読めないことが判明しました。 基本的に、もっと楽しいYAMLがあります。 しかし、この目的のために、 McDaoを （一連のオーバーライドされたルールと共に）使用できることが判明しました。 いくつかの利点もありました。 第一に、マネージャーはその構文にすでに精通している、第二に、特定のタスクのために特別に設計されたニーモニックは、YAMLの利便性にさえオッズを与えました。
これがMcDaoであり、MarkDawnの愛好家やコンテンツ管理の便利なソリューションを探している人々の興味を疑いなく喚起します。