Большие команды разработчиков не могут обработать одну таблицу стилей CSS?

Question

В настоящее время я работаю в 5-7 крупных командах разработчиков, создающих действительно большой веб-сайт с большим количеством страниц и функций.

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

Это полный беспорядок.

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

Допустим, вы забыли о безумном большом CSS и определили CSS для каждого элемента.вместо.Поэтому каждый раз, когда вы визуализируете GreenBuyButton, на нем отображается «style = 'bla bla bla'".И это в значительной степени сделано для всех элементов.

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

Может ли это быть хорошей идеей или как работают действительно большие команды?один сайт делать с CSS, чтобы избежать беспорядка?

Answer 1

Почему бы вам не создать несколько листов CSS в зависимости от области сайта?

• blog.css
• accounts.css
• shopping.css

Тогда у вас может быть серверный скрипт (скажем, PHP), объединяющий весь CSS в 1 лист, который даст вам тот же результат, что и 1 небольшой файл (также можно использовать минимизатор).

Проверьте свой сайт с помощью средства проверки CSS, чтобы найти дубликаты (определенные css) и управлять им таким образом.

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

Answer 2

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

.user-list .p {
    font-size: 11pt
}

.login-screen .p {
   font-size: 12pt
}

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

Answer 3

Измените то, как вы пишете CSS.

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

Соблюдайте некоторые правила.Мол, «Все <ul> имеют особый вид для этого проекта».Если вы хотите стилизовать элемент несколькими способами, начните использовать классы.Это сохранит ваш веб-сайт единообразным.Однородность уменьшает неправильную компоновку.

Создание классов строительных блоков, таких как "каркас".Это помогало мне так часто, что я никогда не начинал проект, не сделав этого сначала.Взгляните на структуру jquery-ui themeroller, чтобы дать вам идею.Вот пример:

.icon        { display:block;width:16px;height:16px;}
.icon-green  { background:url(/green.png);}
.icon-blue   { background:url(/blue.png);}

Затем на элементах:

<span class="icon icon-green"></span>
<span class="icon icon-blue"></span>

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

ОБНОВЛЕНИЕ:

Вот пример того, как я использовал этот метод: Movingcost.com .Огромный сайт, несколько разных разделов и страниц, и только 252 строки несжатого CSS.На самом деле, в эти дни я разбиваю все дальше, чем в проекте по переезду.Вероятно, я бы просмотрел эти элементы в нижней части таблицы стилей и выяснил, как объединить некоторые из них в классы.

Answer 4

Несколько CSS-файлов и объединение в коде

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

2. Не вставляйте стили в HTML. Ремонтопригодность, а также множество царапин на голове, почему некоторые вещи не отображаются должным образом, будут очень плохими.
3. Имейте один (или несколько из них) глобальный CSS, который определяет стили для глобальных частей. Обычно определяет все в шаблоне / мастер. Может быть привязан к главной странице или к общим элементам управления, используемым на большинстве страниц.
4. Иметь CSS-файлы для каждой страницы / элемента управления, когда они действительно нужны. Большинству страниц они не понадобятся, но разработчики могут написать их
5. Хорошо структурируйте эти файлы в папках
6. используйте правила именования и форматирования, чтобы каждый мог писать / читать код
7. Напишите код на стороне сервера, который объединит несколько CSS-файлов в один для сохранения полосы пропускания.

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

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

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

Answer 5

Мой любимый трюк с переопределением - назначать атрибут id на <body> каждой страницы.Это простой способ внести изменения, относящиеся к конкретной странице, без выделения отдельного файла таблицы стилей.

Вы можете использовать следующий html

<body id="home">
  <h1>Home</h1>
</body>

<body id="about">
  <h1>About</h1>
</body>

и использовать следующие переопределения css

h1 {color: black}
#about h1 {color: green}

Домашняя страница получает css по умолчанию, в то время как about переопределяется.

Answer 6

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

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

Answer 7

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

Стивен коснулся очень сильной стороны CSS.Вы можете назначить несколько классов для элемента.Вы должны определить некоторые основные правила, которые «обычные» разработчики не могут коснуться.Они обеспечат согласованность через сайт.Затем разработчики могут назначить дополнительный класс для персонализации любого свойства.Я бы не назначил более двух классов: глобальный и персонализированный.

Учитывая, что у вас в руках уже есть эта огромная таблица стилей, я не уверен, как вы выберете, кто из 7 разработчиков выберетнадо сесть через месяц и организовать его.Это, вероятно, будет трудной частью.

Answer 8

Ответ есть в названии. Причина, по которой это называется каскадными таблицами стилей, заключается в том, что несколько могут быть объединены, и существуют определенные правила, по которым вы предпочитаете.

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

Вот мои предложения:

• используйте один CSS-файл для основного вида сайта. Этот файл CSS написан людьми, занимающимися в основном дизайном, и в результате сайт выглядит непротиворечивым. Он определяет основные цвета, макет и тому подобное.
• использовать другой файл CSS для каждого раздела. Например, в разделе «покупки» будут использоваться компоненты, которых больше нет на сайте. Используйте это, чтобы определить специфичные для раздела вещи
• Поместить стилевой стиль непосредственно на страницу (в заголовок). Если этот раздел становится слишком большим, вы делаете что-то не так
• нанесение исключительного стиля непосредственно на компоненты. Если вы делаете одно и то же три раза, абстрагируйте его и используйте вместо него класс.
• мудро выбирайте свои классы и используйте семантику для именования. selectedSalesItem ' хорошо ' greenBold ' плохо
• если разработчик меняет правило стиля и оно нарушает остальную часть сайта, зачем ему это нужно? Либо это исключительная вещь для того, над чем он работает (и должен быть вписан), либо это было в основном сломано и на остальной части сайта, и все равно должно быть исправлено.

Если ваши CSS-файлы становятся слишком большими для обработки, вы можете разделить их и объединить на стороне сервера, если хотите.

Answer 9

Использование таблиц стилей на больших сайтах - отличная идея. Однако, это действительно работает только тогда, когда вы применяете стандарты вашей команды к стилю. Имеет смысл иметь отдельный шаблонный контроллер, который связывает ваши таблицы стилей. Также имеет смысл назначить кого-то в команде «хранителем стиля», который должен пройти все изменения в таблице стилей, прежде чем вносить существенные изменения.

Как только стандарты стилей согласованы и определены, тогда все элементы управления на сайте должны реализовывать определенные стили. Это позволяет разработчикам выйти из бизнеса кодирования в стиле и просто кодирования в соответствии со стандартом. Входные данные - это входные данные, абзацы - это абзацы, а плавающие div - это головная боль.

Ключ - это стандартизация в команде и соответствие всем разработчикам. В настоящее время я возглавляю групповой сайт, который имеет более 30 таблиц стилей, чтобы контролировать все для макета, шрифтов, отображения данных, всплывающих окон, меню и пользовательских элементов управления. У нас нет ни одной из этих проблем, потому что разработчикам очень редко нужно редактировать таблицу стилей напрямую, потому что стандарты четко разработаны и опубликованы.