Форматирование динамически генерируемого HTML - не заботится?

У меня очень мало опыта в веб-разработке, поэтому это может быть очень простой вопрос.

Это просто из ограниченного опыта, который у меня есть (немного PHP и немного Ruby on Rails), кажется, что способ форматирования динамически генерируемого HTML просто "не имеет значения"; он заканчивается уродливым, с странным отступом, и никто не заботится, потому что это не то, что видят пользователи.

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

Может быть, вы не знаете, о чем я говорю; поэтому позвольте мне привести пример.

В файле Ruby у меня может быть такой код:

<h1>Heading</h1>

<div>
    <%= render :partial => '/layouts/body' %>
</div>

Затем в файле "/layouts/_body.html.erb" у меня может быть следующее:

<p>Here is some content!</p>

<ul>
    <li>List item 1</li>
    <li>List item 2</li>
    <li>List item 3</li>
</ul>

Когда все это получится, все будет хорошо. Но если пользователь пытается просмотреть исходный код, HTML будет выглядеть довольно дерьмовым:

    <h1>Heading</h1>

    <div>
        <p>Here is some content!</p>

<ul>
    <li>List item 1</li>
    <li>List item 2</li>
    <li>List item 3</li>
</ul>

    </div>

Очевидно, это не имеет большого значения. И я могу полностью понять, есть ли преобладающее мнение просто "Это не имеет значения". Но так ли это должно быть? Насколько читаемость HTML не имеет значения для кого-либо?

Мне просто интересно узнать, действительно ли это когда-либо подслушивало кого-то еще, чтобы он/она придумали "решение" для него (очевидно, это должен был быть тот, кто рассматривал его как "проблему" в первом место).

Ответы

Ответ 1

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

Итак, да, это просто лень.

Ответ 2

Важен семантически правильный валидированный HTML; очень важно. Несколько пробелов и разрывов строк не важны - любой достойный форматер может легко разрешить это. В большинстве случаев ничего, кроме браузера, не будет просматривать его, поэтому это действительно не так важно по сравнению с проверкой.

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

Ответ 3

Хорошо, если вы сделаете дополнительный проход над файлом, чтобы украсить его перед отправкой его пользователю, вы:

  • Увеличьте размер файла (медленнее, чтобы загрузить), и, таким образом, дайте пользователям ощущение, что ваш сайт "отстает" и медленный (что он)

  • добавляет дополнительные дополнительные ресурсы на ваш сервер, возможно, максимизирует их и замедляет еще больше

Помимо помощи одному или двум парням, которые читают исходный код (который может быть автоматически украшен в большинстве редакторов), что вы надеетесь сделать с этим, чтобы он того стоил?

Ответ 4

Любите это или нет, HTML - это формат, читаемый браузером, не обязательно читаемый пользователем. Инструменты (редакторы WYSIWIG, языки разметки, такие как Markdown, MediaWiki и т.д. И ваши любимые веб-фреймворки) должны использоваться для генерации HTML. Доступно множество программ, позволяющих читать HTML для разработчиков; см. другие сообщения.

XHTML и инструменты генерации XML имеют некоторые перспективы в отношении удобочитаемости, поскольку их результат может быть пост-обработан более легким (например, с помощью просмотра браузером), чтобы получить правильный отступ, но (IMHO) пока еще недостаточно зрелые, судя по количеству так называемых "W3C XHTML-совместимых" сайтов, которые на самом деле нет. Более новые версии, например WordPress, прилагают усилия, но их расширения, плагины и т.д. Полны плохого (X) HTML, даже не учитывая количество создаваемого JavaScript. (Как мы будем делать это?)

Совет:

  • (X) Код генерации HTML должен быть доступен для разработчиков. Но, пожалуйста, используйте тот, который, по крайней мере, генерирует что-то квази-читаемое.
  • Узнайте свой браузер поиск и используйте регулярные выражения.
  • HTMLTidy, в его многочисленных обличьях, ваш друг. Используйте его в тестах и ​​сравните его вход с его выходом

Ответ 5

Мне никогда неинтересно, потому что, если я хочу взглянуть на HTML, хорошо отформатированный, я могу просто запускать его, хотя TIDY, прежде чем смотреть на него.

Ответ 6

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

Однако многие инструменты (например, FireBug) отлично отформатируют код в структуре DOM, поэтому для разработчика это тоже не имеет значения.

Ответ 7

Чтобы просмотреть форматированный html, который немного лучше, вы можете использовать функцию "Проверить элемент" в Google Chrome или дополнение Firebug в Firefox. Я работаю с динамически генерируемым html все время (используя php), и я никогда не использую "источник страницы просмотра", эти другие инструменты работают намного лучше.

Ответ 8

Превалирующее мнение: "это не имеет значения", потому что, если вы хотите его просмотреть, доступно множество форматов и далее, что использование автоматизированного форматирования является пустой тратой системных ресурсов.

В сценариях, где это происходит, вы можете подумать:

  • Выбор языка, облегчающего его выполнение
  • Определение стандартов кодирования
  • Используя что-то вроде HTMLTidy, либо для обеспечения соблюдения стандартов кодирования, либо даже для автоматического форматирования HTML

Ответ 9

Это может раздражать, когда я пытаюсь посмотреть источник, чтобы увидеть, где отсутствует div или стиль. Я всегда пытаюсь сгенерировать любой html с приличным макетом, потому что 9/10 мне будет нужно искать ошибки.

Итак, с моей точки зрения, это имеет значение, даже если это не приоритет номер один, он должен прийти как приоритет 2 или, по крайней мере, 3, на мой взгляд, конечно.

В настоящее время, как разработчик С#, я обычно копирую исходный код в Visual Studio и делаю ctrl + k + f для отступов кода, поэтому его гораздо легче увидеть.

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

Ответ 10

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

Если вам нужно, чтобы исходный код был правильно отформатирован, большинство редакторов, ориентированных на IDE и ориентированных на программирование, содержат средство для "убирания" кода в правильно отступурованную версию.

Ответ 11

Если бы я отправил свою страницу через любой инструмент, это было бы minifier.

К сожалению, в браузере не размещен конкурс красоты кода:)

Ответ 12

Практически все уважаемые иероглифы имеют ярлык для автоматического форматирования: Visual Studio - ctrl + k + f Netbeans - alt + shift + f Eclipse - ctrl + shift + f

Итак, я думаю, что нет необходимости в форматировании.

Ответ 13

Важная часть состоит в том, что код генерации HTML является аккуратным и читаемым. Как и в вашем примере, любые вызовы функций, включая и т.д. Должны находиться в правильном отступе с остальной частью кода.

Помимо этого, это не имеет значения, если код правильно сформирован и действителен XHTML. Спецификация XHTML не определяет пробелы, но она определяет правильные закрывающие теги и т.д.

В принципе, если выходной код проверяет и код на стороне сервера читается, все хорошо. (Предполагая, конечно, что ваше приложение также работает.)