Что такое хорошая стратегия CSS?

Думаю, лучший вариант - разделить css на:

-layout.css

-content.css

Затем, если вам нужно что-то более конкретное, вы можете добавить больше, например CSS для рекламы: ads.css или один CSS для определенного раздела.

Я бы также добавил ie.css для взлома IE css.

Я бы не стал говорить о создании одного CSS только для одной страницы: проблема, которая может возникнуть, если вы используете слишком много CSS, заключается в том, что вашей странице придется делать больше запросов к серверу, и это замедлит вашу страницу. Вот почему я рекомендую вам реализовать HttpHandler, который будет создавать копию кеша только в одном файле css, который вам нужен в данный момент. Смотри сюда: http://blog.madskristensen.dk/post/Combine-multiple-stylesheets-at-runtime.aspx

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

Кроме того, рассматривали ли вы использование тем и файлов скинов в asp.net? Комбинация .css и .skin может значительно уменьшить общий размер вашего CSS, что незначительно хорошо для производительности, но очень хорошо для упрощения администрирования.

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

То же самое и с файлами JavaScript. Если ваш сайт сильно зависит от Ajax до такой степени, что почти на каждой странице требуется какой-то пользовательский Javascript, тогда вы все это придерживаетесь?

Лучшие практики - это не javascript на странице, а внешние файлы (как с css). Но если у вас есть файл .js на странице, ситуация постепенно выйдет из-под контроля.

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

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

Обновлено: Yahoo Компрессор YUI кажется лучшим минификатором. Он может сжимать как CSS, так и Javascript.

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

Разработайте несколько простых правил, которые работают для вас (или вашей компании).

Разделите свой CSS на отдельные файлы, например:

layout.css
content.css
menu.css
typography.css

Решите, какие объявления будут помещены в каждый файл, например, убедитесь:

font-weight, text-decoration, font-family

и

h1, h2, h3, h4, h5, h6, a, p, li

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

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

Сделайте отступ в CSS, например:

#logo h1 {text-indent: -9999px}
     #logo h1 a {display: block; width: 200px; height: 98px; backround...}

Прокомментируйте свой CSS, включая ссылки на другие файлы, если там находится другое правило для этого конкретного селектора.

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

Убедитесь, что каждый разработчик хорошо осведомлен о вашем стандарте CSS.

Кроме того, что несколько уместно, я только что узнал о плагине Firefox для поиска ненужных селекторов. Он называется Селекторы Dust-Me.

Я не уверен насчет эквивалентов Windows, но на Mac вы можете получить CSSEdit, который позволяет вам добавлять папки в файлы CSS и управлять ими таким образом. Хорошее объяснение этому есть в эта статья.

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

На основе собственности

Самая простая и репрезентативная форма разделения на основе свойств - использование двух таблиц стилей: structure.css и style.css. Файл structure.css будет содержать правила, которые используют только такие свойства, как высота, ширина, поля, отступы, плавание, положение и т. д. Он будет фактически содержать «строительные блоки», необходимые для упорядочивания элементов страницы так, как вы хотите. Файл style.css будет содержать правила со свойствами, такими как фон, шрифт, цвет, оформление текста и т. д. Это эффективно действует как обложка для структуры, созданной в другой таблице стилей.

Дополнительное разделение может включать использование файла typography.css, в котором вы разместите все свойства шрифта. Или файл colors.css, в который вы поместите все свои свойства цвета и фона. Постарайтесь не переусердствовать, потому что этот метод быстро становится больше проблем, чем он того стоит.

На основе структуры

Структурный метод разделения таблиц стилей основан на разделении правил в зависимости от того, к каким элементам они применяются. Например, вы можете увидеть файл masthead.css для всего в заголовке, файл body.css для всего в области содержимого страницы, файл sidebar.css для всего на боковой панели и файл footer.css для все внизу страницы.

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

Гибридный

Как и следовало ожидать, гибридный метод сочетает в себе лучшее из обоих методов, и это мой предпочтительный выбор. Здесь вы создаете файл structure.css, как и в методе на основе свойств, используя только те свойства, которые вам нужны для создания базового макета. Затем вы создаете дополнительные таблицы стилей, такие как masthead.css, которые скроют заголовок; body.css, который сканирует контент; и т.п.

Прочие соображения

Одна проблема, которая преследует каждый из этих методов, заключается в том, что при создании нескольких таблиц стилей вы требуете, чтобы браузер клиента извлекал много файлов. Это может негативно повлиять на взаимодействие с пользователем, поскольку большинство браузеров будут делать только два одновременных запроса к одному и тому же серверу. Если у вас семь таблиц стилей, это означает добавление потенциально сотен миллисекунд при начальной загрузке страницы (этот эффект уменьшается после кэширования таблиц стилей, но вы хотите произвести хорошее первое впечатление на этих новых посетителей). По этой причине была создана техника CSS-спрайтов. Разрушение таблиц стилей может свести на нет все достижения, достигнутые с помощью спрайтов.

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

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

Глобальные файлы css и раньше вызывали у меня головную боль. CSS обычно не имеет пространства имен, поэтому, если два разных модуля создают div с классом «box», то намерение одного заменяет другой. Кроме того, стили в теге [a], теге [p] и других базовых тегах (т. Е. Стили, не основанные на классах или идентификаторах) нанесут ущерб сторонним элементам управления, поскольку ваша глобальная таблица стилей каскадируется на компонент html, который был разработан с учетом других css на странице нет. Неправильное использование центрирования текста для центрирования элементов может затруднить отладку глобального центрирования. Поэтому я предпочитаю несколько файлов css. Я видел менеджеры css (http-модули, которые объединяют css вместе во время запроса), но решил, что дополнительные http-запросы вполне оправдывают ограничение объема ущерба, который, как считается, css может нанести моему приложению.

Мы используем Ruby on Rails, поэтому у нас есть четкая пара контроллер / действие, мы используем ее для ссылки как на классы CSS, так и на представления Javascript.

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

<body id = "users_list_body">

Где «пользователи» - это имя контроллера, «список» - это действие. Тогда в вашем CSS есть правила вроде

#users_list_body

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

В конечном итоге у вас будут такие правила

  #users_list_body table 
  #users_list_body table thead 

Сделайте то же самое для Javascript. Итак, в нижнем колонтитуле каждой страницы вы берете ту же пару имени контроллера / действия и встраиваете ее в вызов функции.

 //javascript
 if (V.views.users_list) { V.views.user_list(); }

Затем во внешнем Javascript у вас есть что-то вроде

V = {};
V.views = {};
V.views.user_list = function() {
  //any code you want to run for the Users controller / List action..
  //jQuery or something
  $('#save_button').click({ ... });
}

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

Каким бы ни был ваш выбор, избегайте использования директивы @import.

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

Мое решение среди множества:

• base.css / reset.css: ваш фундамент {базовый макет, тип, цвет} - 100% возможность повторного использования
• helper.css: основные правила компоновки для модулей, а также «служебных классов» {варианты сетки, формы, таблицы и т.д.} - возможность повторного использования 90 +%
• module.css: сложные правила компоновки для модулей {семантические модули, такие как .post или .comment} - возможность повторного использования 75%
• layout.css: правила на основе шаблонов {#hd, #bd, #ft, #homePage и т. д.} - повторное использование практически невозможно
• color.css: все правила цвета, вместе - возможность повторного использования 50%
• type.css: все правила типов, вместе взятые - повторное использование 75% (стили текста имеют меньше вариаций)
• это разделение также позволяет использовать мобильные и печатные версии листов макета, которые контролируются @import через таблицу стилей, которую я связываю с html.

Я использую это для сайта среднего размера. Для дополнительной организации я делаю каждый лист в основном одинаковым {оболочка, общий, уникальный и т. д.}. Я также помечаю свои селекторы и свойства, а также делаю их отступ в порядке зависимости внутри одной и той же группы селекторов, поэтому я знаю, на какие правила я ссылаюсь или расширяю. Эта структура допускает практически бесконечное расширение, сохраняя при этом порядок, понятность и возможность многократного использования. Месяц назад мне пришлось реорганизовать файл master.css из 7000 строк, так что это новая система, которую я пробую. Я обнаружил, что 100% -ный контентно-семантический CSS не такой масштабируемый и простой для понимания, как гибрид семантики / макета, поскольку CSS в любом случае используется для этого.

1,25 года спустя править: Другой способ, который может быть более актуальным, - это просто использовать хороший текстовый редактор CSS. Я уверен, что VS - дерьмо для работы с CSS, если только вы не столкнетесь с некоторыми расширениями. Если вы работаете в Windows, попробуйте Электронный текстовый редактор, b / c это порт TextMate для Windows, и в нем есть пакеты, разработанные для CSS и разметки, которые обеспечивают лучшую подсветку синтаксиса и автозаполнение. Затем вы можете организовать даже таблицу стилей из 8000 строк в складные складки:

/** Start Module 1 */
[css]
/* End Module 1 **/

И используйте список символов, чтобы отобразить вам быстрое оглавление на лету с запросом типа Start или Module 1. Он также индексирует строки с помощью /** these types of comments **/ (отлично подходит для маркировки областей) и всех цепочек селекторов CSS. У вас не должно возникнуть проблем с работой с отдельными большими файлами с помощью E. Кроме того, если вы постепенно не улучшаете свой CSS, все равно все будет уменьшено. Я бы также сделал отступ в вашем CSS, чтобы имитировать структуру раздела DOM, на который он ссылается.

.container {}
    .container .inner {}
        .container .head {}
    .container .inner.alt {}

В противном случае я согласен с методом «1 базовый CSS и 1 страница / раздел CSS», хотя он полностью зависит от требований вашего бизнеса.

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