†BugTrack/38BugTrack/40BugTrack/69Wikiテキスト整形エンジンの仕様を考えよう書式についての再考察こんなところかしら。†ここでテスト状況を見ていただけるとありがたい。blockquoteの中以外はよさそうですね。reimyblockquoteの中もいい感じになりましたね。reimyいやいや、それが、まだまだなんですわ。kawaraとりあえず力技で解決できている模様。次はきちんとパースのアルゴリズムから考えよう...。kawara残るはブロック要素のプラグインの処理ですね。読み始めている段階でまだまだ先は長いです。10:19:53Wikiテキスト整形エンジンの仕様を考えようと書式についての再考察をあらためてじっくり読んでから思ったのが、Wikiテキスト指向か、それともHTML指向かで文章の論理構造をどこまで扱えるようにするかが若干変わってくるような気がしました。10:36:12とりあえず、現状では出来ることをあまり増やさず、簡素でいてHTMLの構文でこれはまずいだろうって部分を極力減らす方向がいいかと思ってます。10:37:00そうですね。Wikiの基本構文はこれ以上いじると敷居が高くなるので、このままで、機能拡張はプラグインとかで解決していくのが妥当かと思います。reimy(1)ブロック要素の次に別のブロック要素が現われたら確実に直前のブロック要素から脱出する。(2)空行は段落というブロック要素であり、別のブロック要素が現われるまでを<p>~</p>でくくる。空行の次の行にブロック要素がくる場合は、段落が空要素となるため、<p></p>となる。(3)したがって、ブロック要素の中に他のブロック要素を入れ子にはできないことは従来通り。(<ul>と<blockquote>は同種のブロック要素についてのネストは可能)(4)上記のブロック要素の中にはブロック要素として出力されるプラグインも含まれる。(5)<pre>の及ぶ範囲は先頭に空白文字がある行のみ、<blockquote>の及ぶ範囲は先頭に>がある行のみ。従来は空行が現われるまでを対象にしていたため、いろいろ弊害があった。(6)versionやcountのようなインライン要素として出力されるプラグインについてはブロック要素内に置かれるべきものであるから、seagullさんが指摘されていたように、行頭に#で始まるブロック要素として出力されるプラグインとは別の書式を考えるべき。基本的にインライン要素としてのプラグインはユーザー定義などと類似した扱いになる。(7)基本的に(5)(6)以外の書式は従来と変わらない。だいたいワタシがイメージしていたものと同じですね。纏まっていてありがたいです。15:36:34ブロック要素の中に他のブロック要素を入れたいというような要望は却下しましょう。書式が複雑になりすぎるし、利用度も低いだろうし。将来はともかく、今回は機能拡張ではなく、現状の不都合点を修正し、あいまいだった書式をすっきりさせるという観点でいいと思います。--reimy(1)blockquote要素の中には<p>と<blockquote>しか入らない。したがって他のブロック要素が現われた時点でblockquoteから抜ける。ブロック要素として出力されるプラグインが現われた場合も同様にblockquoteから抜ける。いう書式は認められないということ。空行は段落というブロック要素であり、子blockquoteが現われるかblockquoteの終了までを<p>~</p>でくくる。>だけの空行の次の行に子のblockquoteがくる場合は、段落が空要素となるため、<p></p>となる。(3)したがって、blockquoteの中に直接インライン要素が入ることはない。すべて子の<p>の中に入る。(4)blockquoteの中にはブロック要素として出力されるプラグインは含まれない。インライン要素として出力されるプラグインはblockquote内の<p>の中に入る。(5)基本的にblockquoteの出力が<blockquote><p>~</p></blockquote>のように<p>を含む形で出力されるようになるだけで、書式そのものに変更はない。以上、文章にすると一見複雑に見えるが実は非常に単純(笑い)う~ん、思った以上に大変だ。