Кто должен делать разметку семантичной: верстальщик или разработчик?

Question

[Viktor Vsk]

Типичный рабочий процесс - это дизайнер -> верстальщик -> разработчик.

Бывает, что верстальщик делает верстку со всевозможными article, section, header. А потом что-то меняется в шаблоне и это не имеет никакого смысла.
Но это - пол беды. Встречаются случаи, когда от всех этих section, time, dt, dd зависит CSS. Тогда уже у разработчика может начать болеть голова.

UPD: Что бы не отвечать всем, дополню вопрос.
Представим верстальщика, который решил сделать хорошо и написал, не идеальную, но семантическую, не перегруженную классами разметку:

<main class='articles'>
  <header>Статьи</header>
  <article>
    <footer>
      <time>21.05.2015</time>
    </footer>
  </article>
</main>

И так далее. И, соответственно, scss к этому делу:

.articles{
  & > header{ ... }
  & > section { ... }
}

Конечно, каскадные селекторы не очень хорошо, но и идеально не бывает. А если в простейших случаях писать
<header class='article__header'>Header</header>
то с актуальностью html5 тегов еще можно поспорить.

А вот разработчик (тот, кто натягивает на CMS, или режет макет на шаблоны) - обычно копирует app.css, открывает в одной вкладке шаблон, в другой - свой проект, и в редактор переносит макет. И не всегда ему хочется думать о том, зачем ему писать (HAML):
%time.article__time
вместо просто:
.article__time

Особенно это заметно, когда верстка делалась под один шаблон, а со временем он начинает преображаться.

Answer 1

[Евгений Петров]

Вы реально намереваетесь ориентироваться в CSS на имена тэгов типа article, header, etc.? Ну тогда такая вёрстка сразу летит в топку.
И нет таких «каскадных селекторов». Есть комбинаторы, и есть каскад, на котором основан CSS и без которого он вообще невозможен.

Comments

[Viktor Vsk]

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

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

[Евгений Петров]

Какой-нибудь footer может встречаться и в article, и в section и в прочих группах элементов. Так что какая разница — писать комбинатор с классом где-то в начале цепочки или присвоить класс непосредственно каждому элементу footer? Экономия HTML-кода? Сэкономленные 10 килобайт, ужимаемые до 2-х GZIP-ом при передаче не слишком согреют при случайном пересечении стилей.

А при подключении шаблонов никто не думает — просто берут готовый кусок кода и всё. Единственный вопрос, который терзает — что же, что же поставить для такой конструкции. ИМХО тут не нужно слишком сильно заморачиваться — не знаешь, как делать, лепи div и span. С опытом у любого появляется набор решений задач по структурированию.

[Евгений Петров]

Для примера с именами тэгов — мне в готовом модуле пришлось в срочном порядке заменять имена тэгов на кастомные во избежание накладок от говностилей верстальщиков приличной части шаблонов одной CMS.
Вот там-то я вдоволь насмотрелся и на имена тэгов в селекторов (причём как без комбинаторов, так и с таковыми, но тоже сплошь состоящими из имён тэгов). И на универсальные селекторы тоже налюбовался. В плохом смысле этого слова.

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

Answer 2

[Павел]

разработчик чего? Верстальщик это конечный пункт до продакшена , если только нет натяжки на cms .
Если есть cms то тот кто натягивает верстку особо не трогает. А если и трогает то есть замечательная функция рефакторинг.

Answer 3

[Денис Малиночкин]

Верстальщики должны делать её семантической и использовать всевозможные HTML5 теги. Ваш вопрос легко решается использованием каких-либо методик написания стилей (RSCSS, BEM или какой-нибудь нормальной логикой) и присваивания этим тегам соответствующих классов.