Подтвердить что ты не робот

Как документировать CSS для большого сайта

Мы поддерживаем довольно большой сайт с большим количеством страниц. По мере роста страниц, так же как и HTML и CSS. Есть ли хороший способ документировать эти данные? Как на какой странице используется определенный селектор и т.д. Какая наилучшая практика для поддержки CSS для большого сайта?

4b9b3361

Ответ 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/