BugTrack-plugin/357

拡張Wiki記法プラグイン

• 投稿者： あき（、A_M）
• カテゴリ： 新規
• 優先度： 低
• 状態： 提案
• 日時： 2007年10月13日 19時54分32秒

 内容

任意のWiki記法を利用可能にします。

FSWikiにはオリジナル機能としてイタリック、ボールド、打ち消し線、下線等のWiki記法が存在しますが、本プラグインを用いることによって、任意のWiki記法が利用できるようになります。

例として、

• 行末「<<」で左寄せ表示。
• 行頭「>」、行末「<」でセンタリング表示。
• 行頭「>>」で右寄せ表示。
• 「<br>」で改行。
• 「\n」で改行。
• 「\\n」で「\n」を表示。
• 「+○○+」で「○○」を拡大文字列として表示。
• 「++○○++」で「○○」を特大文字列として表示。
• 「!!○○!!」で「○○」を警告文字列（赤太字等）として表示。
• 「(red:○○)」で「○○」を赤字で表示。

といった表現が可能になります。

他の従来からある投稿系プラグインやパッチとの決定的な違いは、

• 記法の追加・編集が可能である。
• 記法がWiki記法そのものである。プラグインのそれ（中括弧２つで囲む）とは異なる。
• ページ編集者は、HTMLタグの知識がなくても表現豊かなページ編集が可能になる。

です。

いまいちうまくイメージできない方はこちらのサンプルサイトをご覧下さい。

 更新履歴

addwikiform_20071013.zip(793) 初版リリース。

addwikiform_20071015.zip(1616) 機能拡張。　←最新版

行書式（パラグラフ）と文字列書式（インライン）を個別に設定できるように対応。HTMLタグ構文訂正に対応。それぞれの機能をON/OFF切り替えられるように拡張。指定できる書式の個数を拡張できるように拡張。

 インストール方法

1. 各ディレクトリ（plugin,tmpl）をディレクトリごと対応するディレクトリにコピーして下さい。
2. 管理者メニューの『プラグイン設定』画面にてaddwikiformを有効にして下さい。
3. 必要に応じて、管理者メニューの『拡張Wiki記法の設定』画面にてWiki記法の編集や追加を行ってください。

 ライセンス

• GPL

 対応バージョン

• 3.6.2

 詳細

このプラグインは、非HTMLタグ装飾用プラグインや身勝手な装飾は許容したくないへの私なりの実質的な解答です。（構想から実現までに実に２年かかりました。単に何もしていなかっただけですが…）

FSWikiに対する表現力への物足りなさは、これで解決できると思います。

従来の文字装飾系プラグインでは、表現力豊かにページを編集するにはHTMLタグ等の知識が不可欠でした。また、それを使いこなせたとしても、『複数の人間でサイトを作り上げていく』というWiki本来の運用形態を考えた場合、個々の人間が個々の感性のままに様々な種類の装飾を使ってページを編集していってしまうと、サイト全体としての統一感が保てなくなっていってしまう危険性があります。（ってか、私はそれで苦労した人間の一人です）

そこで、予めサイト管理者が利用できる装飾の種類を目的別に決めておいてあげて、ページ編集者にはそれを目的に合わせて利用してもらう。という方法を考えました。

FSWikiオリジナルのテキスト修飾（イタリック、ボールド、打ち消し線、下線）には単なる見た目の違いだけでなく、利用目的という概念（意味）が存在します。

こういった意味合いで文字を装飾し、作成されたページ（ドキュメント）を構造化ドキュメントと呼びます。また、Wikiは本来こういったルールに基づいてページを作成していくものです。

FSWikiは、他のWikiと比べてこういった部分がより優れています。FSWikiのこういった利点を活かしつつ、表現力の豊かさと初心者に優しい実現方法を考えました。その答がこのプラグインです。

一度味をしめてしまうと、ないと不便を感じるようになると思います。

 コメント

• 大変有用なプラグインですね。早速使わせていただきました。行頭「>>」はメール文章を貼り付ける際、引用文で使っているため「->」に変更しましたが、問題なく動作しています。1点要望としては、例えば既存の「引用（""）」は""が終わるところまでblockquoteタグで囲まれ、１行ごとに<blockquote>（引用文１）</blockquote><blockquote>（引用文２）</blockquote>のようには出力されません。このプラグインでも左記のような出力方法に対応いただけたら、ちょっと幸せです。 - MRB (2007年10月14日 00時28分59秒)
• 本プラグインは、行単位、文字単位にしか対応していないので（というか、それしか無理）原則として行間を跨ぐ装飾は無理なのですが、<blockquote>タグを１行ごとに分けて出力したいだけでしたら、空行を挟みながら１行おきに記述してやれば大丈夫ですよ。行頭「""」のままで…。 - あき (2007年10月14日 00時44分55秒)
• 複数行をwiki書式だけでdivで囲めたら、装飾の面で楽だなぁ、、、とまぁ、そう思っただけです。そういうことは装飾用HTMLタグプラグインの領分ですね。 - MRB (2007年10月14日 11時18分53秒)
• あ、すみません。逆だったのですね。うーん。コメントしたとおり逆は無理なんですよね。強引な方法を使えば可能かもしれませんが、弊害も出てきそうなので躊躇してしまいますね。限定的になら可能かもしれませんが…できるかな？ - あき (2007年10月14日 12時13分21秒)
• 難しいっスねぇ。置き換えることは可能なんですが、それをどのように指定させるかっていうのも問題になってきますし、このプラグインが想定しているのは単一のブロック要素なんですよね。つまりその中にはインライン要素しか受け付けない…。ですが標準の<blockquote>タグ（つまり行頭「""」）は間にブロック要素（<p>タグ）を１行ごとに含みます。コレっていいのかな？　<p>タグ抜きで毎行改行（<br>タグ）でいい気がするんだけど…。そんなこんなで標準と動きが違ってくるんですよね。ちょっとこの辺りはHTMLの標準仕様に詳しい人でないと…。標準と合わせることは合わせられましたけど、合わせるとなるとこの場合、開始を「<blockquote><p>」、閉じを「</p></blockquote>」としなければなりません。妙ではありませんか？　<p>タグで囲む理由って何なんでしょう？　見栄えに関するプラグインを作成する際、いつもコレで悩まされてます。削除できるなら削除していいのかな？　ドキュメントの他のWikiとの比較のページでも、「ブロックレベルコンテナをpタグで囲んでしまうバグがある。」って書かれてますよね。うーん。作者に意図をお聞きしないと…。 - あき (2007年10月14日 13時14分28秒)
• MLにて聞いてみましたが、<P>タグで囲むのは特におかしくはないようですね。私の思い過ごしでした。引用なので複数段落を引用することも可能性としてありえました。ってことで、開始を「<blockquote><p>」、閉じを「</p></blockquote>」とするのは正しいのかもしれません。ただ、複数行になった場合どうするか、ですね。HTMLを作成した後で整形にて「</p></blockquote>\n<blockquote><p>」を「</p>\n<p>」に置き換えてやればできなくもないです。ただ、その指定をどうやってさせるか、が問題です。コレをサイト管理者にわざわざ設定してもらうのは酷な気がします。一つの案として、「</p>」と「<p>」の間に「</英字文字列>\n<左記と同じ英字文字列>」という文字列があった場合、その部分を「\n」に置き換える、ということで一応は可能ですが、強引過ぎないか？といった辺りが心配です。（ようは副作用が出ないか、といった辺り…）　しばし検証してみます。それから、ついでに昔A_M殿が提案されていたページに埋め込まれる無意味な要素を削除するについても実装してみようと思います。 - あき (2007年10月14日 22時08分41秒)
• 検証してみました。結論から言いますとダメですね。連続する行として書かれた場合と１行おきに書かれた場合の区別ができません。プラグイン側では間に空行があるか否かの判断ができず、どちらも連続する段落としてしか認識できません。元々、強引な整形な気もしてましたし、これに関しては残念させてさせて下さい。ページに埋め込まれる無意味な要素を削除するに関しては盛り込みます。 - あき (2007年10月15日 13時17分36秒)
• 対応しました。 - あき (2007年10月15日 19時11分24秒)
• 「見栄えに関するプラグイン」は、個人的に実装するのは自由としても、標準実装対象とすべきではないと思います。何故なら、HTML規格の趣旨に反します（他のWikiとの比較を見る限りHTML規格を重視する姿勢のようです）し、WIKIの構文にも適しているとは言い難いからです。だから、このプラグインの優先度は「低」とすべきだと思います。尚、「ブロックレベルコンテナをpタグで囲んでしまうバグ」とは、HTMLの文法規則でP要素内にブロック要素を入れることが出来ないことを指しています。また、StrictなHTMLではBLOCKQUOTE要素直下にはテキストを置けないので、P要素を使うのは適切な措置です。 - ryon (2007年10月25日 03時24分54秒)
• リリースから随分経つのですが、改めて使ってみました。たしかに「癖になりそう」ですね。ただ、任意に追加できる機能が標準実装には無用になるのかも知れませんね。FSWikiって、ryon氏も仰るように「他のWikiとの比較を見る限りHTML規格を重視する姿勢」（シンプルな実装で、そうなっているのだと思います）が気に入っているというユーザも多いと思うのです。Wikiの構文も含めて多くのユーザと議論を重ねて行けば、使いやすいものになるのではないでしょうか。 - A_M (2007年10月25日 18時08分46秒)
• ryon殿＞「標準実装対象とすべきではない」とは「CMS向け拡張パックとしての…」、ということでしょうか？　だとしたら、このプラグインにまだ改善の余地が残されているということだと思います。すみません。正直言うとまだ少し手抜きしてまして、本当はHTMLタグ内ではCLASS指定をさせて見栄えに関してはスタイルシートで指定させるつもりだったんです。ってか、そうしなきゃなぁと思いながらしてませんでした（横幅が広くなってしまうのを懸念して、とりあえず今の仕様に落ち着かせました）。それなら問題ないのでしょうか？　優先度に関しては、「すべき」という表現は語気が強すぎではありませんか？　優先度に関しては、作者本人の基準でつけるので宜しいんじゃないかといますし、私の基準は有用性と安全性を基準にしています。有用性はかなり高いと思いますし、安全性に関しても全く問題はないと思います。それから、「HTML規格の趣旨に反する」という部分がよく分かりません。それはサイト管理者次第なのでは？　HTMLに厳格か否かは、『詳細』の項にも記載してありますとおり、身勝手な装飾を避けるのが本プラグインの目的でありますし、その趣旨は他の装飾系プラグインと比較した場合、群を抜いてHTMLの趣旨に近いんじゃないかと自負しています。サンプルでは、HTMLタグの中ではありますが、装飾内容については一応style属性を使って指定しているつもりですし、文法を変更できるのも管理者のみとしてあり、かつ管理者にはHTMLやCSS、Perlの正規表現等について知識があることを前提としてあります。イマイチどの部分を懸念されているのかが理解できていなかったりします。私自身HTMLの規格にそれほど詳しいわけではありませんので、根本的に間違っている部分があるようでしたら、その部分に関してご教授を頂けると幸いです。意固地になるつもりはなく、認識を改めます。それとも、装飾自体がHTML規格の趣旨に反する、ということでしょうか？　だとしたら、もうどうしようもないですね。そういった場合は、装飾部分を全てOFFにして、『書式のエスケープ』と『構文訂正を行う』だけを有効にして使って頂ければ宜しいかと思います。それだけでも有用なプラグインだと思います。ってか、装飾系自体はCMS用途として不可欠な要素だと私は思うのですが…。BLOCKQUOTE要素の説明に関しては、ありがとうございます。なるほどです。私の最初の認識は完全に誤っていました。詳説ありがとうございました。 - あき (2007年10月26日 11時45分53秒)
• A_M殿＞任意に追加できる機能は無用ですか？　うーん。ですがCMS用途として使う場合、サイト毎のカラーを出したいですよね？　それとも、書式の追加や変更はできなくて、装飾内容をだけを変更できる仕様が望ましい、ということでしょうか？　それなら納得ですね。ただ、FSWikiは現状でもHikiやWakWiki、YukiWiki等の書式にも切り替えができるようになっています。こちらで書式を決めてしまうとなると、それらの書式ともかぶらないよう配慮する必要がありますし、今後も対応書式が増えるかもしれませんし、何より、一個人の独断と偏見で決めた固定のものを使ってもらうよりは、自由にカスタマイズして使ってもらうようにした方が便利なんじゃないかと思った次第です。書式の個数も当初は固定で考えてましたが、いくつくらいが妥当かも分かりませんし、ならば自由に増やせる方がいいのかな？と…。 - あき (2007年10月26日 12時07分58秒)
• FSWikiは動的なHTMLページを出力するものですので「書式の追加や変更」、「装飾内容」のどれもが、テーマ（CSS）に影響すると思います。やはり、オフィシャルな実装としては、重要度は低くても良いと思います。BugTrack-plugin/358（拙作）に関しても「CMSパックとして扱うのであれば重要度は高くあって欲しい。」と思います。これに似た感覚でしょうか。 - A_M (2007年10月26日 12時47分44秒)
• BugTrack-plugin/358は、それが標準仕様でもいいんじゃないかと思うくらい有用なパッチだと思うのですが…。（欠点はディスクを喰うというくらいな気が…）　『普通』ならまだしも『低』は控え目すぎでは？　なるほど、「オフィシャルな実装としては…」という考え方ですね。ですがオフィシャルな実装を基準にする必要はないのでは？　あくまでプラグインなわけですし…。ユーザが求めている判断基準は「どれだけ利用価値があるか？」だと思うのですが…。それとも、優先度って『標準仕様としての適切度』なんでしょうか？　小さなことなので討論するほどのことでもないですが、それでは有用なプラグインが埋もれて見えなくなってしまいかねません。ちょっと私にはその基準は同調できかねます。標準仕様としての適切度に関しては、注意書き、又は制限事項として書かれていれば良いだけではないのでしょうか？ - あき (2007年10月26日 13時57分54秒)
• たとえclass指定とCSSを分離しても「左寄せ」「センタリング」「右寄せ」「改行」「拡大」「特大」「赤字」と言った見栄えを表現目的とすることはHTML規格に反します。見栄え目的のclass指定をすることがHTML規格に反しているのであって、それは、詳細な書式をCSSに分離するかどうかとは別問題です。HTML規格では、赤字にする目的で<span class="red">文字列</span>とするのはナシです。それに対して、注意を促す意味を持たせて<span class="attention">文字列</span>として、それを赤字で表現するのはアリです。 - ryon (2007年11月01日 19時32分09秒)
• 優先度は、オフィシャルな実装の必要性を意味すると思います。オフィシャルな実装を前提としないなら公式サイトへの投稿を必要としないはずです。「万人にとって利用価値が高い＝標準仕様として適切」だからこそ、オフィシャルな実装の必要性があるのであって、優先度とオフィシャルな実装の必要性は、当然、連動するものであろうと思います。また、個人的に利用するかどうかの判断は、その内容を見て各個人で判断するものであって、優先度で判断するものではないはずです。 - ryon (2007年11月01日 19時48分21秒)
• もちろん「<span class="attention">文字列</span>」の意味です。このページの『詳細』の欄やサンプルにある各書式名をご覧頂ければ分かるかと思いますが…。（確かに、センタリングや改行は訳が違うのかもしれませんが…）　優先度に関しては、うーん、やっぱり同調できかねない。全ての説明に異論を挙げられてしまう。ですが、こんなことで揉めたくないので『低』にしておきます。「優先度なんてどうでもいいかな？」と思いますし…。 - あき (2007年11月02日 11時26分51秒)
• 提案です。次のような機能が追加されると嬉しい気がします。 - ぐうます (2007年11月02日 11時21分21秒)
  1. 現在設定されている拡張書式の使用例を表示するプラグイン ｛｛addwikiform_help｝｝ (例えば、サンプルサイトのような内容を自動生成)。このプラグインの想定使用例：Help のページに｛｛format_help｝｝に続けて記載。
  2. (1. ができればそれで代用でも可だと思いますが)管理メニュー「拡張 Wiki 記法の設定」のページにおいて、記法設定中に記法使用結果を確認できるプレビュー機能
  3. 各サイトでの使用において、拡張書式設定が固まった時点でその設定を集約サイト(たとえば作者さんのサイト)にアップロードできる機能。目的は、「各サイトごとに自由に設定できるとはいえ、多くのサイトで共通的に使用できる「書式→HTMLの対応」というものがあるはずであり、その共通項を見つけて本プラグインの初期設定にフィードバックを行う情報収集のため。」これによって標準から追加された書式についても共通化を図り、「書式が拡張できるのはいいけど、同じ FSWiki なのに書式が各サイトごとにてんでばらばらで訪問ユーザが書き込むときに戸惑ってしまう」というデメリットを低減する。また、あるサイトが設定した便利な設定がもしあったら、それを普及させることもできる。もちろん、アップロードは任意で、各サイトの管理者が希望した場合にボタンを押すとアップロードされるような仕組み。

• サンプルを見ても詳細を見てもFSWikiの標準実装機能以外はほとんど意味の定義が示されていません。そもそも、見栄えを先に論じていることがHTML規格に反しています。先に見栄えがあってそれに意味を当てはめるではありません。先に意味があってそれに見栄えを当てはめるのがHTMLです。また、CSSを使うなら、それぞれの意味にどんな見栄えを当てはめるかは、CSSで任意に定義することであって、CGIの機能として実装するものではありません。同じ意味でも、右寄せにするか、左寄せにするか、太字にするか、赤字にするか、大きくするか、小さくするかはCSSに委ねることです。そのためのCSSです。よって、HTML規格に沿ってCGIの機能を論じるなら、CSSのサンプルを示す以外に、見栄えの話が出てくるはずがないのです。ついでに言えば、意味を追加するなら、クラス定義より、HTMLで定義されている要素を追加するのが先でしょう。 - ryon (2007年11月06日 09時27分25秒)
• HTMLで定義されながらFSWikiで実装されてない要素には見出しレベル5,6,著者情報,引用句,上付,下付,定義用語,コード,サンプル,キーボード,変数,出典,略語,頭字語などがあります。 - ryon (2007年11月06日 09時43分39秒)
• うーん。一言で言って、残念という他ありません。本プラグインの仕様を理解せず、偏見で発言されていらっしゃるのか、このプラグインの趣旨や用途を全く理解して頂けていないのか…。サンプルはあくまでサンプルですし、初期値の書式もあくまで一例に過ぎません。詳細の欄を読んで頂いてこのプラグインが何を解決しようとして作成したプラグインなのか、どういったことを目的にしているのか考えて頂ければ、『意味合い』を前提としているということは十分にご理解頂けるはず。「装飾して表示できるようにする」のが目的ではありますが、その幹となる部分は『意味合い』です。数ある装飾系プラグインの中で、『意味合い』を幹としているのは本プラグインだけだと思います。ユーザが利用する際に指定するのは意味合いであって見栄えではありません。見栄えを指定できるのはユーザではなくサイト管理者です。ユーザが赤文字を意識して例えば『警告文字』という書式を使ったとしても、サイト管理者が『警告文字』に関する見栄えを朱色太字に変更してしまえば赤文字ではなくなってしまいます。CSSのそれと、方向性は合致しているつもりですが…。また、「HTMLで定義されている要素を追加するのが先」とのことですが、もし利用されたいのであれば、そういった書式を追加すれば良いだけです。本プラグインはそうやって利用して頂く事を前提としたプラグインです。「初期値として、そういった書式を定義しておいた方が良いのでは？」という提案でしたらもちろん前向きに検討させて頂きます。それから、「サンプルを見ても詳細を見てもFSWikiの標準実装機能以外はほとんど意味の定義が示されていません。」に関してですが、利用する書式はサイト管理者が定義するものであって、プラグインが管理している範疇ではないからです。「サンプルの書式名を見て頂ければご理解頂けるのでは？」といった意味でした。と言いますか、装飾自体が駄目だと言うことでしたら、上の方にもコメントしてますが、『書式のエスケープ』と『構文訂正』だけを利用されれば良いだけだと思います。それだけでも十分に利用価値のあるプラグインだと思います。それは、サイト管理者次第ですし、HTML規格に順ずるか否かも、サイト管理者次第ということになります。本プラグインはその窓口を提供しているだけにすぎません。ただ、コンセプトしては、ryonさんが仰っているようなCSSのそれと通ずるものがあると信じています。 - あき (2007年11月06日 13時33分09秒)
• おぉ！　こんなプラグインがあったんですね！（話しに割って入って申し訳ありません）　このプラグインはまだ使っていませんがWiki書式挿入編集ボタンなどのようなものがあるのでしょうか？　というのも、以前内輪でwikiでHPを作ったときに、ほとんどの人間が「新たにwiki書式を覚えるよりはまだタグのほうが一般的」みたいにいわれてしまい結局私一人のHPになったことがあるので・・・ｗ。ワードとかのツールバーアイコンじゃないですが、そういう風にそもそもwiki書式を覚えないですむなら、初心者も気軽に書き込めるのでしょうか？（アイコン同じであれば書式の仕様とかかわっても意識しないですみますし！？） - ふる・たいプ (2007年11月07日 23時14分04秒)
• ああ、よく見れば、意味を定義してる物もありますね。これは見落としていました。すみません。しかし、左寄せ、センタリング、右寄せ、改行、拡大文字列、特大文字列、赤字、こう言った物は明らかに意味が定義されていません。また、Wiki表記法からも、先に見栄えがあって、それに対して表記法をあてはめて、最後に意味付けを決めていることも読み取れます。クラス名より先に見栄えが決まっていることからも、それは明らかでしょう。本当に『意味合い』が幹であるならば、最初に、どのような『意味合い』が必要か、それにどんなクラス名を割り当てるのか、という検討が先にあるはずです。「装飾して表示できるようにする」のが目的の「装飾系プラグイン」であるならば、先に見栄えがあってそれに意味を当てはめているのであり、HTML規格の趣旨や「ユーザが利用する際に指定するのは意味合いであって見栄えではありません」と逆行します。以上のとおり、『意味合い』は後付けであり、幹とはなっていません。おそらく「先に見栄えを決めても、その見栄えに対応する意味付けを決めてしまえばHTML規格に沿っている」と誤解されているのだと思います。しかし、それは、本末転倒であり、HTML規格に沿っているとは言えません。本末転倒の弊害については長くなるので、説明を省略します。標準実装を目指すのであれば、HTML規格に沿うよう、根本から設計を見直すことをお勧めします。現状のままでは、ほぼ絶望的でしょう。また、使いたい人が使えば良いという姿勢であっても、「装飾系プラグイン」として追加する（＝HTML規格を無視する）なら、、中途半端に意味を定義したプラグインよりは、純粋かつ徹底的に見栄えを追求したプラグインの方が使いやすいはずです。HTML規格を重視する人なら初めから「装飾系プラグイン」は使わないはずでしょう。結局、どっちつかずになっているのでは？ - ryon (2007年11月08日 00時47分05秒)
• 意味付けについても詳細に見て行きましょう。「見出し」「説明」「争点」については意味が分かります。しかし、「ホット」が具体的に何を意味しているのかハッキリしません。「一大事」と「警告」、「気になる箇所」と「マーカー」は、それぞれ、どのように違うのでしょうか。一番分からないのは、「ノーマル」と地の文の違いです。組み合わせ事例に、「小さな見出し」に「ノーマル」を入れる事例がありますが、そもそも、こうした使い方はHTML規格に完全に反しています。「ノーマル」が見出しではないことを意味するなら、見出し要素の中に見出しではない物が存在することはHTML規格上許されていません。「ノーマル」が見出しではないことを意味しないなら、一体、「ノーマル」とは何がノーマルなのでしょうか。これらを見る限り、意味付けとしての必要性を検討して決めているのではなく、見栄えに合わせて無理矢理、意味付けを用意しているように見えます。これが、先ほど省略した本末転倒の弊害です。それに対して、HTMLで定義されている要素は、個々の利用者がそれを必要とするかどうかは別として、それなりに必要性が検討されて導入されている物です。本当に『意味合い』を幹であるならば、少なくとも、必要性を検討した上で意味付けを導入するはずです。であるならば、サンプルで示されたような微妙な意味付けよりも先に、必要性が検討された物を導入するでしょう。私が「HTMLで定義されている要素を追加するのが先」と言ったのは、そういった理由からです。もちろん、「W3Cなんざ、まだまだ甘いぜ。俺なら必要性をもっと掘り下げて検討して、W3Cよりずっと必要性の高い意味付けを考えてやる。」と仰るなら、独自の意味付けを導入しようとするのも分かります。しかし、そうした検討をした形跡が全く見られない以上、「HTMLで定義されている要素を追加するのが先」と言われるのは当然であろうと思います。 - ryon (2007年11月08日 01時12分46秒)
• 「Wiki表記法からも、先に見栄えがあって、それに対して表記法をあてはめて、最後に意味付けを決めていることも読み取れます。」＞違います。書式名（意味合い）→Wiki記法→HTML（装飾）の順です。設定画面はそうしてあります。それから、FSWiki標準の書式も『弱い強調』『強い強調』とは表現せず、『イタリック』『ボールド』という表現をしています。幹は『意味合い』のはずですが、ヘルプの説明は『見た目』となっています。 - あき (2007年11月08日 06時57分04秒)
• 「最初に、どのような『意味合い』が必要か、それにどんなクラス名を割り当てるのか、という検討が先にあるはずです。」＞それを決めるのがサイト管理者です。繰り返しますが、初期値やサンプルはあくまで一例です。 - あき (2007年11月08日 06時57分26秒)
• 「標準実装を目指すのであれば、HTML規格に沿うよう、根本から設計を見直すことをお勧めします。」＞最初のコメントにも書きましたが、この『標準実装』というものが何を指しているのかが分かりません。HTML規格準拠というものが改行やセンタリング表示が駄目だと仰るなら、そういったものは求めてません。このプラグインが求めているのは構造化ドキュメントと表現力、簡便さです。また、HTML規格準拠を目指すか否かはサイト管理者次第で本プラグインの範疇ではありません。 - あき (2007年11月08日 06時57分46秒)
• 「中途半端に意味を定義したプラグインよりは、純粋かつ徹底的に見栄えを追求したプラグインの方が使いやすいはずです。」＞そういった方は、そういったプラグインを使われば良いことです。本プラグインが解決しようとしている問題は他のプラグインには解決できない部分にあります。ターゲットとしているユーザ層も異なります。 - あき (2007年11月08日 06時57分57秒)
• 「意味付けについても詳細に見て行きましょう。…」＞ご指摘されている部分は本プラグインが管理する範疇ではないようです。繰り返しますが、本プラグインはその窓口を提供しているだけにすぎません。サンプルはあくまで一例にすぎません。 - あき (2007年11月08日 06時58分08秒)
• 「本当に『意味合い』を幹であるならば、少なくとも、必要性を検討した上で意味付けを導入するはずです。」＞何が必要かを検討するのはサイト管理者の仕事です。本プラグインの範疇ではありません。「ソフト（サンプル書式）の出来が悪いから…」と、ハード（プラグイン）を否定されているような気分です。「絶望的」等の言葉には悪意すら感じます。 - あき (2007年11月08日 06時58分19秒)
• 確かに難しい議論ですよね。ただ、ターゲットユーザの幅が広がるような議論ができれば良いのかなと思います。「HTML＋CSSをよく判っていない一般の方でも編集に幅を持たせることができる」という事なのですが、サンプルや書式の初期値次第では、FSWikiの公式サイトを利用する「HTML＋CSSを学び、WEB文書について知っている方」でも十分使えるようなプラグインになると思います。ぐうます 氏の仰るような、まずは意見交換できるような実装を目指してみるのも良いかも知れませんね。 - A_M (2007年11月08日 15時38分57秒)
• 左寄せにしたいから「<<」、右寄せにしたいから「>>」、センタリングにしたいから「>文字列<」、赤字にしたいから「(red:文字列)」と読めます。これらの表記法は、意味付けが先にあるのならば、どのような理由でこうした表記法を選んだのでしょうか。「設定画面はそうしてあります」「それを決めるのがサイト管理者」については、設定画面のサンプルや機能説明が見当たらないので、以下、想像で物を言います。たとえば、行末「<<」にどんなクラス名を割り付けるのか、サイト管理者が決められるということなのでしょうか。もし、そうならば、Wiki表記法の検討が甘いとしか言い様がありません。左寄せにするからこそ、行末「<<」が分かりやすいということで、その表記法を選んだはずです。しかし、サイト管理者によって、任意に意味付けと任意の見栄えが設定できるなら、そのような統一性のない表記法は混乱を招くだけです。本当に最初から任意に意味付けを想定した物であるならば、このような統一性のない表記法はありえないはずです。初めに見栄えありき、だから、このような表記法になったのではないですか？ - ryon (2007年11月08日 16時21分42秒)
• 「そういった方は、そういったプラグインを使われば良い」と仰るのであれば、論点がすり替わっています。「このプラグインは、非HTMLタグ装飾用プラグインや身勝手な装飾は許容したくないへの私なりの実質的な解答」「群を抜いてHTMLの趣旨に近いんじゃないかと自負しています」に対して、見栄え重視の人にとっては二度手間、HTML規格重視の人には問題が解決されてない、誰にとっても解答になってない、「群を抜いてHTMLの趣旨に近い」どころか、HTMLの趣旨に逆行しているという話をしているのです。 - ryon (2007年11月08日 16時23分25秒)
• 「設定画面はそうしてあります」という話を後から出して、「悪意すら感じます」と言われても困ります。説明すべきことを説明してなかったのだから、それは説明する方の落ち度では？そして、今なお、設定画面がどのようなものかの説明は為されていません。それによって意図するような議論にならなかったら、また、「悪意すら感じます」と言われるのでしょうか。 - ryon (2007年11月08日 16時37分01秒)
• 初期値の書式を差し替える機能は実装済みですので、書式だけを別途公開する場所を設けて、それを選択して使ってもらうっていうのは現バージョンのままでも可能です。（ryon殿が理想だと仰っている範囲のパターンだけをHTML規格準拠パターンとして提供するすることも可能です）　サイトテーマやサイトテンプレートのように複数の複数のパターンの中から選択できる機能を設けると良いかもしれませんね。　ぐうます殿の仰るヘルプ自動生成案に関しては、実は途中まで実装を試みていました。まだ断片的にそのコードが残っています。ただ、難しいんですよね。サイト管理者にヘルプとなる文章を同時に考えて頂く様にしないといけない。それは「１００歩譲って納得してもらうしかないな」と思えたのですが、それを指定できる欄を設けたところ１書式につき２段の構成とせざるをえなくなって設定画面の見栄えが一気に悪くなる。「このままじゃいけないなぁ」と思ってとりあえず残念しました。その代わりと言ってはなんですが、『Wiki書式挿入編集ボタンとの連動』というのは考えています。ただ、それもこのプラグインだけでは解決できる問題ではないのでどうしたものかと…。 - あき (2007年11月08日 17時43分28秒)
• 「任意に意味付けと任意の見栄えが設定できるなら、そのような統一性のない表記法は混乱を招くだけです。」＞はい。任意に意味付けと見栄えが設定できます。「混乱を招く」の混乱をする人とは誰を指してますでしょうか？　書式はサイト毎に閉じられた設定となりますので、そのサイト内であれば誰が使っても共通の書式、共通の見栄えとなります。「サイト毎に異なるのが混乱の元」ということでしたら、改善の余地はあると思います。個人的にはそれがサイト毎のカラーだと思い設計しましたが、他の方の意見を聞いても、どうやらそうではないようです。 - あき (2007年11月08日 17時43分46秒)
• 「これらの表記法は、意味付けが先にあるのならば、どのような理由でこうした表記法を選んだのでしょうか。」＞当プラグインのコンセプトとは、関係のない話ですよね？　初期値兼サンプル書式の話題ということで議論をさせてもらってもよろしいですか？　ご指摘のとおりです。Wikiソースを見た時に整形後の形が連想できるようにです。ただ、それは標準の『打ち消し線』や『下線』等も同様ですよね？ - あき (2007年11月08日 17時44分00秒)
• 「栄え重視の人にとっては二度手間、HTML規格重視の人には問題が解決されてない、誰にとっても解答になってない」＞結論が強引過ぎます。強いて言うなら、そのどちらも対象ではありません。 - あき (2007年11月08日 17時44分10秒)
• 「説明すべきことを説明してなかったのだから、それは説明する方の落ち度では？」＞了解しました。説明が至らなかったのだと思います。申し訳ございません。コンセプトと初期値兼サンプル書式の間に大きな隔たりがあったことを認めます。今後の改善事項として考えます。ただ、見栄えに関するプラグインですので、HTML規格準拠を謳ったプラグインでないことはご承知おきください。規格に準拠することが、改行やセンタリング表示を禁止することに繋がるなら、それはこのプラグインの目指す所ではありません。コンセプトは構造化ドキュメントであり、構造化ドキュメントのそれは、HTMLのCSSの考えに通ずるものがあると述べているだけです。 - あき (2007年11月08日 17時44分18秒)
• 「今なお、設定画面がどのようなものかの説明は為されていません。」＞私が気付きの悪い人間だからなのかもしれませんが、個人的にはその必要性を感じません。使って頂ければ分かることですし、使い方は自由ですので、「可能な限り、HTML規格準拠で利用しましょう」と宣言するのも「何だかなぁ」という気がしています。 - あき (2007年11月08日 17時44分27秒)
• 「また、「悪意すら感じます」と言われるのでしょうか。」＞攻撃的な（語気の強い）文章でなければそうは感じません。今回の文章は大丈夫でした。 - あき (2007年11月08日 17時46分14秒)
• この手の議論は昔から繰り返される不毛なものだ。どのみち「HTMLを厳格に適用することを要求する人」は、他とは相容れない。「規定が全て」であり、それを破る可能性のあるものは容認しない(使う人の選択にゆだねるべきではないと主張するのだから)。「見栄えを目的としたHTML記述は良くない」というのが、そもそも現実から乖離しているのに、その現実に目を向けられない。それが駄目な理由は「規定に反しているから」というしか言わないし言えない。「意味合いを持たせるのなら良い」といっても、普通にページを見ている人に、それは伝わらない(ソースを見ない限り)のだから、ただの自己満足だ。それでも「規格に従っているから正しい」とそれしか言わないし、その考えを変える気などさらさらないだろう。仮に規定が「見栄えについても記述してよい」といえば、容認するだろう・・・その程度のことだ。俺自身はこのプラグインを便利に使わせてもらっているので、不毛な議論で心が折られるようなことが無いことを祈りたい。 - リアス (2007年11月09日 01時54分40秒)
• HTML＋CSSの規則で言うと悪いのだけども、コードの規則に拘っていない人には使いやすい。一長一短あるプラグインなんですよね。設定も自由が利くため、テーマを作成する人は、このプラグインをサポート出来ないと思います。そこで、このプラグインを活用する際、どのような設定をすれば、より規則正しいマークアップに近づく(テーマのデザインもし易くなる)のか。論点を切り替えることによって、建設的な意見が増えそうに思います。 - A_M (2007年11月09日 06時55分11秒)
• なるほど、「使う人の選択にゆだねるべきではない」という考えですね。コンセプト云々の話ではなく…。コンセプトが近いのに『逆行』という言葉を使われた時には、さすがに拒絶を意図しているとさえ感じました。コンセプトが近いか否かではなく、規格を100%厳守できるか、が焦点なわけですね。分かる気がします。確かに私が目指しているものはそれではないです。規格厳守が表現力の豊かさを阻害することに繋がるなら（例えば「改行が駄目」とかなら）、それは私が目指している方向ではありません。ですがとてもありがたいことです。こうやってご指摘を頂くことで、見えていなかった（見ようとしても見えなかった）問題点がどんどん見えてきますので…。 - あき (2007年11月09日 12時14分12秒)
• 「設定も自由が利くため、テーマを作成する人は、このプラグインをサポート出来ないと思います。」＞ご指摘を否定したいわけではないのですが、ここでいう『テーマを作成する人』とはサイト管理者のことですよね？次の言葉を見る限り…。ですが設定を行うのもサイト管理者なわけで通常は同一人物だと思うのです。サイトテーマとサイトテンプレートを同時にカスタマイズしていくように、本プラグインの設定も同時にカスタマイズして頂く。（CSSの一部のような感じで…） そういった運用方法を思い描いているのですが…。 - あき (2007年11月09日 12時30分50秒)
• 「そこで、このプラグインを活用する際…」＞そうですね。そういった方向に考えていくのは大切だと思います。強制とかではなく、ガイドラインのようなものですね。 - あき (2007年11月09日 12時31分01秒)
• 「使って頂ければ分かる」から説明する必要がないという論理であれば、内容、詳細、サンプルサイトも全く不要なはずです。「使って頂ければ分かる」のではないですか？ハード（プラグイン）の説明を一切せずにソフト（サンプル書式）の説明だけしておいて、「ソフト（サンプル書式）の出来が悪い」から「ハード（プラグイン）を否定されている」と言うのは、完全な逆ギレですね。説明した部分に評価が集中するのは、当然のことです。「偏見」だの「悪意すら感じます」だの言った以上、キチンと説明すべきでしょう。説明しないならば、言い掛かりで非難したことを素直に認めるべきです。 - ryon (2007年11月09日 21時07分01秒)
• 「規格に準拠することが、改行やセンタリング表示を禁止することに繋がる」ことはあり得ません。「規格厳守が表現力の豊かさを阻害することに繋がる」こともあり得ません。HTMLは改行やセンタリング表示を禁止していません。そうした見栄えが先にあることがHTML規格に反しているのであって、先に意味付けがあるなら、その意味付けに見栄えを設定することは何らHTML規格に反しません。このプラグインは見栄えが先にあるからHTML規格に反しているのです。 - ryon (2007年11月09日 21時07分49秒)
• 標準の『打ち消し線』や『下線』とは、実際には、del要素やins要素として実装されています。標準のCSSでもdel要素やins要素のスタイルは指定されていません。よって、これらが必ずdel要素やins要素として意味付けされるのに対して、表示方法が『打ち消し線』や『下線』となることは保証されていません。ヘルプの記述の方が不正確なのであって、実際には、見栄えではなく削除や挿入の意味付けとして実装されている物です。また、打消線は、事実上、削除以外の意味で使うと混乱を招きますし、削除を意味する見栄えとしても打消線以上に適切な表現方法がありません。挿入＝下線も多くのブラウザで採用されている表現方法です。よって、これらの実装は、このプラグインとは思想が根本的に違う物です。 - ryon (2007年11月09日 21時08分21秒)
• 任意に意味付けと任意の見栄えの設定を許容すると言うことは、実際には右寄せになるのに行末「<<」という設定も許容すると言うことです。それは混乱を招きます。そういう設定をする奴が悪いと言うなら、任意設定可能なように見せ掛けて、事実上、見栄えを固定しているのと同じです。「Wikiソースを見た時に整形後の形が連想できるように」が理由であるならば、行末「<<」は右左寄せ以外に使えないわけであり、事実上の見栄えの固定ですね。 - ryon (2007年11月09日 21時09分00秒)
• ブロック要素とインライン要素がごっちゃになっているために、ネスティング時にインライン要素内にブロック要素内が入ることを許容してしまうという致命的なバグもあります。そもそも、これは、元々のWiki表記法がブロック要素（行頭に制御文字）かインライン要素（対象文字列の前後に制御文字）かで書き方を変えていることを考慮せず、目的とする見栄えだけを元に表記法を決めていることによって生じる問題です。よって、このプラグインでは、「HTML規格準拠パターン」なるものは実現できません。 - ryon (2007年11月09日 21時10分26秒)
• あと、どのような設定方法となっているか（＝ハードの機能）によっては、更なる問題も発生し得ます。設定画面の詳細が説明されないなら、それ以上の言及は出来ませんが、説明を省略した部分こそがHTML規格にとって最も重要な部分です。それを説明されないなら、HTML準拠と言う看板は外されるべきでしょう。 - ryon (2007年11月09日 21時11分15秒)
• 私が変態なのかもしれませんが、行末「<<」は右寄せかな（右の空白を消す、という感じ）と思い、実際そのように設定してみましたが、しっくりきてます。ですので、サンプルの例がいまいちなのかなとは思いますが（私の実感と合わない）、見栄えを固定しているとは思いません。設定が変えられる点がいいですね。 - 名無しさん (2007年11月09日 23時04分43秒)
• 「「使って頂ければ分かる」から説明する必要がないという論理であれば、内容、詳細、サンプルサイトも全く不要なはずです。」＞毎度のことですが、極論すぎると、ご自身ではお気付きになりませんか？　「使って頂ければ分かる」というのは意味合いが先か、見栄えが先か、という話題についてです。『詳細』の欄に説明してるはずですが、それでも「逆だ」と仰るので「設定画面を見て頂けていれば意味合いが先であることが分かるはず」といったことを述べたまでです。 - あき (2007年11月09日 23時30分26秒)
• 「ハード（プラグイン）の説明を一切せずにソフト（サンプル書式）の説明だけしておいて…」＞ハード（プラグイン）の説明もしてあります。 - あき (2007年11月09日 23時30分34秒)
• 「このプラグインは見栄えが先にあるからHTML規格に反しているのです。」＞何度も申し上げてますが、見栄えが先にあるつもりはありません。本当に、実物を見て発言されていらっしゃいますか？それとも、見栄えに関するプラグインだからそう見えるのでしょうか？見栄えが先にあるか、意味付けが先にあるかは実際に使って頂ければ（設定画面を見て頂ければ）分かることだと思いますし、詳細の欄にも意味付けによる装飾だということは説明してあるつもりです。たとえ詳細の欄の説明が不足だったにせよ、これだけ誤解を解くための説明を繰り返しているのだからかげん理解できるのでは？ - あき (2007年11月09日 23時30分43秒)
• 「標準の『打ち消し線』や『下線』とは、…」＞Wiki記法についての話です。「=」２つや「_」２つで囲むというスタイルは整形後の見た目を連想させるものだという意味で例に挙げさせて頂きました。行頭「>>」、行末「<<」等も同様だということです。 - あき (2007年11月09日 23時30分53秒)
• 「これらが必ずdel要素やins要素として意味付けされるのに対して、表示方法が『打ち消し線』や『下線』となることは保証されていません。」＞本プラグインもこの原理は同じです。ユーザが指定できるのは意味付けであって装飾ではありません。この説明も２度目になりますが、ユーザが固定の見栄えを意識して使用しても、サイト管理者がその書式に対応する見栄えを変更してしまえば装飾内容も変わります。つまりユーザが指定できるのは意味合いであって装飾内容ではないということです。 - あき (2007年11月09日 23時31分00秒)
• 「ヘルプの記述の方が不正確なのであって、実際には、見栄えではなく削除や挿入の意味付けとして実装されている物です。」＞仰るとおりです。私もそのことについて述べました。本プラグインの説明も、ベースは意味づけだけれども説明の記述は見栄えの方になってしまっている、と申し上げたまでです。「標準の説明と同じでしょう？」と…。 - あき (2007年11月09日 23時31分08秒)
• 「打消線は、事実上、削除以外の意味で使うと混乱を招きますし、削除を意味する見栄えとしても打消線以上に適切な表現方法がありません。」＞本プラグインも同様です。 - あき (2007年11月09日 23時31分16秒)
• 「任意に意味付けと任意の見栄えの設定を許容すると言うことは、実際には右寄せになるのに行末「<<」という設定も許容すると言うことです。それは混乱を招きます。」＞はい、許容しています。繰り返しますが、混乱するのは誰なのでしょうか？　また、そういった設定するのは誰でしょうか？（次に続く…） - あき (2007年11月09日 23時31分23秒)
• 「そういう設定をする奴が悪いと言うなら、任意設定可能なように見せ掛けて、事実上、見栄えを固定しているのと同じです。」＞見せ掛けでなく事実許容しています。「設定をする奴が悪い」というより、あえて好き好んでそういった設定をする人もいないでしょう？　FSWiki標準の『打ち消し線』や『下線』等もWiki記法（「=」２つや「_」２つ）が逆さになったりすると混乱しませんか？　事実、そういった設定にすることも可能です。ですがそんな設定にする変わり者も実際問題居ないでしょうし、それならば行末「<<」を右寄せと関連付けるサイト管理者もいないでしょう。同じことではありませんか？ - あき (2007年11月09日 23時31分34秒)
• 「元々のWiki表記法がブロック要素（行頭に制御文字）かインライン要素（対象文字列の前後に制御文字）かで書き方を変えていることを考慮せず…」＞考慮してあります。事実に反する発言は不愉快です。 - あき (2007年11月09日 23時31分42秒)
• 「よって、このプラグインでは、「HTML規格準拠パターン」なるものは実現できません。」＞本当に（コメントの）説明を読んで頂けてますか？ - あき (2007年11月09日 23時31分50秒)
• 「HTML準拠と言う看板は外されるべきでしょう。」＞そういった看板を掲げているつもりはありません。更新履歴に書いた『HTMLタグ構文訂正に対応』のことでしょうか？ - あき (2007年11月09日 23時31分57秒)
• このプラグインの目的は、「文書構造と体裁とを簡単に実現したい」と認識しています、また、多くの利用者が使いやすいとも感じているはずです。ただ、現状のHTMLの要素を出力できてしまう点など、インライン要素内にブロック要素が入れることも出来たり、SPAN要素がネストされたりと、検討すべき点もあると思います。もし、このプラグインが「簡単な装飾記号の入力」で任意の箇所(パーサが出力する任意の要素)にclass属性(またはstyle属性)を埋め込む事ができるようになると、真の意味で見栄えだけを埋め込める優れたプラグインになるとも感じます。 - A_M (2007年11月10日 00時55分10秒)
• 現在の私のFSWikiカスタマイズ例としまして、Parser.pmとHTMLParser.pmとを弄り、「コメント行処理に『//CSS:(class)』を書いておくと、以降、コメント行が来るまで、各要素にclass属性を埋め込む」ようにしています。こうすると、人名でも「署名」になる部分は class="sign"（画面上では「右寄せ」表示）と、特定のP要素にだけclassを与えることが出来、構造と体裁とを切り分けた結果を得られます。私の方法だと、パラグラフの出力単位でしか意味付けできないんですよね。 - A_M (2007年11月10日 00時56分53秒)
• 『HTMLタグ構文訂正』は私が公開した強引な不要タグ除去法ですが、回避するための方法として、NULLを返すプラグインの設計方法（WIKI記法出力で「\n//\n」を返す）や、HTMLParserに若干の修正を加えるなどがあります。 - A_M (2007年11月10日 01時06分02秒)
• すいません。行末「<<」が右寄せと感じる（そしてそう設定する）のはそんなに変ですかねえ……。自由ですよねえ……。 - 名無しさん (2007年11月10日 01時58分39秒)
• ついでに。どうでもいいことしか書いてない私が書くのも何ですが、HTMLがどうしたこうしたとかは別のページに書いて、このページにはそこへのリンクだけ書いておくことにしませんか。 - 名無しさん (2007年11月10日 02時09分40秒)
• はい、自由です。FSWiki内でも『大見出し』『中見出し』『小見出し』は、行頭『!!!』『!!』『!』ではなく『!』『!!』『!!!』の方が他の書式と統一が取れてて良いんじゃないかといった議論も出たことがありました。が、そういったのも含めてFSWikiのカラーです。自由です。変更もできます。行末『<<』を例に挙げたのはちょっと不適切だったかもしれません。 - あき (2007年11月10日 02時14分18秒)
• 「HTMLがどうしたこうしたとかは別のページに書いて、このページにはそこへのリンクだけ書いておくことにしませんか。」＞本プラグインに関する話題ですので、個人的にはここでいい気がするのですが…。HTML規格準拠云々の話に関しては、私もここで討論する必要はないと思いますが、このプラグインに対しての指摘である以上、ここで解答すべきなのかな、と思います。純粋に「HTML規格準拠とは何ぞや？」という話題でしたら、ここでの討論は不適切ですね。コメントの欄を２つに分けるとかはいいかも知れませんね。 - あき (2007年11月10日 02時25分36秒)
• 補足になりますが、先ほどの発言で下線部分は、HTML入力を認めるシステム（ブログなど）に採用されたWYSIWYGエディタのやってることそのものだと思います。〜余談ですが、プラグインのページですので「このプラグインを活かすためにどうするか」を論点とするのがふさわしいと思います。 - A_M (2007年11月10日 02時29分11秒)
• みんなに非難囂々で、行末「」を右寄せに設定するのはやめようかなと思い始めました（みんなこんな指定使わないくせに）。で、設定を変えよう（==行末「」かな==）と思っているのですが、まさに、この、設定を変えられる点が利点なんですよね？自らの感触と異なる設定をせざるを得ないこともあって、「事実上、見栄えを固定しているのと同じ」というご意見には大きな違和感があります。 - 名無しさん (2007年11月10日 11時24分21秒)
• 行末「<<」は右左寄せかなと言うなら、それは見栄えが先にある考えです。それを「しっくりきてます」と思うのは、見栄えが先にあるからです。「右左寄せと感じる」のは、見栄えが先にあるからです。ここで議論していることは、行末「<<」を右左寄せと感じることが妥当かどうかではなく、そう感じることを理由にして、つまり、見栄えを基準にして考えることがHTML規格に反しているということです。 - ryon (2007年11月10日 19時19分21秒)
• 意味合いが幹であり、HTML準拠となるかどうかがサイト管理者次第と言うなら、ハードとは設定機能そのものであり、ソフトとはどのような設定をするかとなります。設定の具体例は重点的に説明されていますが、設定機能については全く説明されていません。つまり、ハードに関する説明はありません。いくつかの実装方法は想像可能ですが、そのどの方法をとっているのか、あるいは、それ以外の方法をとっているのか、説明がないので全く分かりません。そして、それこそが、HTML準拠とする選択が可能となるかどうかの分かれ目となります。「設定画面を見て頂ければ」と言っている以上、ハードを評価するために設定画面を見る必要があると自認しているのであり、「ハード（プラグイン）の説明もしてあります」とする発言と矛盾します。ちなみに、サンプルを見る限りでは、HTMLを誤って理解されている様子であり、HTML準拠とする選択が不可能な方法をとっているのだろうと推測できます。 - ryon (2007年11月10日 19時19分38秒)
• どちらも「整形後の見た目を連想させる」ことは、両者の同一性の説明になっていません。9日21時08分21秒でも説明したとおり、削除や挿入は見栄えと意味付けがほぼ一体化している事例であり、それは見栄えと意味付けが一体化していない事例には当てはまりません。「本プラグインも同様」と仰るなら、右寄せや左寄せを連想させる一体化した意味付けとは何ですか？そのような意味付けがあるなら、初めから、右寄せや左寄せとは言わず、その意味付けを前面に出して説明すれば良いのではないですか？わざわざ、「このプラグインとは思想が根本的に違う」と強調表示してあるはずです。どうして、相手の主張の主たる部分を無視するのですか？ - ryon (2007年11月10日 19時19分56秒)
• FSWikiの標準機能は明らかにHTML準拠となっています。だから、ヘルプが間違ってるだけです。しかし、このプラグインの行末「<<」等は明らかにHTMLに反しています。両者は全く違います。これも9日21時09分00秒、同日 21時10分26秒やそれ以前の発言でしつこく説明してきたことです。どうして、相手の主張の主たる部分を無視する'''のですか？それとも、本当に説明の間違いであって、行末「<<」等は書いてあるけど使えないと仰るのでしょうか？ - ryon (2007年11月10日 19時20分15秒)
• 「あえて好き好んでそういった設定をする人もいない」と言うなら、事実上、許容していないですね。私が9日21時08分21秒で指摘したことそのままです。 - ryon (2007年11月10日 19時20分38秒)
• ブロック要素やインライン要素を「考慮してあります」、考慮してないとするのが「事実に反する」と仰るなら、「$$」で囲むとh5（ブロック要素）、「%%%」で囲むとh6（ブロック要素）となるのは、何故ですか？行末に制御記号を置くのは、ブロック要素（行頭）やインライン要素（文字列両端）とどのように違うのですか？ - ryon (2007年11月10日 19時20分59秒)
• HTML準拠を拒絶されるなら、「文書構造と体裁とを簡単に実現したい」という看板は正しくありません。「体裁を簡単に実現したい」が適当でしょう。 - ryon (2007年11月10日 19時21分26秒)
• あき氏はHTMLを間違って理解されているのだと思います。だから、Validであれば十分であると思っているのでしょう。確かに、このプラグインでValidと体裁を両立することは可能でしょう。しかし、HTML規格に沿うならStrictであることが求められます。Validに留まることは、Strictへ移行するための一時的措置として認められているのであって、最終的にはStrictを目指すことが前提となります。FSWikiのDOCTYPE宣言はTransitionalとなっているものの、blockquote要素直下にテキストを置かずにp要素を入れていることは、紛れもなくStrictを目指している証拠です。このプラグインは設計思想の段階からStrictではない故に、Strictな利用には適しない部分があります。そして、現時点では示されてない機能の詳細を検討すれば、Strictな利用には適しない部分が他にもあることが疑われます。「文書構造」を実現すると言うなら、Strictな利用が可能でなければなりません。 - ryon (2007年11月10日 19時39分12秒)
• なるほど。「事実上、見栄えを固定しているのと同じ」ことが問題なのではなく「見栄えが先にある考え」それ自体が問題であると。どうも私は周りと感覚が異なるようで、いろいろ言われてイヤになって、行末「>>」とか「<<」で右寄せする指定は削除してしまいました（どうせ使わないし）。HTMLに準拠してるかどうかは管理者である私にとって（たぶん利用者にとっても）重要ではなく、簡潔なWiki書式の字面と見栄えがしっくりくるかどうかの方がよほど重要です（これが変だと言われてへこんだ）。まあ、結果としてHTML準拠であればそれはそれでよいことだろうとは思いますので、プラグイン制作者サイドで建設的な議論がなされることを、一利用者として、期待します。 - 名無しさん (2007年11月10日 19時57分08秒)
• まだ試験運用の段階ですが、次のようなガイドラインだと、HTML準拠に近い運用も出来るのではないでしょうか。 - A_M (2007年11月10日 22時14分57秒)
  1. 他の実装機能(見出し毎に編集する機能など)を損なわないように既存の要素でも簡単にclass属性を埋め込めるように設定。
  2. style属性は使わない ― HTMLを全く修正せずに複数のテーマに対応することが出来なくなるため。
  3. 見出しの要素にはclassも使わない ― outlineプラグインや、見出し毎の編集機能が活かせないため。
  4. 文脈に合う意味合いの英単語をclass属性として記述し、グループ化の意味で活用する。
  5. ブロック要素では記号の付与を行頭で統一し、インライン要素では該当文の前後に ― 標準のFSWiki記法に統一しています。

• インライン要素に簡単な記号でclass付けできるのは便利に思いますが、ブロック要素では弱い気もします。以前、コメントさせていただいた、コメント行を利用した記述を行うと、見出しを囲った時に見出し編集の画面に表示されないなどの欠点もありますので、このプラグインで補うことが出来れば…と思います。- A_M (追記)
• ryon氏のWEBページを拝見したが、 氏の このプラグインに対するコメントを見る限り、やるつもりは無いと御本人が言っている「規格の押し付け」をしているに過ぎない。大事なのは「してはいけないことの詮索」ではなく「なにをするべきなのかの指摘」ではないのか？ HTMLなどの思想がどんなに良いものだとしても、こんな風にコメントされてしまっては、その良さが何も伝わらない。・・だから「不毛な議論」だ。こんな風な指摘をする人間ばかりが喜んで使う規格など、糞食らえだ。本当に「正しいHTML」を広めたいと ryon氏が微塵でも感じているのなら、ここでのコメント方法を もっと考えた方が良いのではないか？ 偉そうに規格を押し付けることが、そんなに楽しいのか？ その規格の目的がきちんと伝わらなくてもいいのか？ - リアス (2007年11月11日 18時32分14秒)
• 一部訂正。「Validに留まることは、Strictへ移行するための一時的措置」ではなくて、Transitionalに留まることが一時的措置。ValidであることはStrictであるための必要条件であって十分条件ではない。DOCTYPE宣言がTransitionalでマークアップがStrictになることは許されても、DOCTYPE宣言がStrictでマークアップが非Strictは許されない。どちらもStrict以下という意味でTransitionalとValidに共通点があるが、イコールではない。ちょっと混同してました。FSWikiがStrict指向であること、このプラグインの設計思想がStrictでないことは間違っていません。 - ryon (2007年11月11日 20時07分47秒)
• ここでは「簡潔なWiki書式の字面と見栄えがしっくりくるかどうか」が重要であるかどうかは論じていません。「見栄えが先にある考え」をしてはいけないとは誰も言っていません。論じているのは、それがHTML規格準拠どころか逆行しているということであり、HTML規格準拠という認識が正しくないということです。だから、現状のこのプラグインについては「文書構造と体裁とを簡単に実現」ではなく「体裁だけを簡単に実現」と言うべき、という話です。「見栄えが先にある考え」がいけないのではなく、それをHTML規格準拠と言うのが間違っているということです。根本的な部分での認識が間違っているのです。 - ryon (2007年11月11日 20時18分16秒)
• 認識が正されて初めて、HTML規格準拠にするのか否かという選択の段階に入れます。HTML規格準拠にする意思がないのであれば、どうぞ、このままひっそり続けてください。決して、HTML規格準拠などとは言わないでください。HTML規格に逆行しているとハッキリ言ってください。もし、HTML規格準拠にする意思があるなら、何らかのアドバイスをすることもできます。その場合は、まず、現状のプラグインの機能の主要部分の説明が必要です。 - ryon (2007年11月11日 20時21分55秒)
• いや、プラグインの機能の主要部分の説明も何も、言い方は悪いですが（あきさんごめんなさい）、これ、HTMLParserをちょろっと拡張して外部からWiki書式を与えられるようにしただけですよね？ - 名無しさん (2007年11月11日 21時17分32秒)
• HTMLParserじゃなくてParserの方をいじくった方がいいような気もします。ぱっと見の印象なんで外してたらすいません。 - 名無しさん (2007年11月11日 21時20分07秒)
• 「行末「<<」は左寄せかなと言うなら、それは見栄えが先にある考えです。」＞うーん。何故そちらに視点が向いてしまうのでしょう？　では、『打ち消し線』や『下線』が「=」２つ、「_」２つなのは何故でしょうか？　整形後の形が連想できるからではありませんか？　また、行末「<<」が左寄せ等に関しては、（繰り返しになりますが）これらはあくまでサンプルです。プラグインのコンセプトとサンプルの間に大きな隔たりがあったことは既に認めたとおりです。これらの議論をされても、私には「ソフト（サンプル）が駄目だからハード（プラグイン）も駄目」と仰っているようにしか聞こえません。 - あき (2007年11月11日 21時28分46秒)
• 「意味合いが幹であり、HTML準拠となるかどうかがサイト管理者次第と言うなら、ハードとは設定機能そのものであり、ソフトとはどのような設定をするかとなります。」＞その通りです。 - あき (2007年11月11日 21時28分55秒)
• 「設定の具体例は重点的に説明されていますが、設定機能については全く説明されていません。」＞なるほど、設定機能についてですね。そうですね。確かに設定機能については説明してませんし、「見れば分かるでしょう」と考えています。（設定画面自体にも多少の説明はありますし…）　私が「説明している」と申し上げたのは、今回の議論の中心になっている意味合いが幹か見栄えが幹かという部分（本プラグインのコンセプトの部分）に関してです。 - あき (2007年11月11日 21時29分02秒)
• 「…そして、それこそが、HTML準拠とする選択が可能となるかどうかの分かれ目となります。」＞この結論に繋がる理由が分かりません。HTML準拠となるパターンだけを選んで利用すればHTML準拠になるはずです。「そうならない」と仰るなら、それはどういったケースなのかをお聞かせ下さい。私が気付いていない部分でそういった部分もあるのかもしれません。 - あき (2007年11月11日 21時29分09秒)
• 「「設定画面を見て頂ければ」と言っている以上、ハードを評価するために設定画面を見る必要があると自認しているのであり…」＞違います。コンセプトに関しては詳細の欄でも説明してあるつもりです。が、それでも「分らない」と仰るので、ならば「設定画面を見て頂ければ…」と述べたまでです。 - あき (2007年11月11日 21時29分17秒)
• 「サンプルを見る限りでは、HTMLを誤って理解されている様子であり、HTML準拠とする選択が不可能な方法をとっているのだろうと推測できます。」＞前半の「HTMLを誤って理解」に関してはそういった認識で結構です。冒頭の方のコメントでも述べてますが、私はHTML規格に対して博識なわけではありません。が、後半の「HTML準拠とする選択が不可能」というのは意味が分かりません。可能だと思っています。 - あき (2007年11月11日 21時29分24秒)
• 「「本プラグインも同様」と仰るなら、右寄せや左寄せを連想させる一体化した意味付けとは何ですか？」＞これは、揚げ足を取るのが目的の質問ですか？　プラグインのコンセプトとサンプルの間に大きな隔たりがあったことは既に認めたとおりです。そもそも、私はサンプルの書式がHTML規格に準拠しているとは主張していません。これで３度目になりますが「ユーザが固定の見栄えを意識して使用しても、サイト管理者がその書式に対応する見栄えを変更してしまえば装飾内容も変わります。つまりユーザが指定できるのは意味合いであって装飾内容ではないということです。」の部分は読んで頂けてますか？見栄えが幹ならこういった仕様は説明つかないでしょう。 - あき (2007年11月11日 21時29分31秒)
• 「削除や挿入は見栄えと意味付けがほぼ一体化している事例であり、それは見栄えと意味付けが一体化していない事例には当てはまりません。」＞一体化も何も関係ないでしょう？「記法から整形後の形が連想できる」と言ったら「それは見栄えから来ている」と言うので、同様なものを挙げたまでです。「ヘルプの説明が間違っている」とか、「これは別」とか、そういった返し方をされては会話になりません。「理論に反する」とのことでしたので、「それは標準でも同じようなのがありますよ」と指摘させて頂いたまでです。例外的な話をされるなら、逆にサンプルにある『マーカー』に関して、『見栄えが先（見栄えを固定している）』という観点からの説明ができますか？　おそらく、こういった辺りの議論を始めると、全ての書式について説明し尽くさない限り、収まりがつかなくなるでしょう。不毛な議論です。 - あき (2007年11月11日 21時29分37秒)
• 「どうして、相手の主張の主たる部分を無視するのですか？」＞無視も何も、その主たる部分というものがサンプルに対してであってプラグインに対してではないからです。プラグインの管理する範疇ではないからです。（これでこの文句は５度目です） - あき (2007年11月11日 21時29分45秒)
• 「「あえて好き好んでそういった設定をする人もいない」と言うなら、事実上、許容していないですね。」＞意味が分かりません。許容してます。考えや感じ方は人それぞれですので、好みで良いと思っています。好み通りにカスタマイズして利用できるところが、本プラグインのウリでもあります。「自由だけれども、あえて混乱を招くような設定を施す人は居ないでしょう」ということを言ったのです。 - あき (2007年11月11日 21時29分52秒)
• 「行末に制御記号を置くのは、ブロック要素（行頭）やインライン要素（文字列両端）とどのように違うのですか？」＞ブロック要素の中にはインライン要素を含められますが、その逆はできません。これは本体の仕様と同じです。かつ、インライン要素同士はネストが可能です（こちらは本体は3.6.3以降からの仕様）。行末に制御記号を置いたのはサンプルとして一例を示しただけで、行頭だけに制御記号を置くパターンも指定できます。 - あき (2007年11月11日 21時29分59秒)
• 「HTML準拠を拒絶されるなら、「文書構造と体裁とを簡単に実現したい」という看板は正しくありません。」＞極論ですね。拒絶しているわけではありません。拒絶しているなら、こういった議論に耳を傾けるようなこともしないでしょう。「HTML＋CSSが目指す『構造化ドキュメント』という方向性は同じつもりだけれども、『準拠』を目的にしているわけではない」と言っているのです。 - あき (2007年11月11日 21時30分31秒)
• 「あき氏はHTMLを間違って理解されているのだと思います。…」＞この辺りのご指摘は、だいたいはご指摘の通りだと思います。ただ、最後の一文「「文書構造」を実現すると言うなら、Strictな利用が可能でなければなりません。」については、可能だと思っています。そういったパターンだけを選んで使用すれば良いだけだと思います。「不可だ」と仰るなら、それはどういった部分なのかをお聞かせ下さい。まだ私には気付いていない部分があるのかもしれません。 - あき (2007年11月11日 21時30分40秒)
• 「「見栄えが先にある考え」をしてはいけないとは誰も言っていません。」＞ご自身の発言を振り返られてみてください。 - あき (2007年11月11日 22時21分28秒)
• 「論じているのは、それがHTML規格準拠どころか逆行しているということであり、…」＞『不完全』と言うなら分かりますが、『逆行』というのは未だに分かりません。他の装飾プラグインと比べ、その逆行している（遠ざかっている）部分とはどういった辺りでしょう？ - あき (2007年11月11日 22時21分39秒)
• 「「見栄えが先にある考え」がいけないのではなく、それをHTML規格準拠と言うのが間違っているということです。」＞HTML規格準拠を謳っているつもりはありません。 ryon殿の、単なる思い込みではありませんか？ - あき (2007年11月11日 22時21分48秒)
• 「認識が正されて初めて、HTML規格準拠にするのか否かという選択の段階に入れます。」＞意味が分かりません。どういった理論で考えるとそうなるのでしょう？ - あき (2007年11月11日 22時21分55秒)
• 「これ、HTMLParserをちょろっと拡張して外部からWiki書式を与えられるようにしただけですよね？」＞インライン書式のネストを許容するのが大変でしたので『ちょろっと』といった感じではありませんが、まあ、だいたいはそんな感じです。 - あき (2007年11月11日 22時42分48秒)
• 「HTMLParserじゃなくてParserの方をいじくった方がいいような気もします。」＞いえ、出力するものがHTMLですので、Parser側では無理です。標準書式についてもHTMLParser側で変換されています。Parser側ですと、PDF等での出力も考慮しなければなりません。 - あき (2007年11月11日 22時42分58秒)
• ちょろっと、とは失礼しました。言いたかったのは、単純なロジックで実装されていて、行末に>>とかどうとかは本質じゃない、ということでした。機能の説明も何も、説明することはあまりないというか。Parserの方を、と書いたのは、もしかして、一番下で強引に新しい書式に対応するのはつらいのかな、と思いまして。変換じゃなくて、振り分け（というかどのl_*を呼ぶか）を決めてるところに新しい書式を追加できればシンプルなのかな、と思いました。失礼しました。 - 名無しさん (2007年11月12日 00時39分21秒)
• 「言いたかったのは、単純なロジックで実装されていて、行末に>>とかどうとかは本質じゃない、ということでした。機能の説明も何も、説明することはあまりないというか。」＞そうですね。仰るとおりです。 - あき (2007年11月12日 18時03分30秒)
• 「変換じゃなくて、振り分け（というかどのl_*を呼ぶか）を決めてるところに新しい書式を追加できればシンプルなのかな、と思いました。」＞任意のパターンを直接ソースコードに追加するなら（パッチ形式なら）、それが最も簡単ですね。もちろんそのようにしたとしても、HTMLへの変換部分は別途作成する必要はありますが…。メソッドをオーバーライドするようにすれば、パッチでありながらプラグイン形式にすることも可能ですが、本体のバージョンが上がるとそれに追従してプラグイン側も対応しなければならなくなるので、可能な限りそれは避けたかったのです。 - あき (2007年11月12日 18時03分39秒)
• 私が、いつ、「見栄えが先にある考え」をしてはいけないと言ったのでしょうか。「群を抜いてHTMLの趣旨に近いんじゃないかと自負しています」「『意味合い』を前提としている」「その幹となる部分は『意味合い』です」「違います。書式名（意味合い）→Wiki記法→HTML（装飾）の順です」「コンセプトは構造化ドキュメントであり、構造化ドキュメントのそれは、HTMLのCSSの考えに通ずるものがある」「HTML＋CSSが目指す『構造化ドキュメント』という方向性は同じつもり」これらは、全てあき氏自身が宣言したことであって、私が強要したわけではありません。いつ、私がそうしろと強要したのでしょうか。あき氏が「『意味合い』を前提としている」と言い張るから、それは完全に見栄えが先にある考えであると指摘しているだけです。「コンセプト」についてHTMLの誤認があると言ってるのです。そして、その誤認は設計画面に反映されているはずです。 - ryon (2007年11月12日 19時32分08秒)
• 「見れば分かるでしょう」なら、ソフトの機能も「見れば分かるでしょう」ではないのですか？そもそも、「意味合いが幹か見栄えが幹かという部分」について、ハードの機能を検証する必要性を主張したのはあき氏の方です。だったら、それを説明せずして、「意味合いが幹」だと言い張るするのは、自己認識を押しつけているだけではないのですか。思うとか思わないとか言い合うのは議論ではありません。何故そう思うのかを説明を交換することが議論です。本当に「意味合いが幹」であるなら、ハードの機能を説明して、「意味合いが幹」であることを示せば良いだけですよね。そうした説明をやり取りすることが議論なのではないですか。どうして、それをしないのですか。 - ryon (2007年11月12日 19時32分20秒)
• 行末「<<」は単に「ソフト（サンプル）」の問題ではありません。これは、「プラグインのコンセプト」で行末に制御文字を置くことを可能としているから実現できているのであり、これは「ソフト（サンプル）」による使用例ではなく、「ハード（プラグイン）」の機能です。「意味合いが幹」であるなら、「ハード（プラグイン）」の機能として行末に制御文字を置く機能はないはずであり、機能にないことは「ソフト（サンプル）」では実現できません。「ソフト（サンプル）」で実現できるのは、「ハード（プラグイン）」がそのような設計になっているからです。それと同様の問題の有無が、設定画面を見ることによって知り得ます。少なくとも、これまでの説明からは、他に同様の問題があるかどうかは分かりません。 - ryon (2007年11月12日 19時32分33秒)
• ブロック要素とインライン要素の違いは質問していません。行末に制御記号を置くことが、ブロック要素やインライン要素とどう違うのかと聞いているのです。ブロック要素やインライン要素とも違う第三の書式記述法を必要とする理由は何ですか。そう聞いているのです。ブロック要素やインライン要素であるなら、第三の記述法は必要ありません。見栄えのために第三の記述法を導入しているのだから、要素の区別のために表記法を変えているFSWikiの標準機能とは全く違います。 - ryon (2007年11月12日 19時32分46秒)
• 『打ち消し線』や『下線』については、9日21時08分21秒および10日19時19分56秒にて、表面上は似ていても根本的な違いがあることは説明済みであり、全く「同様」ではありません。その根本的な違いを説明されても無視し、表面的な類似点にしか着目しないのは、不毛な議論ではないのですか。 - ryon (2007年11月12日 19時33分03秒)
• あき氏がStrictだと思っているのは単なるValidに過ぎません。確かに「そういったパターンだけを選んで使用すれば」Validは実現可能でしょう。しかし、それはValidであってStrictではないのです。あき氏はStrictが何なのか理解されてない。Strict=HTML準拠であって、Valid=HTML準拠ではないのです。設計思想として見栄えが先にある時点で既にアンチStrict=アンチHTMLなのです。あき氏が、これまでの発言を撤回して、アンチStrict=アンチHTML路線を進むと主張するなら、議論はここで終わりです。今までの路線がアンチStrict=アンチHTMLであることを認めない、もしくは、Strict=HTML準拠に方向転換すると仰るなら議論は続きます。 - ryon (2007年11月12日 19時33分16秒)
• 「根本的に間違っている部分があるようでしたら、その部分に関してご教授を頂けると幸いです」これもあき氏の言葉です。 - ryon (2007年11月12日 19時39分27秒)
• HTMLに関して厳密な知識で臨むと ryon氏 の仰る通りです。VaildなHTML、StrictなHTMLの良さの一つは、様々なテーマに対応できる点。ブラウザを選ばなくて済むなど、メリットの方が非常に大きいものです。単に規則としてあるだけでなく、仕様が定まり、各ブラウザが対応してきた今日、テーマ作成においてもメリットの方が優っています。私自身も最初のコメントでは相当迷いましたが、「利用者がHTMLを知らなくても…」というコンセプトのWikiですので「正しいマークアップに自動修正される、より良い使い方」を提案し、必要な箇所から修正を働きかけるのが遠回りだけども早いと思います。実際、最初に指摘した任意に設定できる機能ですが、class 属性の追加機能であれば幾つでも欲しい。とさえ感じます。 - A_M (2007年11月12日 21時50分59秒)
• ryon殿：「そもそも、「意味合いが幹か見栄えが幹かという部分」について、ハードの機能を検証する必要性を主張したのはあき氏の方です。」＞主張？本当に説明を読んで頂けてますか？コンセプトに関しては詳細の欄を読んで頂ければそれだけでも理解可能なはずです。それでも「違う」と仰るから、「本当にそういった造りになっているのかどうかは設定画面を見て頂ければ分かるはず」と追記したまでです。にも関わらず、サンプルの欠点を題材にプラグインを批判されているのです。 - あき (2007年11月12日 22時04分03秒)
• ryon殿：「それを説明せずして、「意味合いが幹」だと言い張るするのは、自己認識を押しつけているだけではないのですか。」＞押し付けも何も、このプラグインを作成したのは私です。どういった思想でこのプラグインを作成したかは私自身が一番良く知っています。ryon殿がいくら「意味合いが幹でない」と仰っても、作者は意味合いを幹に発想し、作成したのです。 - あき (2007年11月12日 22時04分32秒)
• ryon殿：「ハードの機能を説明して、「意味合いが幹」であることを示せば良いだけですよね。」＞ですから、設定画面は書式名（意味合い）→Wiki記法→HTML（装飾）の順となっています。 - あき (2007年11月12日 22時04分40秒)
• ryon殿：「「プラグインのコンセプト」で行末に制御文字を置くことを可能としているから実現できているのであり…」＞なるほど、「行末に…」の部分を仰っていたのですね。確かに、FSWikiでは行書式は行頭側だけかもしれません。本プラグインでそれを可能にしたのは、グローバルなWiki記法（Wiki記法標準化プロジェクト、和訳）を意識してのことです。数あるWikiクローンの中には、行頭＋行末セットで目的の書式を示すものもあります。そういったものにも対応できるように、との配慮です。 - あき (2007年11月12日 22時04分48秒)
• ryon殿：「「意味合いが幹」であるなら、「ハード（プラグイン）」の機能として行末に制御文字を置く機能はないはずであり…」＞かなり強引な理論ですね。行末に制御文字が置けてしまうと意味合いが幹でなくなってしまうのですか？柔軟な記法が指定できるよう幅を持たせているだけであって、「どちらが幹か？」ということとは全く関係のない話です。 - あき (2007年11月12日 22時04分56秒)
• ryon殿：「…少なくとも、これまでの説明からは、他に同様の問題があるかどうかは分かりません。」＞未だに問題であるという認識になれません。自由度が広いだけだと思います。 - あき (2007年11月12日 22時05分04秒)
• ryon殿：「その根本的な違いを説明されても無視し、表面的な類似点にしか着目しないのは、不毛な議論ではないのですか。」＞表面的な部分にしか着目して頂けていないのは、ryon殿の方ではありませんか？　整形後の形が連想できることを理由にWiki記法を考えるのは見栄えが幹だと仰るから、同様に整形後の形が連想できる標準のWiki記法の例を挙げさせて頂いたまでです。どちらも、そのWiki記法を選んだのは整形後の形が連想できるからであり、それは意味合いが幹か見栄えが幹かといったコンセプトの部分とは全く関係のない話です。表面的な類似点にしか着目していないのではなく、質問されたことに対して答えたまでです。表面的なことですので当初は答えるつもりはありませんでしたが、「どうして、相手の主張の主たる部分を無視するのですか？」とのことでしたので、しぶしぶ答えたまでです。 - あき (2007年11月12日 22時05分11秒)
• ryon殿：「確かに「そういったパターンだけを選んで使用すれば」Validは実現可能でしょう。」＞最初からそのようにしか言っておりません。「HTML規格準拠としても使える」としか…。 - あき (2007年11月12日 22時05分18秒)
• ryon殿：「設計思想として見栄えが先にある時点で既にアンチStrict=アンチHTMLなのです。」＞かなり強引な理論としかいいようがありません。本プラグインは柔軟な表現を可能にするための窓口であり、HTML規格準拠として利用するか否かはサイト管理者の自由です。極力規格に沿った運用ができるよう、ガイドラインを設けたり、標準的な書式について議論する場を設けてサンプルを共有し合ったり、といったことなら考えますが、HTML規格準拠を厳守するために柔軟性を犠牲にしたプラグインへと変化させていくつもりはありません。 - あき (2007年11月12日 22時05分25秒)
• 補足ですが、class付けする際に、記号の選び方は難しいですね。コアのParserが3文字までを認識する仕様に合わせているからでしょうか。 - A_M (2007年11月12日 22時05分58秒)
• 自分で書いた分を一部訂正。意味を考えたら<span class="attention">はstrictじゃないね。strictなら<strong class="attention">じゃないと。何らかの意味があって見栄えを派手にする場合はstrongかemくらいしか選択する余地がなさそう。 - ryon (2007年11月13日 20時46分52秒)
• 「どういった思想でこのプラグインを作成したか」を作者が知ってて当然です。誰も、あき氏が自分の思想を熟知しているかどうかは問うていません。問うているのは、その思想がHTMLに合致しているかどうかです。あき氏は、その思想がHTMLに反していることを理解していない。あき氏が、どんなに自分の思想を熟知していても、HTMLを知らないのでは、HTMLに沿っているかどうか自己検証できるわけがありません。HTMLを知らない思想からは、HTMLに沿った物は作れません。 - ryon (2007年11月13日 20時47分19秒)
• 行末「<<」等は、「書式名（意味合い）→Wiki記法→HTML（装飾）の順」となっていない事例を示しています。合理的必要性もないのに統一性に欠けた書式とするのは、混乱を招くだけで、柔軟な記法でも何でもありません。その必要性が見栄えのためなら、「書式名（意味合い）→Wiki記法」ではないですよね。 - ryon (2007年11月13日 20時48分42秒)
• Wiki記法標準化プロジェクトには「行頭＋行末セットで目的の書式を示す」記法はないようです。ブロック要素で行末にも制御記号を置くのは見出しのみのようですが、そこには「閉じる（右側の）等号は任意」と書かれており、サンプルを見ても書式は行頭のみで表されています。行末の制御記号は書式を閉じる目的で使われており（必要性には疑問あり）、書式を表すための制御記号は行末に用いられていません。閉じるための制御記号を設ける理由は明らかではないけれど、複数行に渡った記述を可能にするため、将来拡張して何らの属性指定できるようにするため、等の理由が考えられますが、少なくとも、行末で書式を示すような目的には使われていません。 - ryon (2007年11月13日 20時48分59秒)
• 見栄えが意味合いと一体化しているなら、見栄えを連想することは意味合いを連想することと等価です。一体化していないなら、見栄えを連想しても意味合いを連想することになりません。両者は、結果として、意味合いを連想することなるかどうか１８０度違います。よって、「意味合いが幹か見栄えが幹かといったコンセプトの部分」と密接に関わる問題です。書式設定後の意味合いが連想できることが重要なのであって、「整形後の形が連想できる」かどうかはHTML規格的にはオマケでしかありません。本体（意味合いが連想できるかどうか）の類似性を論じているのに、オマケの部分が同じだと言い張るのでは、表面的な類似点にしか着目していませんね。 - ryon (2007年11月13日 20時49分48秒)
• ValidはHTML規格準拠ではありません。HTML規格準拠にするつもりがないなら、次の発言を全て撤回してください。「群を抜いてHTMLの趣旨に近いんじゃないかと自負しています」「『意味合い』を前提としている」「その幹となる部分は『意味合い』です」「違います。書式名（意味合い）→Wiki記法→HTML（装飾）の順です」「コンセプトは構造化ドキュメントであり、構造化ドキュメントのそれは、HTMLのCSSの考えに通ずるものがある」「HTML＋CSSが目指す『構造化ドキュメント』という方向性は同じつもり」これらを撤回すれば話は終わると前にも言ったはずです。 - ryon (2007年11月13日 20時50分34秒)
• ついでながら、重要なので言っておくと、FSWiki標準の削除や挿入については、インライン要素の書式記法まで変えたりはしていません。他のインライン要素と同じ書式記法規則を用いています。その点が、行末「<<」とは全く違います。行末「<<」は、見栄えのために書式記法規則まで変えてしまっているのであり、単に制御記号として使う文字に何を使うか等の些細な問題とはレベルが違います。 - ryon (2007年11月13日 20時58分02秒)
• ryon殿：いくら議論をしても終わらないと思います。ご自由に解釈してください。こういった議論を続けていても肝心の開発が滞るだけですし、他のユーザの方々にとっても迷惑でしょう。優先度の件もそうですが、ユーザにとっては使えるか否かが重要なのであって、HTML規格準拠か否かは殆どのユーザにとっては興味の無い話だと思います。私自身、本プラグインをHTML規格準拠とは謳ってませんし、「HTML規格準拠としても使える」ならそれで十分だと思っています。むしろこれだけ攻撃的な口調で規格云々で叩かれてしまうと、かえって規格準拠では実現できない機能を目玉にしたくもなってきました。（自由度を「必要性が無い」と切り捨てる考えには、唖然としました）　今後、提供する書式パターンの検討やガイドラインについて考えていきたいと思います。文言の撤回については、その必要性は無いと考えています。人それぞれ、感じ方や考え方が異なりますので、納得のできない人にその考えを押し付けるつもりはありません。また逆に、撤回を強要される問題でもないと思います。 - あき (2007年11月14日 00時30分22秒)
• 単に「辛口コメント」でもないと思いましたので「要点」を引き出しますと、プラグインを利用する上で、ブロック要素の記号を行頭のみで済ませられるというのは、一考すべき点だとおもいます。Wikiの編集画面でも行単位で記述できる（むしろ、行末を強制されない）からこそ、ブロック要素を記述しやすいのかな。私もWiki記法での「ブロック要素に閉じる記号」は面倒なだけだと思います。また、運用管理する立場の方が、単に汎用要素(DIV、SPAN)を使うのではなく、できるだけEM要素、STRONG要素など、意味づけされた要素を利用するのが望ましい事を意識できると、より良い使い方も広まると思います（ガイドライン作成の際には必要な内容と思います）。 - A_M (2007年11月14日 02時25分09秒)
• ぐうます殿：ヘルプページの自動生成については、何らか形で実現したいと思います。書式の標準化については、目的別にいくつかのパターンから選んで利用できる手段を提案していきたいと思っています。標準書式についての、議論の場も設けていきたいと思っています。 - あき (2007年11月14日 02時41分49秒)
• ryon殿：見出しレベル5,6,著者情報,引用句,上付,下付,定義用語,コード,サンプル,キーボード,変数,出典,略語,頭字語についても、可能なものについてはパターンに加えようと思います。 - あき (2007年11月14日 02時42分06秒)
• ふる・たいプ殿：いずれ必要になってくるだろうとは考えています。ただ、異なるプラグインですので実装をどのようにしようかな、と…。こちらのプラグインで新規パターンを追加すれば、それに連動してWiki書式挿入編集ボタン側にも追加される、というのが理想ですが、現実的にはかなり大変ですね。カスタマイズ済み版のリリースなら可能だと思います。 - あき (2007年11月14日 02時42分17秒)
• リアス殿：励ましのお言葉ありがとうございます。ただ、ryon殿のご指摘が自己満足であるとは思ってません。規格に準拠したプラグインを公の場にて提供することは、万人にとってのメリットになることは理解しています。理解できなかったのは、「HTML＋CSSの趣旨に逆行する」と言われたことと、「規格に準拠した運用ができない」と切り捨てられたことです。確かに、費用対効果を重視した場合、規格に準拠せず見た目ありきで突き進んだ方がメリットがあったりもしますよね？　その双方のタイプのユーザ（サイト管理者）に、提供できるプラグインが実現できたら、と思っています。 - あき (2007年11月14日 02時42分27秒)
• A_M殿：「HTML＋CSSの規則で言うと悪いのだけども…」＞いまいち、何処がまずいのかが分らないんですよね。「サンプル書式が…」ではなくて、プラグイン的に問題がありますか？　このプラグインで指定する見栄えの部分は、FSWikiの管理画面で言うと、『テーマ』の部分ではなく『ユーザ定義スタイル』側と等価だと思うんですよね。サイトテーマとは関係なく、個々のマークアップを装飾しますので…。 - あき (2007年11月14日 02時42分35秒)
• A_M殿：「ただ、現状のHTMLの要素を出力できてしまう点など、インライン要素内にブロック要素が入れることも出来たり、SPAN要素がネストされたりと、検討すべき点もあると思います。」＞インライン要素内にブロック要素は入れられない造りなのですが…、出力結果として指定できるHTMLについてでしょうか？　確かにそういったチェックは行ってませんね。全てのタグをチェックするとチェックロジックでプラグイン自体が肥大化してしまいますので、そういった辺りはサイト管理者に一任したいな、と…。それから、SPAN要素って、ネストが駄目なんですね。知りませんでした。確かに、「必要か？」と問われれば不要な気もしますが…。 - あき (2007年11月14日 02時42分43秒)
• A_M殿：「「簡単な装飾記号の入力」で任意の箇所(パーサが出力する任意の要素)にclass属性(またはstyle属性)を埋め込む事ができるようになると…」＞うーん。装飾だけを目的とするなら、そうですね。ただ、本プラグインは任意のWiki記法を利用可能にするプラグインですので、作成するとしたら別プラグインとしての作成になるでしょうか？　本プラグインと同じような仕組みで、実現できそうな気はしますね。 - あき (2007年11月14日 02時42分51秒)
• A_M殿：「現在の私のFSWikiカスタマイズ例としまして…」＞ご紹介ありがとうございます。この案の延長で、何かできそうではあります。 - あき (2007年11月14日 02時43分00秒)
• A_M殿：「まだ試験運用の段階ですが、次のようなガイドラインだと、HTML準拠に近い運用も出来るのではないでしょうか。」＞ご提案ありがとうございます。一読しただけでは（思想は良くても設定時の利便性を考え場合）同感できない部分があります。再度改めで熟読し、検討させて頂きます。と言いますか、議論の場を設けられれば、と思います。 - あき (2007年11月14日 02時43分09秒)
• リアス殿：「本当に「正しいHTML」を広めたいと ryon氏が微塵でも感じているのなら、ここでのコメント方法を もっと考えた方が良いのではないか？」「その規格の目的がきちんと伝わらなくてもいいのか？ 」＞そうですね。こういった攻撃的な文章では、せっかくの立派な思想も歪んで伝わってしまいます。「そんなふうに言われるなら、もうどうでもいいや」とさえ思ってしまいます。良い所も指摘して下さっているのに、揚げ足を取るのが目的ともとれるような発言が多くて、そういった部分は残念です。 - あき (2007年11月14日 02時43分17秒)
• A_M殿：「補足ですが、class付けする際に、記号の選び方は難しいですね。コアのParserが3文字までを認識する仕様に合わせているからでしょうか。」＞これは、このプラグインに対する質問ですか？　３文字までとかは制限はしていません。質問が理解できておりませんが、「指定しても思ったように動作しない」とかでしたら、優先順位の問題とかではないでしょうか？ - あき (2007年11月14日 02時43分27秒)
• A_M殿：「ブロック要素の記号を行頭のみで済ませられるというのは、一考すべき点だとおもいます。」＞利点は理解できます。そのように設定もできますので、それに合わせた方が理想的、ということでしたら、標準ではそのようにしたいと思います。ただ、自由度の広さを否定されたのは納得できませんでした。 - あき (2007年11月14日 02時55分55秒)
• A_M殿：「また、運用管理する立場の方が、単に汎用要素(DIV、SPAN)を使うのではなく、できるだけEM要素、STRONG要素など、意味づけされた要素を利用するのが望ましい事を意識できると、より良い使い方も広まると思います（ガイドライン作成の際には必要な内容と思います）。 」＞そうですね。これは感じてました。 - あき (2007年11月14日 02時56分07秒)
• 議論が有るべき方向(「ガイドラインは必要&議論の場を設けよう」という方向)に進んでいますので問題ないのですが、「HTML＋CSSの規則で言うと悪いのだけども」、「インライン要素内にブロック要素は入れられない造り」と指摘したのは、インライン書式の設定項目に、DIV要素などを記憶できる仕様だからです。こういうイレギュラーな内容も自由に設定もできる仕様ですので、諸刃の剣になっています。ただし、管理者が留意すべき事であって、プラグイン側のチェックロジックは不要だと思います。 - A_M (2007年11月14日 06時17分40秒)
• サンプルの修正意図については高く評価します。完全なStrictとはならなくても、少しはStrictに近づくことができるでしょうか。たとえ不完全であっても、Strictに近づこうとする行為は評価されて然るべきと思います^[1]。サンプルの件について口出しするなら、まず、左寄せ、センタライン、右寄せ等を残すなら、これらには何らかの意味付けを用意し、左寄せ、センタライン、右寄せと説明するのではなく、その意味付けを説明すべきでしょう。重要な小見出し(h5)、小さな見出し(h6)がインライン要素の書式記法で表されているので、これはブロック要素の書式記法とすべきであろうと思います^[2]。ホット、一大事、警告、争点、気になる箇所、マーカーは、全て、強調を意図したものであり、強調するニュアンスの違いであるのだから、全てspanではなくstrongかemを使うべきであろうと思われます^[3]。 - ryon (2007年11月15日 19時53分04秒)
• 13日20時50分34秒に並べた「殆どのユーザにとっては興味の無い話」をしたのは他ならぬあき氏です。これらは「感じ方や考え方」の違いではありません。明確な間違いです。感じ方や考え方を強要しているのではありません。HTML規格を誤認しているから、それは間違いだと言ってるだけです。HTML規格を正しく理解したうえで、その規格をどう扱うかは感じ方や考え方の問題です。「HTML規格なんざ糞食らえ」と言うのも個人の自由です。しかし、HTML規格を誤認するのは、感じ方や考え方の問題ではありません。HTML規格を正しく認識するかどうかは会話の前提であり、前提が成り立たないのでは会話も成立しません。 - ryon (2007年11月15日 19時53分44秒)
• 「ブロック要素に閉じる記号」の必要性は、このプラグインの議論から脱線しています。少なくとも、これまでの説明内容から見て、このプラグインに実装されているのは行末書式指定であって^[4]、「ブロック要素に閉じる記号」は実装されていないと考えられます。敢えて脱線を承知で言わせてもらうなら、「ブロック要素に閉じる記号」はHTML規格準拠に極めて有用です^[5]。 - ryon (2007年11月15日 19時54分07秒)
• これまでの説明から見て、このプラグインには「行末書式指定」は実装されてないと思いますが……。 - 名無しさん (2007年11月15日 21時28分50秒)
• いや、けどよく考えると、「パラグラフ」の方の片側だけ指定すると行末指定になるので「行末書式指定」も実装されてると言えば言えるのか……。 - 名無しさん (2007年11月15日 21時38分50秒)
• さらによく考えると、指定できるWiki書式は何でもありなので、少なくとも「ブロックに閉じる記号」とはかぎらないわけで、とすると、結果として「行末書式指定」かも……。 - 名無しさん (2007年11月15日 21時46分17秒)
• もっとよく考えると、「パラグラフ」の方は、開始と終了の両方を指定できるわけで、行末だけ指定が気持ち悪い人は、行頭側にもなんらかの指定を追加するか、私みたいにそもそも使わないようにするか、すればいいわけだ！「行末書式指定」を許すかどうかは管理者にゆだねられていると。なるほど。 - 名無しさん (2007年11月15日 21時57分37秒)
• ブロック要素を示す行末記号は必要/不要を決めるのは編集者の自由で任意なんですね。ガイドラインを決めるには、Wiki記法標準化プロジェクトの内容も一通り詳細な確認が必要と思いました。ご指摘有難うございます。 - A_M (2007年11月15日 23時26分36秒)
• ryon殿：「左寄せ、センタライン、右寄せ等を残すなら…」＞HTML規格準拠パターンとしては残さない方が良さそうですね。装飾内容そのものなので、意味付けする適当な書式名がありません。無理やり付けるとしたら、『宛先』『字幕』『署名』といった訳の分らないものになりそうです。現行の『ホット』『一大事』『争点』なんかも同じようなものですが…。 - あき (2007年11月16日 00時23分32秒)
• ryon殿：「重要な小見出し(h5)、小さな見出し(h6)がインライン要素の書式記法で表されているので、これはブロック要素の書式記法とすべきであろうと思います。」＞了解です。閉じ側を使用するのはFSWikiらしくないのでやめます。提供する標準書式には含めません。プラグインの機能としては残します。 - あき (2007年11月16日 00時23分43秒)
• ryon殿：「ホット、一大事、警告、争点、気になる箇所、マーカーは、全て、強調を意図したものであり、強調するニュアンスの違いであるのだから、全てspanではなくstrongかemを使うべきであろうと思われます。」＞そうですね。 - あき (2007年11月16日 00時23分50秒)
• ryon殿：ブロック要素に閉じ記号も指定できるようにした理由ですが、MediaWikiなんかでは見出しの書式が見出し名を複数の「=」で囲む記法が採用されています。個人的には、Wiki記法を知らない人間が見ても何となく見出しっぽく見えるところが気に入っています。Wiki記法標準化プロジェクトの見出し書式に関して言えば、閉じ側はなくても可ですが、有った場合、後ろ側の「=」は取り除いて見出し文字列にしなければなりません。ですよね？（と思って試してみたら現版でもそう動かない…。ありゃ…。(汗)　次版では対応します。メモ：Install.pmの103行目の「+」の直後に「?」を挿入すれば解決） - あき (2007年11月16日 00時23分58秒)
• ryon殿：「殆どのユーザにとっては興味の無い話」というのは、このプラグインがHTML規格準拠か否かという件についてそう発言しました。 - あき (2007年11月16日 00時24分05秒)
• もう議論の方向性はある程度修正されたようで、今更とは思いますが一言。この議論は、問題のある使い方を許容するかどうかに収束するように思います。刃物が殺人に使えるから刃物の販売は許さないか？です。刃物＝本プラグイン自体は有用と思います。あとはいかに問題のある使い方をさせないかです。 - 猫X (2008年03月05日 12時40分16秒)
• これは思想を含む問題で、技術的に思想を完全には制御できません。特売商品の値段に対し、class名で意味づけ（赤：redとするか特価：special_priceとするか）はプラグインで強制できません。実態は制御できないのですから、ここでは形式的にHTML規格に沿う技術的改善点が求められるべきと思います。 - 猫X (2008年03月05日 12時40分41秒)
• ryonさんにはあくまで技術的改善点としての発言を、あきさんにはサンプル等の修正をお願いしたく思います。規格に対する神経質な表記は不要ですが、サンプルは「あるべき姿」での提示が望ましいと思います。また、spanのネストのような問題がプラグイン側で予防できるなら、これに対応すればなお本プラグインが有用になります。 - 猫X (2008年03月05日 12時43分17秒)
• 現状はあくまで「提案」ですから、将来的に標準的な使い方で形式的にHTML-strictへの準拠がなされれば、公式FSWikiの制式プラグインにはなり得ると思います。この際、技術的に規格準拠を強制できない部分がとして残っても、その仕様（注意事項）がユーザーに伝わればよいと思います。 - 猫X (2008年03月05日 12時45分36秒)
• 私自身は、サイトの見栄えが簡単に統一できる本プラグインは、公式FSWikiにあってもおかしくない、あって欲しい機能を含む素晴らしい提案と思います。まだ解決可能な問題点がいくつかあるにすぎません。ですから、批判でなく応援したいと思います。 - 猫X (2008年03月05日 12時46分18秒)
• 設定読み込み部分がFarmを考慮していないため、Farmの方で独自に設定しても親の設定が反映されてしまいます。Farmの設定自体は保存されています。 - 名無しさん (2008年05月13日 18時50分18秒)
• Install.pm内に数箇所ある「my $config_fname = "config/addwikiform.dat";」を「my $config_fname = $self->{wiki}->config('config_dir') . "/addwikiform.dat";」に修正して一応いけるようです。 - 名無しさん (2008年05月13日 18時54分45秒)
• これ便利ですね！プラグインを利用した（更新日とか）記述の位置が調整できなくて困っていたのですが、これで無事解決しました。感謝！ - まめ (2008年12月23日 12時28分47秒)
• 提起した問題は刃物販売ではなく殺人の是非です。HTMLを出力するCGIなのだから、HTML規格に従うのは当然です。HTML規格を念頭において、可能な限り規格に従うように設計されていてこそ、正式採用に値します。HTML規格の枠に留まらない、というか、規格と無関係な自由度を持たせるのは、Wikiの進化に逆行します。そのような自由度がなくとも、建前上の目的は達成できるはずです。例えば、BugTrack-plugin/397のようにすれば、「規格の枠を超えた自由」は制限できます。尚、class名については、ここで挙げられたサンプルに対する異論（意味付けで定義していると言いながら、実は、見栄えで定義しているじゃないか。意味付けで定義していると言うなら、意味に従ったclass名にすべきではないのか。ということ）であって、各ユーザーがどのようなclass名を使うかは全く別問題です。そして、DIVやSPANは技術的に制限できるので、無秩序なclass名はある程度制限可能です。 - ryon (2009年01月25日 23時46分35秒)