x
 
Олег Истомин
16 августа 2012

Стоит ли наращивать вложенность тегов для структурированности кода?

Например, список комментариев (выделение отдельных комментариев не понадобится). Его можно оформить так:

<div>
    <h1>Комментарий 2</h1>
    <p>Текст комментария 2</p>
</div>
<div>
    <h1>Комментарий 1</h1>
    <p>Текст комментария 1</p>
</div>

А можно так (проще, но все в кучу):

<h1>Комментарий 2</h1>
<p>Текст комментария 2</p>
<h1>Комментарий 1</h1>
<p>Текст комментария 1</p>

Последний способ увеличивает скорость сайта, но не возникнут ли потом проблемы?



В общем случае, я бы обернул всё, что относится к комментарию ещё в один тег для гибкости.

Что, если пользователь разобьёт свой комментарий на несколько абзацев? Дизайнеру может не понравиться, что абзацы имитируются двумя переводами строки <br><br> внутри одного <p>, он попросит сделать честные <p> и сблизить их на половину высоты строки, а расстояние между комментариями увеличить. Без дополнительной обёртки всё это сделать очень трудно.

Не стоит заниматься преждевременной оптимизацией, выкидывая лишние элементы и придумывая, какой хитрый ЦСС их заменит. Наоборот, сначала лучше делать разметку в лоб и на вырост: завтра может потребоваться выделение важного комментария, через неделю — удаление комментария аяксом, через месяц ещё что-то. Чем богаче разметка, тем легче настраивать стили и реже придётся копаться в разрезанном шаблоне на сервере. Перебарщивать, конечно, тоже не стоит, достаточно каждой сущности дать свой тег:

<ul class="comments">
  <li class="comment">
    <h3>Инга2007</h3>
    <p>А если исключить момент силы трения?</p>
  </li>
  <li class="comment">
    <h3>Саня МАК</h3>
    <p>Согласен.</p>
    <p>Во втором абзаце хотел бы отметить...</p>
  </li>
</ul>

Да, такая разметка замедляет страницу. Но заметить это без веб-инспектора можно, наверное, только при >1000 комментариев. При сотне комментариев вариант:

ul.comments>(li.comment>h3+p)*100

по сравнению с вашим:

(h1+p)*100

утяжеляет страницу всего на 2,5 КБ — это не так существенно, чтобы жертвовать удобством и отказываться от дополнительной обёртки.

Предлагаю уважаемым советчикам поделиться своим опытом экономии тегов и разметки комментариев.

Те, кто знаком с Дзен-кодингом, легко прочитают эту аббревиатуру.

P. S.
Это был совет о разработке веб-интерфейсов. Хотите узнать всё об умной вёрстке, правильных скриптах, грациозной деградации, трюках и работе технолога с дизайнером? Присылайте вопросы.

Поделиться
Отправить

Комментарии

Андрей Ситник
16 августа 2012

Утяжеления размера страницы практически не будет — выдача веб-сервера (при правильной настройке) гзипуется, так что повторяющиеся теги и классы будут сжаты.

Владимир Кузнецов
16 августа 2012

Современные браузеры гораздо быстрее рендерят DOM при меньшей глубине вложения при прочих равных условиях. Это неоспоримый факт. По этому любое вложение — это удар по производительности. Если нужно отобразить 1000 комментариев на одной странице, то плевать на семантику — делаем зазоры между комментариями пустыми элементам, дополнительными классами у параграфов и т. п.

Артём правильно заметил, что хорошо структурированную разметку в дальнейшем будет проще обслуживать. По этому, если нет задачи работать с экстремально большим количеством элементов на странице (5-10-20-50 тысяч) или оптимизировать сайт под маломощные устройства, то в первую очередь заботимся о структуре документа, заботливо отделяя сущности друг от друга.

Дима Николаев
16 августа 2012

Если у вас тысяча комментов на одну страницу выливается — вам нужно не код, а дизайнера оптимизировать.

Коля Митин
16 августа 2012

Ситник меня опередил про gzip, но я хотел бы добавить, что не постеснялся бы завернуть ещё и текст комментария в свой див.

Ростислав Чебыкин
17 августа 2012

На большинстве сайтов самым «толстым» местом обычно являются скрипты, особенно сторонние фреймворки. Они грузят и тормозят на много порядков больше, чем какая угодно вложенность в коде ХТМЛ.

На втором месте после скриптов — с большим отрывом — особо монструозные селекторы в ЦСС, вроде тех, где участвует *.

И только после скриптов и ЦСС имеет смысл обращать внимание на производительность кода ХТМЛ.

В реальных проектах практически никогда не удаётся оптимизировать скрипты и ЦСС настолько, чтобы стало заметно, как на скорость сайта влияет многоуровневая вложенность ХТМЛ.

Владимир Кузнецов
17 августа 2012

Дима, да всё с дизайнерами в порядке. Посмотрите страницу «Советы» http://artgorbunov.ru/bb/soviet/ Там как раз тысяча советов на одной странице.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Сайты для слабовидящих 2 За какими вещами нужно следить, чтобы при загрузке страница выглядела прилично? 1 С чего начать изучение ЦСС? 1 Как сделать, чтобы блок при прокрутке залипал у верхней границы окна браузера? 5




Недавно всплыло

Как сделать нагляднее таблицу перфорированных лотков? Часть вторая 5 Несмотря на то, что между нами была договорённость о работе по ФФФ, клиент был в бешенстве 5 Визуализация проявляет 4 2