Что такое хорошая стратегия CSS? [закрытый]

24
задан Ben Voigt 20 August 2015 в 04:07
поделиться

13 ответов

Я думаю, что наилучший вариант состоит в том, чтобы разделить 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

17
ответ дан netadictos 28 November 2019 в 23:37
поделиться

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

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

Редактирование: Yahoo компрессор YUI , кажется, лучший minifier вокруг. Это может сжать и CSS и JavaScript.

7
ответ дан Greg 28 November 2019 в 23:37
поделиться

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

Основанный на свойстве

самая основная, представительная форма основанного на свойстве разрыва должна была бы использовать две таблицы стилей: 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 как Дерзость . Это позволяет автору CSS повреждать одну таблицу стилей во многих, все еще только представляя одну таблицу стилей браузеру. Это добавляет шаг к CSS авторский рабочий процесс (хотя это могло потенциально быть задано сценарием для компиляции Дерзости в CSS любое время, файл Дерзости обновляется), но это может стоить, особенно при рассмотрении некоторых многих других преимуществ Дерзости.

13
ответ дан gregnostic 28 November 2019 в 23:37
поделиться

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

1
ответ дан Thomas Hansen 28 November 2019 в 23:37
поделиться

Мое решение, среди много:

  • 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.

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

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

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

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

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

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

2
ответ дан hlfcoding 28 November 2019 в 23:37
поделиться

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

Делят Ваш 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 для нахождения ненужных селекторов. Это звонило Пыль - Меня Селекторы .

1
ответ дан Chris Hawes 28 November 2019 в 23:37
поделиться

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

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

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

0
ответ дан dove 28 November 2019 в 23:37
поделиться

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

Лучшие практики oftern струя, не имеющая JavaScript на странице, но как внешние файлы (как с css). Но если у Вас будет .js файл на страницу тогда, то вещи будут медленно выходить из-под контроля.

0
ответ дан Owen 28 November 2019 в 23:37
поделиться

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

0
ответ дан Philip Morton 28 November 2019 в 23:37
поделиться

Глобальные css файлы вызвали меня головные боли прежде. CSS обычно не является namespaced, поэтому если два различных модуля создают отделение с классом "поля", то намерение каждый перезаписывает другой. Кроме того, стили на тег, [p] тег и другие основные теги (т.е. стили не на основе классов или идентификатор) разрушит опустошение на сторонних средствах управления, поскольку Ваш лист глобального стиля располагается каскадом на компонент HTML, который был разработан, не приняв никакой другой css на странице. Несоответствующее использование текста, центрирующегося для центрирования элементы, может привести к трудно для отладки глобального центрирования. Таким образом, я одобряю несколько css файлов. Я видел css менеджеров (http модули, которые объединяют css вместе во время запроса), но решил, что дополнительные запросы HTTP определенно стоят ограничить объем повреждения, плохо полагал, что css может сделать к моему приложению.

0
ответ дан MatthewMartin 28 November 2019 в 23:37
поделиться

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

А именно, захватите название controller+action, называют и встраивают это как идентификатор в представлении, выражаются на теге основного текста или Вашем отделении основного содержания

<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, у Вас есть что-то как [1 111]

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 никакой другой страницы, потому что каждая страница ограничена по объему ее именем метода.

0
ответ дан Cody Caughlan 28 November 2019 в 23:37
поделиться

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

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

0
ответ дан Brian Clozel 28 November 2019 в 23:37
поделиться

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

0
ответ дан VirtuosiMedia 28 November 2019 в 23:37
поделиться
Другие вопросы по тегам:

Похожие вопросы: