Мои мысли о CSS-фреймворке и CSS-модулях всегда были расплывчатыми, и я полностью следую этой тенденции. Проблемы, с которыми я столкнулся на работе в последнее время, заставили меня обратить внимание на этот вопрос. Я привык, что все делает один человек: планирование, проектирование и публикация. Когда проект требует совместной работы нескольких людей и завершения его за короткое время, планирование файлов стилей, продумывание модулей CSS и фреймворков особенно важно.
В последнее время меня беспокоит следующий вопрос: Если над стойкой сайта одновременно работают несколько человек, как их распределить, чтобы стиль всего сайта был единым, структура файлов стилей была разумной, есть никакого дублирования и избыточности, а эффективность высочайшая? Я проконсультировался с несколькими одноклассниками, и полученные ответы суммируются следующим образом: Что касается унификации стиля, мы вместе обсудили, чтобы сначала сделать эскиз, и один человек сделал стандартную страницу стиля на основе эскиза, а затем мы начали работать вместе. а остальное было постоянной модификацией. С точки зрения производства, для всего сайта установлено несколько разных CSS-файлов, и каждый человек отвечает за разные файлы стилей.
То, что легко сказать, не так-то просто после реализации. Что касается дизайна, я пока не смею рисковать. К счастью, страниц первого и второго уровня не так много, и с этим справится один человек. Расскажите о процессе производства.
(1) Стандартизировать именование CSS, порядок написания и комментарии.
Не говоря уже о важности этого момента, трудно представить, насколько запутанным было бы появление в таблице стилей одновременно нескольких «строго персонализированных» методов именования. В именовании может использоваться соединение средних символов «-», «_», например, текстовое поле, текстовое содержимое, text_box или написание верхнего и нижнего регистра «горб», textBox, textContent и т. д. Комментарии очень важны. Комментарии можно разделить на три уровня. Основные категории комментариев используются для разделения блоков CSS, таких как аннотации второй категории, аннотации локальных модулей в основных категориях и аннотации третьей категории. аннотировано в селекторе. Используйте комментарии или комментарии к некоторым специальным эффектам. Формат письма может использовать горизонтальные отступы для отображения иерархических отношений.
(2) Определить структурное разделение таблицы стилей на основе визуализации.
В Интернете есть много статей о разделении файловой структуры CSS, которые обычно представляют собой всего несколько файлов: layout.css/main.css/footer.css/header.css/reset.css и т. д. Все говорят, что это хорош в этом и практикуйте это. Поймите, нет лучшего, есть только самое подходящее. Лучшее разделение стилей должно тесно зависеть от самой структуры HTML, а не быть универсальным.
Помимо облегчения будущего разделения труда и совместной работы, распространение CSS-файлов также имеет очень важный момент: если байты маленькие, их можно максимально сжать, чтобы уменьшить количество одновременных подключений. Если байты слишком велики. большие, их можно разделить, чтобы скорость загрузки не была слишком низкой, что влияло на загрузку стиля. Это конкретные вопросы, которые необходимо решать в каждом конкретном случае. Например, для часто посещаемых страниц, таких как поисковые системы и домашние страницы порталов, лучше всего написать CSS внутри страницы.
Предварительно определитесь со структурой стилей css:
Пример исходного кода
reset.css /*Перезарядка стиля страницы*/
header.css /*Стиль заголовка для всего сайта*/
footer.css /*Полный стиль нижнего колонтитула сайта*/
public.css /*Публичный стиль модуля для всего сайта*/
index.css /*Уникальный стиль домашней страницы*/
Container.css /*Стили тела уровня 2 и ниже*/
print.css /*Стиль печати*/
ie.css /*IE хак*/
(3) Разделение труда и сотрудничество
Сцена установлена, и начнется пение. Найдите все общедоступные текстовые списки, а также смешанные списки изображений и текста. Один человек отвечает за написание общедоступного модуля, по одному человеку за заголовок и хвост и один человек за второстепенный фрейм страницы. Персонализированная часть оставлена на конец.
В реальной эксплуатации все еще существует множество проблем. Избыточности кода невозможно избежать, и ее можно только свести к минимуму. Иногда ради эффективности приходится идти на жертвы.