ユーザー入力フィールドを検証するときにHTMLテーブルを許可しない理由は何ですか?
質問
ウィキを少し書いて、構文の強調表示に関するすべてのオプションを検討しています。 wiki構文(mediawiki)とmarkdown + whitelistedタグの間の議論。私は後者を好むと思うが、ユーザーにはテーブルが必要だと思う。 Stackoverflowでここでテーブルが許可されないのはなぜですか?
<table> <tr> <td> </td> </tr> </table>
解決
Q <!> amp; A形式では何の目的もありません。少なくとも、誰かの質問に答えたり、自分で質問したりするためにテーブルを使用する必要がある理由は考えられません。
プラス、とにかくこれを行うことができます:
cell 1-1 cell 1-2
cell 2-1 cell 2-2
編集:だから、返信に対するコメントを読んだ後、テーブルがより良い視覚補助を提供できるいくつかのケースがあるかもしれないことがわかります。したがって、CSVに似たマークダウンを推奨します。入力して実装するのは簡単だと思います。
他のヒント
サイトをテーブルの上に構築し、ユーザーのhtmlが構文的に正しいことを検証するのに十分な正規表現を記述できない場合、テーブルを許可しないことをお勧めします。そうしないと、レイアウトが影響を受ける可能性があります。
サイトがレイアウトされていない場合でも、コメント投稿などに不正な形式のテーブルHTMLが2セットあると、サイトが改ざんされる可能性があります。
3つの理由:
- 任意のMarkdown実装との互換性、
- 安全なユーザー入力、
- レイアウトに依存しないコンテンツ
Standard Markdownはテーブルをサポートしません 。電子メールのように意図されています。 SOは標準のマークダウンを使用するため、テーブルは使用しません。
一部 Markdown拡張機能はテーブルをサポートしていますが、それらの間では互換性がありませんコンテンツは特定のMarkdown実装に依存するようになるため、Markdownの概念を無効にします。
したがって、テーブルはHTML-inside-Markdownでのみ作成できます。これも良くありません。 Markdown2PDF、Markdown2TeX、Markdown2TheNextBigMLコンバーターは簡単に作成できます。 HTMLを埋め込んだMarkdownをHTML以外のものに変換するのは簡単ではありません。そのため、(一部の)埋め込みHTMLが許可されている場合、Markdown(プレーンテキスト)にすべてを保存しても意味がありません。
ユーザーが送信したすべてのHTMLをサニタイズする別の理由は明らかであり、適切に解析するには難しすぎて高価であり、レイアウトを壊す可能性があります(<table width="10000" height="10000">
など)。
最後に、軽量(純粋なマークダウン)マークアップには大きな利点があります。特定のサイトレイアウト(画面幅、パディング、マージン、位置調整、列幅など)に依存しません。そのため、SOの再設計が1年後に行われた場合、コンテンツを編集する必要はありません(HTMLスニペットは特定のCSSに暗黙的に依存します)。追加ボーナス:サードパーティのアプリケーション(携帯電話クライアントなど)で使いやすくなりました。
それはarbitrary意的だと思います。それらには多くの用途がありますが、ここでは手動で固定幅のテキストを揃えることが好ましいようです(これはハックと考えられます)。
個人的には、BBCodeスタイルの構文を好みます。
- 明示的
- ほとんどHTMLに似ています
- 角度の代わりに角括弧を使用しているため、HTMLと混同することはできません
<!> quot; explicit <!> quot;は、意図した効果をほぼすべての組み合わせで表現でき、意図しない効果がないことを意味します(多くの特殊文字の1つが使用されている場合のマークダウンなど)。たとえば、このサイトで単語を非固定フォント(* word *)でアスタリスクで表示する方法はわかりません。モールス符号は特殊文字でもあるため、下線を使用できません。 BBCodeには、特殊文字が1つだけあります:[
さらに、入力のサニタイズがはるかに簡単になります。
Wisiwyg javascript editor(WMD)は、入力中の内容をリアルタイムでレンダリングする必要があると考えます
(SOの最初からジェフが望んでいた重要な機能)
したがって、テーブルの動的更新は、解析/表示するには複雑すぎると思います。HTMLトランスレータは、入力中に不完全なテーブル構造を解釈する必要があるためです。
つまり、colspan、rowspan、不適切なヘッダー構造などの機能に対処することを意味します。
したがって、より優れた動的プレビューエクスペリエンスを得るために、テーブルは完全にスクラッチされました。
テーブルが役立つ多くのケースがあります:データのテーブル、マトリックスの表示、アルゴリズムの可能な結果の表示など。
HTMLテーブル(rowspanおよびallを含む)ほど複雑なものは必要ないと思います。99%のユースケースではプレーンCSVで十分だと思います。また、javascript動的レンダラーがその仕事を簡単に行えるようになります。
CSVはよく知られており、軽量で、入力や理解が簡単です。その上で必要なのは、CSVデータの開始タグと終了タグだけです。たとえば、[csv] ... [/ csv]または|| ... ||。次のようになります。
[csv]
**XOR**,**true**,**false**
**true**, false, true
**false**, true, false
[/csv]
これにより、次のような表が生成されます。
XOR true false
true false true
false true false
(最初の行と最初の列を太字で表示)