¿Cuáles son las razones para no permitir tablas HTML al validar los campos de entrada del usuario?

Question

Estoy escribiendo un poco de wiki y revisando todas mis opciones para resaltar la sintaxis. Debatir entre la sintaxis wiki (mediawiki) y las etiquetas markdown + whitelisted. Creo que preferiría lo último, pero creo que mis usuarios necesitarán tablas. ¿Por qué las tablas no se permiten aquí en Stackoverflow?

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

Answer 1

No sirven para nada en un formato Q & amp; A. Al menos no puedo pensar en una razón por la que necesitaría usar una tabla para responder la pregunta de alguien, o hacerla yo mismo.

Además, puedes hacer esto de todos modos:

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

EDITAR: Entonces, después de leer los comentarios sobre mi respuesta, veo que puede haber algunos casos en los que una tabla podría proporcionar una mejor ayuda visual. Así que voy a recomendar una rebaja similar a CSV; Creo que es bastante fácil de escribir e implementar.

Answer 2

No sería una buena idea rechazar tablas si su sitio está construido sobre tablas y no puede escribir una expresión regular que sea lo suficientemente buena como para validar que los usuarios html son sintácticamente correctos, de lo contrario su diseño podría verse afectado.

Incluso si su sitio no se presenta en la tabla, tener dos conjuntos de HTML de tabla con formato incorrecto en las publicaciones de comentarios, etc. podría hacer que su sitio se dañe.

Answer 3

Tres razones:

• compatibilidad con implementaciones arbitrarias de Markdown,
• entrada segura del usuario,
• contenido independiente del diseño

Markdown estándar no admite tablas. Está destinado a ser como el correo electrónico. SO usa Markdown estándar, por lo que no hay tablas.

Algunas extensiones de Markdown admiten tablas, pero no son compatibles entre entre sí, lo que invalida la idea de Markdown, porque el contenido se vuelve dependiente de una implementación particular de Markdown.

Entonces, las tablas solo se pueden hacer con HTML-inside-Markdown. Lo que tampoco es bueno. Estoy seguro de que los convertidores Markdown2PDF, Markdown2TeX y Markdown2TheNextBigML son fáciles de escribir. Convertir Markdown con HTML incrustado en cualquier cosa que no sea HTML no es trivial. Por lo tanto, no tiene sentido almacenar todo en Markdown (texto sin formato), si (algunos) HTML incrustado está permitido.

Otra razón para desinfectar todo el HTML enviado por el usuario es obvio, es demasiado difícil y costoso analizarlo correctamente, y puede romper el diseño (por ejemplo, <table width="10000" height="10000">).

Finalmente, hay un gran beneficio en un marcado ligero (Markdown puro): no depende de un diseño de sitio particular (ancho de pantalla, rellenos, márgenes, justificación, anchos de columna, etc.). Entonces, si un rediseño de SO ocurre dentro de un año, no es necesario editar el contenido (los fragmentos de HTML dependen implícitamente de un CSS en particular). Bonificación adicional: más fácil de usar en aplicaciones de terceros (como clientes de teléfonos móviles).

Answer 4

Creo que es arbitrario. Podría haber muchos usos para ellos, pero parece que aquí se prefiere alinear manualmente el texto de ancho fijo (lo que considero un hack).

Personalmente, prefiero la sintaxis de estilo BBCode.

• es explícito
• es casi como HTML
• no se puede confundir con HTML debido al uso de corchetes en lugar de ángulos

" explícito " significa que cualquier efecto deseado puede expresarse en casi cualquier combinación, y no hay efectos no deseados (como en la reducción, cuando se usa uno de los muchos caracteres especiales). Por ejemplo, no tengo idea de cómo hacer que este sitio muestre una palabra en asteriscos en una fuente no fija (* palabra *). El código Morse no puede usar el subrayado, porque también es un carácter especial. En BBCode, solo hay un carácter especial: [

Además, la desinfección de entrada se vuelve mucho más simple.

Answer 5

Tenga en cuenta que el editor de JavaScript Wisiwyg (WMD) tiene que representar lo que está escribiendo en tiempo real
(una característica importante que quería Jeff desde el comienzo de SO)

Por lo tanto, creo que la actualización dinámica de la tabla sería demasiado compleja para analizar / mostrar , ya que el traductor HTML tendría que interpretar estructuras de tabla incompletas mientras las escribe.
Eso significa hacer frente a características como colspan, rowspan, estructuras de encabezado incorrectas, etc.

Entonces, para tener una mejor experiencia de vista previa dinámica, las tablas se rascaron por completo.

Answer 6

Hay muchos casos en los que las tablas serían útiles: tabla de datos, mostrar una matriz, mostrar los posibles resultados de un algoritmo, etc.

No creo que necesite algo tan complejo como las tablas HTML (con una fila de filas y todo), creo que CSV sería suficiente para el 99% de los casos de uso. También permitiría que el renderizador dinámico de JavaScript haga su trabajo fácilmente.

CSV es bien conocido, ligero, simple de escribir y entender. Además, lo único que se necesitaría sería una etiqueta de inicio y fin para los datos CSV. Por ejemplo [csv] ... [/ csv] o || ... ||. Así es como podría verse:

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

Esto produciría una tabla como esta:

XOR     true    false
true    false   true
false   true    false    

(con la primera fila y la primera columna en negrita)