Quali sono i motivi per non consentire le tabelle HTML durante la convalida dei campi di input dell'utente?

Question

Sto scrivendo un po' di wiki ed esaminando tutte le mie opzioni per l'evidenziazione della sintassi.Dibattito tra la sintassi wiki (mediawiki) e markdown + tag autorizzati.Penso che preferirei quest'ultimo, ma penso che i miei utenti avranno bisogno di tabelle.Perché le tabelle non sono consentite qui su Stackoverflow?

<table> <tr> <td> </td> </tr> </table>

Answer 1

Non servono a nulla in un amplificatore Q &; Un formato. Almeno non riesco a pensare a un motivo per cui avrei bisogno di usare un tavolo per rispondere alla domanda di qualcuno, o chiedermene uno io stesso.

Inoltre, puoi farlo comunque:

cell 1-1      cell 1-2
cell 2-1      cell 2-2

EDIT: Quindi dopo aver letto i commenti sulla mia risposta, vedo che potrebbero esserci alcuni casi in cui una tabella potrebbe fornire un miglior aiuto visivo. Quindi consiglierò un markdown simile a CSV; Penso che sia abbastanza facile da digitare e implementare.

Answer 2

Non consentire le tabelle sarebbe una buona idea se il tuo sito è costruito su tabelle e non puoi scrivere una regex sufficientemente buona per verificare che l'HTML degli utenti sia sintatticamente corretto, altrimenti il ​​tuo layout potrebbe risentirne.

Anche se il tuo sito non è strutturato in tabelle, avere due serie di tabelle html non valide nei post dei commenti, ecc.potrebbe portare alla deturpazione del tuo sito.

Answer 3

Tre motivi:

• compatibilità con implementazioni Markdown arbitrarie,
• input dell'utente sicuro,
• contenuto indipendente dal layout

Standard Markdown non supporta le tabelle. È pensato per essere proprio come l'e-mail. SO utilizza Markdown standard, quindi nessuna tabella.

Alcune estensioni Markdown supportano le tabelle, ma non sono compatibili tra a vicenda, il che invalida l'idea di Markdown, perché il contenuto diventa dipendente da una particolare implementazione di Markdown.

Quindi, le tabelle possono essere create solo con HTML-inside-Markdown. Anche questo non va bene. Sono sicuro che i convertitori Markdown2PDF, Markdown2TeX e Markdown2TheNextBigML sono facili da scrivere. Convertire Markdown con HTML incorporato in qualsiasi cosa tranne HTML non è banale. Quindi non ha senso archiviare tutto in Markdown (testo normale), se (alcuni) HTML incorporato è consentito.

Un altro motivo per disinfettare tutto l'HTML inviato dagli utenti è ovvio, è troppo difficile e costoso da analizzare correttamente e può rompere il layout (ad esempio <table width="10000" height="10000">).

Infine, c'è un enorme vantaggio in un markup leggero (markdown puro): non dipende da un particolare layout del sito (larghezza dello schermo, padding, margini, giustificazione, larghezza delle colonne, ecc.). Quindi, se una riprogettazione SO avviene tra un anno, il contenuto non deve essere modificato (gli snippet HTML dipendono implicitamente da un determinato CSS). Bonus aggiuntivo: più facile da usare in applicazioni di terzi (come i client di telefonia mobile).

Answer 4

Penso che sia arbitrario. Potrebbero esserci molti usi per loro, ma sembra che l'allineamento manuale del testo a larghezza fissa sia preferito qui (che io considero un hack).

Personalmente, preferisco la sintassi in stile BBCode.

• è esplicito
• è quasi come HTML
• non può essere confuso con HTML a causa dell'uso delle parentesi anziché degli angoli

&

quot; & Esplicito quot; significa che qualsiasi effetto desiderato può essere espresso in quasi tutte le combinazioni e non ci sono effetti indesiderati (come nel caso del markdown, quando viene usato uno dei tanti caratteri speciali). Ad esempio, non ho idea di come ottenere questo sito per visualizzare una parola negli asterischi in un carattere non fisso (* parola *). Il codice Morse non può usare la sottolineatura, perché è anche un carattere speciale. In BBCode, c'è solo un personaggio speciale: [

Inoltre, la sanificazione dell'input diventa molto più semplice.

Answer 5

Considera che l'editor javascript di Wisiwyg (WMD) deve eseguire il rendering di ciò che stai digitando in tempo reale
(una caratteristica importante voluta da Jeff dall'inizio di SO)

Quindi, penso che l'aggiornamento dinamico della tabella sarebbe troppo complesso per analizzare / visualizzare , dal momento che il traduttore HTML dovrebbe interpretare le strutture di tabella incomplete mentre le digiti.
Ciò significa far fronte a funzionalità come colspan, rowpan, strutture di intestazione errate e così via.

Quindi, per avere una migliore esperienza di anteprima dinamica, le tabelle sono state completamente graffiate.

Answer 6

Esistono molti casi in cui le tabelle sarebbero utili: tabella di dati, visualizzazione di una matrice, visualizzazione dei possibili risultati di un algoritmo, ecc.

Non penso che tu abbia bisogno di qualcosa di così complesso come le tabelle HTML (con rowpan e tutto il resto), il semplice CSV sarebbe sufficiente per il 99% dei casi d'uso, credo. Consentirebbe anche al renderer dinamico javascript di fare facilmente il suo lavoro.

CSV è noto, leggero, semplice da scrivere e da capire. L'unica cosa necessaria in più sarebbe un tag di inizio e fine per i dati CSV. Ad esempio [csv] ... [/ csv] o || ... ||. Ecco come potrebbe apparire:

[csv]
**XOR**,**true**,**false**
**true**, false, true
**false**, true, false
[/csv]

Questo produrrebbe una tabella come questa:

XOR     true    false
true    false   true
false   true    false    

(con la prima riga e la prima colonna in grassetto)