Каков наилучший подход к CSS-инфраструктуре приложения Enterprise Cloud?

Существует несколько способов стилизации элементов на каждой странице, в корпоративных приложениях обычно размер CSS Framework увеличивается примерно на 1 МБ, а когда ваши пользователи используют медленное подключение к Интернету, вы должны уменьшить рамки css размер.

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

<div id="blah" class="blah"></div>

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

<div id="blah" class="margin10 padding20 bg-color-red fg-color-white text-bold else"></div>

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

Ответ 1

Размер файла

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

Кроме того, у вас будет время для изучения некоторых других методов, таких как загрузка критического "выше складки" css в его собственный, оптимизированный файл; и расщепление файлов css вверх, чтобы общий материал загружался в первый просмотр страницы, но на каждую страницу загружался любой материал для конкретной страницы, поскольку он был посещен (для записи это может быть очень хорошо для вышеупомянутых целей PPC).

CCS Tricks более подробно описывает здесь и здесь.

Сложность

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

Все очень хорошо, если вы можете загружать страницу на 0,1 с меньше, но если вам понадобится 30 минут, чтобы сделать каждое простое редактирование css, у вас возникнут проблемы.

Моя рекомендация

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

Например:

.blue-box

.header-login-box

.contact-form-submit .green-button

bad: не семантический, или слишком контекстный. Я предполагаю, что .blah довольно сильно попадает в эту категорию, судя по фразе "сделайте это для каждого элемента".

.login-box

лучше: проще повторное использование, семантическое, но все же слишком контекстуальное

.box--highlighted

.button

.button--standout

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

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

Также полезно использовать служебные классы, такие как .pull-left на самом деле, Гарри Робертс в CSS Wizardry, успешный консультант, который сделал этот материал в дикой природе для реальных клиентов рекомендует его.

Три дополнительных направления исследования

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

BEM: docs вводная статья

OOCSS: docs вводная статья

SMACSS: документы и введение

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

Ответ 2

Я думаю, что правильный ответ: "Найдите счастливого и поддерживаемого внутри Betweener".

Модульный подход

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

Подход "use-css-properties-as-css-classes"

У вас может возникнуть соблазн использовать этот подход, поскольку он дает вам большую гибкость для ваших элементов на странице. Проблема заключается в повторном использовании. Если вы определите, что определенный компонент должен всегда иметь свой заголовок, заданный как "жирный". Ожидаете ли вы применять класс "text-bold" каждый раз, когда вам нужно использовать этот компонент? Это может стать ночным кошмаром для обслуживания, и я буду использовать его только для исключений.

Подход, основанный на модуле с вариациями

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

Затем ваш код CSS будет жить в следующей структуре:

Большинство работ CSS, инкапсулированных модулями/компонентами пользовательского интерфейса (пространство имен CSS)
Некоторые или несколько вариантов CSS для ваших компонентов пользовательского интерфейса.
Собственные CSS-классы для исключений и специфических для страницы вариантов

Советы

Загрузите исходные коды из существующих фреймворков CSS, таких как Twitter Bootstrap, и изучите, как они повторно используют CSS для разных компонентов пользовательского интерфейса.
Рассмотрите возможность использования предварительно скомпилированных CSS, таких как LESS или SASS, поскольку вы можете использовать функции и переменные.
Используйте короткие имена css для имен компонентов (чтобы они не раздували ваш окончательный файл CSS
минимизировать и gzip ваши файлы css.

<сильные > Примеры

Классы CSS

/* Panel Component */
.panel {
    width: 100%;
}
.panel-content {
    padding: 10px 20px;
}

/* Panel variations*/
.panel-success {
    background-color: #3F3;
}
.panel-with-icon .panel-content {
    padding-left: 50px;
}

/* Exceptions (Helpers) */
.pull-right {
    float: right;
}
.margin-top-20 {
    margin-top: 20px;
}

Использование HTML

<div class="panel">
    <div class="panel-content">
        Simple panel
    </div>
</div>

<div class="panel panel-with-icon">
    <div class="icon">
        my great icon
    </div>
    <div class="panel-content">
        Panel with icon
    </div>
</div>

<div class="panel panel-success margin-top-20">
    <div class="panel-content">
        My successful panel with page specific tweaks
    </div>
</div>

Надеюсь, это поможет вам.

Ответ 3

Я всегда придерживаюсь второго подхода, потому что:

1. Легче поддерживать, вы никогда не знаете, когда будете редактировать свои страницы. Например, если вы даете своим элементам класс my-color, и вы хотите изменить его через некоторое время, все, что вам нужно сделать, это перейти в ваш файл css и изменить цвет my-color, представьте время сохранения и Конечно, время означает деньги.

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

3. Вы можете сделать свою .css-структуру один раз, а затем повторно использовать в каждом проекте. Вам придется только изменить стиль. Например, вы можете иметь .my-color в каждом проекте с другим стилем. Вместо того, чтобы делать это с нуля каждый раз.

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

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

Цитата из http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/

Этот подход называется OOCSS= Object Oriented Cascade Style Sheet, но пока он не считается лучшей практикой, но он развивается.

Здесь вы можете прочитать здесь

http://oocss.org/

http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/