Каковы причины, по которым таблицы HTML не допускаются при проверке полей ввода пользователя? - PullRequest
Новая
       37

Каковы причины, по которым таблицы HTML не допускаются при проверке полей ввода пользователя?

5 голосов
/ 23 января 2009

Я пишу немного вики и изучаю все варианты подсветки синтаксиса. Обсуждение между синтаксисом вики (mediawiki) и тегами markdown + whitelisted Я думаю, что предпочел бы последнее, но я думаю, что моим пользователям понадобятся таблицы. Почему таблицы запрещены здесь в Stackoverflow? 

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

Ответы [ 6 ]

4 голосов
/ 23 января 2009

Они не имеют смысла в формате вопросов и ответов. По крайней мере, я не могу придумать причину, по которой мне нужно было бы использовать таблицу, чтобы ответить на чей-то вопрос, или задать ее самому.

Плюс, вы можете сделать это в любом случае: 

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

РЕДАКТИРОВАТЬ: Итак, после прочтения комментариев к моему ответу, я вижу, что может быть несколько случаев, когда таблица могла бы обеспечить лучшую визуальную помощь. Поэтому я собираюсь рекомендовать уценку, аналогичную CSV; Я думаю, что это достаточно просто набрать и реализовать.

2 голосов
/ 28 января 2009

Три причины:

  • совместимость с произвольными реализациями Markdown,
  • безопасный ввод пользователя,
  • контент, независимый от макета

Стандартная уценка не поддерживает таблицы. Он предназначен для электронной почты. SO использует стандартную уценку, поэтому нет таблиц.

Некоторые расширения Markdown поддерживают таблицы, но они несовместимы друг с другом, что лишает законной силы идею Markdown, поскольку контент становится зависимым от конкретной реализации Markdown.

Таким образом, таблицы можно создавать только с помощью HTML-inside-Markdown. Что тоже не хорошо. Я уверен, что конвертеры Markdown2PDF, Markdown2TeX и Markdown2TheNextBigML легко написать. Преобразование Markdown со встроенным HTML во что угодно, кроме HTML, не тривиально. Таким образом, нет смысла хранить все в Markdown (простой текст), если (некоторые) встроенный HTML разрешен.

Другая причина очистки всех представленных пользователем HTML очевидна, это слишком сложно и дорого для правильного анализа, и это может нарушить компоновку (например, <table width="10000" height="10000">).

Наконец, существует огромная выгода в облегченной (чистой разметке) разметке: она не зависит от конкретной компоновки сайта (ширина экрана, отступы, поля, выравнивание, ширина столбцов и т. Д.). Таким образом, если через год произойдет SO-редизайн, контент редактировать не нужно (фрагменты HTML зависят от конкретного CSS неявно). Дополнительный бонус: удобнее использовать в сторонних приложениях (например, клиентах для мобильных телефонов).

2 голосов
/ 28 января 2009

Запрещение таблиц было бы хорошей идеей, если ваш сайт построен поверх таблиц, и вы не можете написать регулярное выражение, достаточно хорошее для проверки того, что html пользователей синтаксически верен, иначе это может повлиять на ваш макет.

Даже если ваш сайт не представлен в виде таблицы, наличие двух наборов неверно сформированных таблиц html в комментариях и т. Д. Может привести к потере вашего сайта.

1 голос
/ 28 января 2009

Есть много случаев, когда таблицы были бы полезны: таблица данных, отображение матрицы, показ возможных результатов алгоритма и т. Д.

Я не думаю, что вам нужно что-то более сложное, чем HTML-таблицы (с rowspan и всем), простого CSV будет достаточно для 99% сценариев использования, я думаю. Это также позволило бы динамическому рендереру 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

(первая строка и первый столбец выделены жирным шрифтом)

1 голос
/ 28 января 2009

Учтите, что редактор JavaScript Wisiwyg (WMD) должен отображать то, что вы печатаете, в режиме реального времени
(важная особенность, разыскиваемая Джеффом с самого начала SO)

Следовательно, я думаю, динамическое обновление таблицы было бы слишком сложным для анализа / отображения , поскольку переводчик HTML должен был бы интерпретировать неполные структуры таблиц по мере их ввода.
Это означает, что нужно справиться с такими функциями, как colspan, rowspan, неправильные структуры заголовков и так далее.

Таким образом, чтобы улучшить динамический предварительный просмотр, таблицы полностью поцарапаны.

1 голос
/ 23 января 2009

Я думаю, что это произвольно. Их может быть много, но кажется, что здесь предпочтительнее выравнивание текста фиксированной ширины вручную (что я считаю хаком).

Лично я предпочитаю синтаксис стиля BBCode.

  • явно
  • это почти как HTML
  • его нельзя спутать с HTML из-за использования скобок вместо углов

«явный» означает, что любой предполагаемый эффект может быть выражен практически в любой комбинации, и нет никаких непреднамеренных эффектов (как в уценке, когда используется один из множества специальных символов). Например, я понятия не имею, как заставить этот сайт отображать слово в звездочках нефиксированным шрифтом (* word *). Азбука Морзе не может использовать подчеркивание, потому что это также специальный символ. В BBCode есть только один специальный символ: [

Кроме того, очистка входных данных значительно упрощается.

...