Универсальные и специфические стили элементов - для удобства обслуживания

Question

Рассмотрим следующие три сценария ...

Сценарий A

@import "reset.css";
/* ... */
p {margin:1em 0;}
/* ... */
p#copyright {margin:0; padding:10px;}

В Сценарии A правило общего типа применяется квсе элементы <p>, которые дают ему верхнее и нижнее поля, чтобы абзацы правильно располагались при использовании в HTML.Но при этом это приводит к случаям, когда элементу <p> теперь необходимо удалить его общие поля для декоративных целей, например, у авторского права в нижней части документа не должно быть полей.

Сценарий B

@import "reset.css";
/* ... */
div.content_body p,
div.sidebar_body p {margin:1em 0;}
/* ... */
p#copyright {padding:10px;}

В сценарии B предполагается, что элементам <p> не нужны верхние и нижние поля, если только явно не определено .Здесь элементам контента и боковой панели потребуются хорошо расположенные абзацы

сценарий C

@import "reset.css";
/* ... */
p.spaced {margin:1em 0;}
/* ... */
p#copyright {padding:10px;}

В сценарии C только <p> элементы с классом spacedбудут применены верхний и нижний поля.

Вопросы:

Какой сценарий лучше использовать и, что более важно, почему?Какое влияние оказывает каждый сценарий на:

• производительность CSS браузера
• вес CSS и удобство обслуживания
• распространение дефектов пользовательского интерфейса

Если вам нужно было добавить новый виджет, в котором требовались текущие абзацы, какой сценарий был бы лучше для вас?

Спасибо!

Answer 1

Я стараюсь следовать принципу, согласно которому неукрашенные селекторы (например, «p») должны обеспечивать разумные значения по умолчанию, а затем использовать более специфические селекторы для переопределения этих значений по умолчанию. Я думаю, что это лучше всего представлено сценариями A и B .

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

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

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

1. Чем меньше специализированных специализированных классов, тем легче "попасть в пропасть успеха", потому что простейшая вещь, которую вы пишете (<p>Whatever</p>), просто сработает.

2. Чем больше специализированных классов , тем больше вероятность того, что вам понадобится попрактиковаться в программировании копирования / вставки для обеспечения согласованного использования разметки.

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

Answer 2

Общий, потому что сначала лучше разрешить все, а потом блокировать несколько. :)

Answer 3

Это полностью зависит от дизайна вашего сайта.

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

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

Что касается подхода в C, то меня больше всего беспокоит то, как генерируется HTML для сайта. Если он генерируется серверной системой, эта система должна знать, какие абзацы должны быть разнесены, а какие - нет. Это дополнительная сложность для системы или ее пользователей.

Для конкретного примера абзацев у меня часто получалось что-то вроде B. Легко предположить, что у абзацев должен быть какой-то приятный, приличный стиль, который бы сделал, скажем, статью приятной для чтения. Но если вы посмотрите на большинство современных веб-сайтов, большая часть того, что находится на странице, не похожа на это: это меню и боковые панели и особые мелочи. Теперь, это может быть не очень хорошо, с точки зрения дизайна, но если вы реализуете подобный дизайн, B - это способ сделать это с меньшим количеством кода, а меньшее количество кода обычно означает меньший вес, простоту обслуживания и меньше дефектов.

Answer 4

D Ничего из вышеперечисленного

@import ""; // don't need this
p { } // don't need this
ul#footer li { padding: 10px }

• Производители браузеров знают очень много о своей технологии, в частности, о типографии и верстке в целом. «Сброс» - отличный способ избавиться от всего этого накопленного опыта. Поведение браузера по умолчанию - это хорошо, и его следует перезаписывать только в исключительных случаях. Различные браузеры do выглядят немного по-разному. Это неплохая вещь. Смотри: http://dowebsitesneedtolookexactlythesameineverybrowser.com/

• Ссылка на авторское право не является абзацем текста. Это вероятно один из нескольких пунктов в списке подтверждающей информации о рассматриваемой странице. Если нет, то это список из одного.

Answer 5

Лично я предпочитаю сценарий А. Я нахожу, что если вы поступите так, вы сможете максимально использовать каскад. Вопрос, который вы должны задать себе, - это "какой разумный дефолт?" Это означает, что более вероятно, что p потребуется интервал, или, скорее всего, это не так. Это должно помочь вам определить, какими должны быть ваши стандартные настройки по умолчанию. Вообще говоря, ответ на этот вопрос приведет вас в соответствие со сценарием А.