Мы поддерживаем довольно большой сайт с большим количеством страниц. По мере роста страниц, так же как и HTML и CSS. Есть ли хороший способ документировать эти данные? Как на какой странице используется определенный селектор и т.д. Какая наилучшая практика для поддержки CSS для большого сайта?
Как документировать CSS для большого сайта
Ответ 1
По моему опыту, CSS не поддерживается. Если бы CSS был комнатой в вашем доме, это подвал... он собирает вещи на протяжении многих лет, и через некоторое время вы, как правило, имеете больше вещей в нем, которые бесполезны против вещей, которые вы хотите сохранить.
Таким образом, я рекомендую начинать свежие каждые несколько лет.
Запрет на то, что некоторые предложения:
- Поддерживать CSS-dev-side в большом количестве отдельных файлов, как это имеет смысл. Используйте минимизатор для сжатия и объединения всех его в один файл для развертывания.
- просмотрите методы OOCSS (Object Oriented CSS). Я пытаюсь использовать это в наши дни для сайтов с большими командами разработчиков. Основная идея состоит в том, чтобы иметь больше имен классов в вашем HTML, но то, что у вас есть, гораздо более доступно для использования на всем сайте, поэтому ваши файлы CSS должны оставаться более упорядоченными.
- создавать библиотеки компонентов. Основная цель состоит в том, чтобы НЕ иметь конкретный css для каждой отдельной страницы. Вместо этого можно использовать многоразовый код и шаблоны проектирования на сайте.
Ответ 2
Я видел несколько систем, которые описывают CSS, написанные для интерфейса, с именами многократно используемых классов, как указывает DA, но они пошли вперед и дали архитектурное разбиение этих классов, поскольку их намерение состоит в повторном использовании. Затем они продолжили использовать подробные названия селекторов для компонентов и подробных функций, которые обычно не были задокументированы и были предоставлены третьими сторонами в основном.
Он работал довольно хорошо, и я думаю, что если бы интерфейс был перепроектирован в какой-то момент, это было бы трудным, но выполнимым заданием для повторной работы интерфейса CSS и документации, оставив компонентный стиль до сторонних поставщиков/разработчиков или тех, кто создает компоненты.
Как говорили другие, не позволяйте документам CSS заманивать вас во избежание минимизации, даже если это не автоматизировано, но будьте осторожны, если ваш CSS растягивается и непогашен, когда вы минимизируете, вы можете найти свои результирующие стили aren 't совершенно на уровне - в зависимости от используемых параметров minify.
EDIT:
Горячий канал Google+ - Джонатан Снук пишет что-то, связанное с этой нитью, здесь временная ссылка, чтобы следить за: http://smacss.com/
Ответ 3
Мы используем рельсы и следуем этой архитектуре: http://codefastdieyoung.com/2011/03/css-js-organization-best-practice/
В зависимости от используемой структуры вам может потребоваться соответствующим образом настроить логику.
Краткое объяснение архитектуры:
В рельсах существует способ указать общий идентификатор для группы страниц. Например: все страницы, связанные с управлением пользователями, могут иметь этот идентификатор: body # users-registration. Аналогично, все страницы, связанные с службами отчетности, имеют этот id: body # reporting-services
Сказав это, у вас есть файл common.css, который содержит общие стили, которые можно повторно использовать на сайте - например, стили макета, li, p, панели и т.д.
И затем у вас есть отдельные файлы css для каждой группы страниц: users-registration.css, reporting-services.css. Эти файлы будут иметь стили, относящиеся к соответствующей группе.
Таким образом нам также удалось избежать конфликтов на страницах.
Обратите внимание, что мы, наконец, объединяем все файлы CSS в один файл css и делаем это в процессе производства.
Ответ 4
Я обнаружил, что комментирование моих CSS и таргетинг на теги HTML vs "class1, myselector27 и т.д." сделано для гораздо меньшего количества кода и проще читать позже. Если у меня есть событие JavaScript, которое необходимо изолировать, я переношу этот компонент в id
и соответствующим образом комментирую базовый файл CSS.
reset.css
fonts.css
main.css
main.css
/*
** Image Slider for products.php
*/
#slider_products {...}
#slider_products #slide_container {...}
#slider_products h1, p {...}
#slider_products img {...}
Если вы используете IDE (например, NetBeans), эти комментарии могут быть сделаны видимыми (и при необходимости вы можете написать как можно больше описательного текста)
Я поддерживал файлы CSS для сайтов с более чем 200 страницами контента, а также с 20 страницами. В любом случае мои файлы CSS никогда не были в диапазоне 1200 строк кода, который я видел на сайте портфолио друзей (без имен:-)), но его сайт - @best 20-30 страниц - Все из них имеют одинаковый дизайн, стиль, внешний вид - OVERKILL. Нужно полагать, что если CSS и код должны быть расчесываны - через эти 1200 строк можно значительно сократить довольно быстро.
Ответ 5
Есть несколько вещей, которые вы можете сделать.
-
Поместите CSS в таблицу стилей по порядку страницы. Таким образом, стили заголовков вверху, затем основные стили содержимого, затем стили нижнего колонтитула. Ниже вы можете добавить дополнительные стили для определенных целей.
-
Используйте комментарии в своих стилях, например.
/* ### Styles for Links in Main Content #### */
-
Используйте отдельные таблицы стилей для отдельных разделов, если CSS достаточно велик. Итак, если у вас есть раздел сайта, который имеет дело с определенной темой, и он имеет значительные модификации стиля, дайте ему свою таблицу стилей и ссылайтесь только на нее в этом разделе.
-
Используйте каскад мудро и сократите количество css, которое вы пишете. Простой пример: http://csswizardry.com/toybox/use-the-cascade/