Как удалить CSS спагетти в устаревшем веб-приложении?

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

Как вы переходите от устаревшего беспорядка CSS к очищенным, красиво каскадным, СУХИМЫМ таблицам стилей?

Приложение, над которым я сейчас работаю, имеет 12000 строк CSS. Он вырос до этого размера органично, так как на ранних этапах не было никаких стандартов или пересмотра CSS, единственное правило состояло в том, чтобы приложение соответствовало дизайну. Некоторые из проблем, которые мы постоянно имеем:

  • Противоречивые стили: один разработчик добавляет.header { font-weight: bold;}, но.header уже использовался в других модулях и не должен быть жирным в них.

  • Каскадные проблемы: виджет Foo имеет.header, но он также содержит список виджетов Bar с классами.header.

    • Если мы определим.foo .header { ... } и.bar .header { ... }, то все, что явно не перезаписано в foo, будет отображаться в строке.
    • Если мы определяем.foo > .header и.bar > .header, но позже нам нужно изменить foo, чтобы обернуть заголовок в div, наши стили ломаются.

  • Проблемы наследования, мы постоянно переопределяем шрифты виджетов до 11px/normal, потому что некоторые верхние контейнеры используют высоту строки 12px / 18 px.

  • Борьба с библиотеками виджетов с использованием таких библиотек, как dojo/dijit или jquery ui, которые добавляют функциональность тоннам стилей, означает, что в нашем коде много мест, где мы должны переопределить стили библиотек, чтобы все выглядело правильно. Есть ~2000 строк CSS только для настройки встроенных стилей dijit

Мы находимся в точке, где мы думаем о реализации следующих правил:

Пространство имен всех новых классов виджетов - если у вас есть виджет foo, все имена подклассов будут.foo_, поэтому мы получаем:.foo,.foo_header,.foo_content,.foo_footer. Это делает наш css по сути FLAT, но мы не видим другого способа организовать наш код дальше, не сталкиваясь с устаревшими стилями или каскадными проблемами, которые я упоминал выше.

Универсальные стили полиции - есть небольшая группа универсальных классов, которые можно применять только в очень специфических ситуациях. например,.editable - применяется к частям предложения, которые должны вызывать редактор - должен содержать только текстовые узлы.

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

Как еще мы можем перейти от CSS-беспорядка, который постоянно вводит регрессии, к чему-то поддерживаемому в будущем.

Источник

2 ответа

Решение

Мы используем руководство по стилю в виде простой HTML-страницы с примерами каждого правила CSS в таблице стилей. Очень просто определить, добавляете ли вы новое несовместимое правило, поскольку примеры выровнены друг над другом.

Пример мне нравится: http://getbootstrap.com/components/ (добавлено 2015)

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

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

Как вы переходите от устаревшего беспорядка CSS к очищенным, красиво каскадным, СУХИМЫМ таблицам стилей?

Используйте руководство по стилю в качестве модульного теста. После того, как вы получили в нем основные части: уменьшите, проведите рефакторинг и объедините (вы, скорее всего, столкнетесь с .campaign_1 span а твои обычные правила, наследство может быть твоим другом).

Противоречивые стили: один разработчик добавляет.header {font-weight: bold;}, но.header уже использовался в других модулях и не должен быть жирным в них.

В ответ на комментарий Адриано Вароли Пьяццы и цитату выше: я не вспоминаю это как проблему, полностью принадлежащую CSS, но больше к разметке HTML. Независимо от того, что вы делаете, это будет тяжелый подъем. Решите, какое правило вы хотите сохранить, и примите меры, чтобы вычистить менее использованные; например: через наследование: #news a .header { ... } или переименование HTML-класса a .stand_out_header { ... },

О следующей идее

Пространство имен всех новых классов виджетов - если у вас есть виджет foo, все имена подклассов будут.foo_, поэтому мы получаем:.foo,.foo_header,.foo_content,.foo_footer. Это делает наш css по сути FLAT, но мы не видим другого способа организовать наш код дальше, не сталкиваясь с устаревшими стилями или каскадными проблемами, которые я упоминал выше.

Вместо этого используйте содержащий элемент, который будет гораздо проще поддерживать:

<div id="widget_email">
  <h2>One type of h2</h2>
</div>
<div id="widget_twitter">
  <h2>Another h2</h2>
</div>
Источник

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

  • общие CSS для всех страниц
    • CSS для страниц в разделе A
    • CSS для страниц в разделе B

Так что если вы найдете .header модификация, которую вы добавили в общий CSS, работает в A, но не в B, вы просто перемещаете ее в нижний CSS-файл.

Да, это подразумевает больше файлов для загрузки. Есть способы обойти это с серверными языками, такими как чтение всех файлов с помощью php и отправка только одного блока контента.

Источник
Другие вопросы по тегам