Pourquoi ne pas autoriser les tableaux HTML lors de la validation des champs de saisie de l'utilisateur?

Question

J'écris un peu un wiki et passe en revue toutes mes options pour la coloration syntaxique. Débattre entre la syntaxe wiki (mediawiki) et les balises markdown + liste blanche. Je pense que je préférerais le dernier mais je pense que mes utilisateurs auront besoin de tables. Pourquoi les tables sont-elles interdites ici sur Stackoverflow?

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

Answer 1

Ils ne servent à rien dans un format Q & et A. Au moins, je ne vois pas pourquoi je devrais utiliser un tableau pour répondre à la question de quelqu'un ou en poser une moi-même.

De plus, vous pouvez le faire quand même:

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

EDIT: Donc, après avoir lu les commentaires sur ma réponse, je constate qu’il peut arriver qu’un tableau fournisse une meilleure aide visuelle. Je vais donc recommander un démarquage similaire à CSV; Je pense que c'est assez facile à taper et à mettre en œuvre.

Answer 2

Il serait judicieux de refuser les tables si votre site est construit sur ces tables et que vous ne pouvez pas écrire une expression régulière suffisamment bonne pour vérifier que le code HTML des utilisateurs est correct, sans quoi votre mise en page pourrait en être affectée.

Même si votre site n'est pas présenté en table, le fait d'avoir deux ensembles de tables malformées html dans les commentaires, etc. pourrait entraîner la dégradation de votre site.

Answer 3

Trois raisons:

• compatibilité avec les implémentations de Markdown arbitraires,
• entrée utilisateur sécurisée,
• contenu indépendant de la mise en page

Standard Markdown ne prend pas en charge les tables. Il est conçu pour ressembler à un courrier électronique. SO utilise donc Markdown standard, donc pas de tables.

Certaines tables de prise en charge des extensions Markdown, mais elles ne sont pas compatibles entre elles mutuellement, ce qui invalide l’idée de Markdown, car le contenu devient dépendant d’une implémentation particulière de Markdown.

Ainsi, les tableaux ne peuvent être créés qu'avec HTML-inside-Markdown. Ce qui n'est pas bon non plus. Je suis sûr que les convertisseurs Markdown2PDF, Markdown2TeX et Markdown2TheNextBigML sont faciles à écrire. Convertir Markdown avec HTML incorporé en quelque chose mais HTML n'est pas trivial. Il ne sert donc à rien de tout stocker dans Markdown (texte brut), même si un code HTML incorporé est autorisé.

Une autre raison de supprimer tout le code HTML soumis par l'utilisateur est évidente: il est trop difficile et coûteux d'analyser correctement et il peut casser la mise en page (par exemple, <table width="10000" height="10000">).

Enfin, un balisage léger (pur Markdown) présente un énorme avantage: il ne dépend pas d’une mise en page de site particulière (largeur de l’écran, marges, marges, justification, largeur de colonne, etc.). Ainsi, si une refonte SO a lieu dans un an, le contenu n'a pas besoin d'être modifié (les extraits de code HTML dépendent implicitement d'un code CSS particulier). Bonus supplémentaire: utilisation plus facile dans les applications tierces (comme les clients de téléphonie mobile).

Answer 4

Je pense que c'est arbitraire. Elles pourraient avoir de nombreuses utilisations, mais il semble que l’alignement manuel de texte à largeur fixe soit préférable ici (ce que je considère comme un hack).

Personnellement, je préfère la syntaxe de style BBCode.

• c'est explicite
• c'est presque comme HTML
• il ne peut pas être confondu avec HTML à cause de l'utilisation de crochets au lieu d'angles

" explicite " signifie que tout effet souhaité peut être exprimé dans presque toutes les combinaisons et qu'il n'y a pas d'effets inattendus (comme dans le démarquage, lorsqu'un des nombreux caractères spéciaux est utilisé). Par exemple, je ne sais pas comment faire en sorte que ce site affiche un mot sous forme d'astérisques dans une police de caractère non fixée (* mot *). Le code Morse ne peut pas utiliser le soulignement, car il s'agit également d'un caractère spécial. Dans le BBCode, il n'y a qu'un seul caractère spécial: [

De plus, la désinfection des entrées devient beaucoup plus simple.

Answer 5

Considérez que l'éditeur javascript de Wisiwyg (WMD) doit restituer ce que vous tapez en temps réel
(fonctionnalité importante recherchée par Jeff depuis le début de SO)

Par conséquent, je pense que la mise à jour dynamique de la table serait trop complexe à analyser / afficher , car le traducteur HTML devrait interpréter les structures de table incomplètes lors de leur saisie.
Cela signifie qu'il faut faire face à des fonctionnalités telles que colspan, rowspan, structures d'en-tête incorrectes, etc.

Pour améliorer la prévisualisation dynamique des tableaux, les tableaux sont complètement supprimés.

Answer 6

Il existe de nombreux cas où les tableaux seraient utiles: tableau de données, affichage d’une matrice, résultats possibles d’un algorithme, etc.

Je ne pense pas que vous ayez besoin de quelque chose d'aussi complexe que les tableaux HTML (avec rowspan et tout), un fichier CSV simple suffirait pour 99% des cas d'utilisation, je pense. Cela permettrait également au moteur de rendu dynamique javascript de faire son travail facilement.

CSV est bien connu, léger, simple à taper et à comprendre. La seule chose nécessaire en plus serait une balise de début et de fin pour les données CSV. Par exemple, [csv] ... [/ csv] ou || ... ||. Voici à quoi cela pourrait ressembler:

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

Ceci produirait un tableau comme celui-ci:

XOR     true    false
true    false   true
false   true    false    

(avec la première ligne et la première colonne en caractères gras)