Regarding HTML
このページでは HTML に関連するシステム設計について解説しています。
HTML 要素の識別
KARAS で書かれたテキストには HTML を含めることができます。ただし KARAS の標準的なコンバーターは、HTML タグの内容を理解しません。例えば次のようなとき、テキストは p 要素として出力されます。
This text become a paragraph. <pre>In HTML</pre>, p element cannot include pre element.<p>This text become a paragraph. <pre>In HTML</pre>, p element cannot include pre element.</p>この出力結果の HTML は誤った構造を持っています。 pre 要素は p 要素に含めることができないためです。もしも KARAS の標準的なコンバーターがタグを解析するならば、 p - pre - p のように、2つの p 要素が pre 要素を挟む構造になります。しかし KARAS の標準的なコンバーターではこれをしません。理由は変換速度のためです。
ユーザが書いた HTML タグの中身を解析すれば、理想的な出力結果を得られますが、解析することの負担はとても大きいです。W3C の資料を読む限り、2014年現在では、インライン要素は 28 種類、それ以外の要素は、28種類以上あります。もしもタグを解析して適切な出力結果を得ようとするならば、少なくともインライン要素の 28種類のいずれのタグであるかを判定する必要があります。タグが現れる度にそのような処理をすることは、変換速度を落とすことにつながります。
ユーザが自由に HTML を挿入するときは、そのユーザは HTML に対して十分な理解を持っていると考えられます。したがって出力結果の正しさを保証することよりも、変換速度を優先することに大きな問題はないと判断しました。この pre 要素の問題以外にも、HTML の構文を解析しないことによって起こるほとんどの問題は、高速な変換のために解決されません。
- Reference
この問題は将来的に、あらゆる環境で十分な変換速度が実現できるタイミングで、解決することができるかもしれません。つまり、将来的には、KARAS の標準的なコンバーターが、タグも正しく認識する可能性がある、ということです。しかしながら、現在のところ、その予定はありません。その理由については次の項目で解説します。
< から始まるテキストの識別
KARAS の標準のコンバーターでは、< から始まるテキストを HTML 要素として判定します。理由は、上の項目と同じです。 < から始まるテキストが、HTML タグの一部なのか、あるいはテキストなのか、判定するためには多くの処理を必要とします。
さらに、将来、新たな HTML 要素が定義されることもあるかもしれません。また、ユーザが独自に定義するタグについても検証することは困難です。あらゆるタグを KARAS の変換処理から取り除くことは、私は良いことだと考えています。
HTML 内にある KARAS の構文
< から開始されるテキストに含まれる KARAS の構文は変換されません。正しく変換するためには多くの処理が必要になり、変換速度が遅くなるからです。また、変換しないことによって、そのテキストが KARAS のコンバーターによって変換されないことを明らかにすることができます。KARAS では必要なら HTML を書くことができますが、HTML を書くときの多くは、コピーアンドペーストを使うと思います。この仕様であれば、コピーアンドペーストした HTML テキストに含まれる KARAS の構文を探してエスケープするような、面倒くさい作業は要らなくなります。
当然のことですが、ユーザは、KARAS の構文で出力される HTML と同じ内容の HTML を書くことができます。したがって、この仕様は問題を持っていないと考えています。
改行の除去
多くのブラウザでは、HTML の p 要素や li 要素の中にある改行は、半角スペースと同じように僅かな空間としてレンダリングされます。KARAS では空行が現れるまでは、改行を含めたテキストを1つのブロックとしてみなします。例えば、次のようなときです。
This is sample text.
This is 2nd line.<p>This is sample text.
This is 2nd line.</p>このとき1つの問題が起こります。改行が半角スペースとしてレンダリングされることは、特定の言語にとっては良くないことです。例えば、日本語などのように、それぞれの単語を空白で区切らない言語です。例えば次のような入力の場合です。
ABCDEFGHIJK
LMNOPQRSTUこの出力結果は、ブラウザ上では ABCDEFGHIJK LMNOPQRSTU となります。これは英語のような単語ごとをスペースで区切る言語では良いルールですが、日本語のような、単語が連続する言語では良いルールではありません。
この問題に柔軟に対応することは困難です。例えば言語によって、改行を消した方が良いのかどうかを判定することが考えられます。あるいは、例えば日本語であっても、ユーザが書いたテキストが英語であったり、他のスペースを必要とする言語であるかもしれません。KARAS の標準的なコンバータでは、この問題を解決していません。
この問題を解決するためには、様々な国の言語の理解を深めなければいけません。また、改行が現れるたびに、その前後の文字や単語の構成を確認する必要もあります。1つ目は、問題が大きすぎて、開発者個人では対応することができません。2つ目についても、変換速度を落としてまで対応するべき内容ではないと判断しました。
将来的には、この問題を解決するための仕組みが KARAS の標準的なコンバーターに実装される可能性があります。それはあらゆる環境下で十分な変換速度が得られると判断したときでしょう。一方で、この問題はブラウザ側で解決するべき問題ではないか、とも私は考えています。
メディアリンクの改行
メディアリンクの構文から出力される HTML はすべて改行されていません。例えば img 要素や video 要素です。これは、それらの要素がフローコンテンツ (ブロック) か、フレージングコンテンツ (インライン) にもなりえるからです。Webブラウザなどのユーザエージェントは、改行をわずかなスペースとしてレンダリングします。ユーザが連続して書いたメディアリンクに、コンバーターが勝手に改行を付けて、スペースを入れてしまうことは良くありません。例えば次のようなテキストです。
(((ImageURL-A)))
(((ImageURL-B)))(((ImageURL-A)))(((ImageURL-B)))Pattern-1 ではユーザが改行を書いているので、2つの要素の間にはブラウザがわずかなスペースをレンダリングします。一方で、ユーザがスペースをレンダリングしたくないときは、Pattern-2 のように書きます。このとき、コンバーターが改行を挿入してしまうと、ユーザが臨んだ結果とは異なる結果が出力されます。この問題のために、あらゆるリンクは改行されません。また param 要素などについても改行しません。いくつかの要素だけ改行されていると、気持ちが悪いでしょう。
リストの構文では改行していますが、これについては問題がありません。CSS などを使って横並びにするリストは、改行が原因の同じ問題を持っています。しかしながら、KARAS の構文では、リストを出力するための記号 - を行頭に書かなければいけません。横並びにするリストは、KARAS は書くことができませんから、改行は問題になりません。
pre, code, samp の中にある < と > は変換されない
KARAS の構文から出力される pre, code, samp 要素の中にある < と > は、それぞれ < と > に変換されます。しかしながら、ユーザが HTML として書いた pre, code, samp 要素のときは、それらは変換されません。これは、pre, code, samp 内のタグを有効にするためです。装飾や意味を持たせることを目的としたタグが挿入される可能性があるからです。