Как написать поддерживаемый HTML и CSS код?

Question

[Никита Pewget]

Один мой проект вошел к стадию, хорошо описанную в этом вопросе. Есть два файла с названиями default.css, common.css и куча мелких css-файлов. Внутри них царит хаос. На некоторых страницах есть отдельный блок style со стилями конкретно для этой страницы. Думаю, вы сами сталкивались с такими проектами.

Сейчас я планирую развивать этот проект, но с текущим бардаком это делать достаточно сложно - меняешь что-то в одном месте, ломается в другом, да и просто не приятно работать с таким кодом. Поэтому я принял волевое решение переписать frontend с нуля, заодно попробую свою силы, т.к. давно ничего серьезно не верстал.

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

Заранее спасибо за ответ!

Answer 1

[Денис Инешин]

Используйте LESS! Ну или там SASS/SCSS по желанию. + Сборщик проекта Grunt.

Это позволит вам разбить CSS код на неограниченное количество файлов и папок. А дальше Grunt все это обработает, собрав все это хозяйство в один файл, скажем style.css.

Чем удобен такой подход? У вас в директории проекта будет папочка ксс, внутри неё будут другие папочки или файлы, например defaults, header, footer, news и т.п. до бесконечности. В каждом из этих файлов будет только тот кусок кода, который отвечает за нужный вам блок. Проект в таком виде очень(!) удобно поддерживать и вносить правки. Кроме того удобно в этих же папочках рядом с нужным файлом стиля держать еще и нужные картинки. Скажем в папке header, лежат файлы: header.less, bg.png, logo.png и т.д. Очень удобно.

Далее, как это все работает:
LESS: www.lesscss.ru
Grunt: gruntjs.com + туториал: nano.sapegin.ru/all/grunt-0-4
Пользуйтесь!

Answer 2

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

Абсолютно независимо от среды разработки сначала следует составить структуру сайта.

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

После этого можно развесить листочки со структурой страниц (или прикрепить в той программе, что используете — например, в Mindjet Manager). И головная боль от того, где и что используется, пропадёт.

А что использовать в качестве среды разработки и инструментов для фронтенда — вообще второстепенный вопрос. Тем более, что в разных компаниях может быть свой набор.

Answer 3

[ultrbi4]

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

Answer 4

[Sergey Romanov]

В добавление ко всему уже сказаному.

Если проект динамичный то обязательно LESS. Но тут надо тоже окуратно. Будет хорошо если вы разбьете LESS файлы на 2 группы.

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

Вторая группа это все свойства кторые наводят красоту: color, background, font-face, ...

Таким образов вы получите на выходе 2 CSS файла. Один как бы обязательный а другой это тема или скин. Таким образом можно будет создавать разные скины уравляя параметрами одно файла.

Важна техника в LESS это вынос параметров в отдельный файл который включается в основной файл первым. Например

@borderRadius: 10px;
@buttonColor: #ff5544;

Надо вынести все настроки так что бы потом создание нового скина - это была работа редактирования только одного этого файла и больше ни чего.