Странное ограничение IE на количество внешних CSS

[arestov]

бедные пользователи

[brutaler]

бедные разработчики

[Delka]

есть такая проблема,
про неё pepelsbey рассказывал на UAWeb.

лечится подключением css-файлов, внутри которых подключаются ещё css-файлы.
Т.е. допустим у вас 40 css импортируются, нужно разбить их на несколько групп, и сделать css-файлы для этих групп с @import внутри.

[sunnybear]

да, в Яндексе на это первыми напоролись :)

[vithar]

Не первыми, в инете потом находили, но напарывались и до сих пор напарываемся регулярно. Впрочем, мы почти решили для себя этот вопрос. Пока не скажу как.

[sunnybear]

рискну предположить, что собирается «полу-статическая» версия CSS, которуб можно со спокойно душой править. Она затем нормально в SVN сохраняется по всем файлам, а на боевой сервер уходит версия, собранная уже по другим правилам из SVN

Т.е.

SVN <-> Подготовленная тестовая версия  -> SVN -> подготовленная боевая версия

[vithar]

Исходник, который можно править всегда должен быть один. Точнее у нас это сотни мелких файлов.

[itlife]

По моему там с путями начинается проблема по разным браузерам… одни смотрять путь относительно файла с html в независимости от того где лежит css в котором @import, а другие всегда берут файлы css считая путь от файла css в котором @import…

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

[pulev]

а по моему не Макеев это был :-)

[cogonet]

угу, по моему это был Виталий Харисов )

[BoltThrower]

Оох мать… Напишите пожалуйста книжку «Веб-разработка. Как делать не надо».
На мой взгляд «подключением css-файлов, внутри которых подключаются ещё css-файлы» не та проблема лечится, ибо не в браузере она :) Все вполне неплохо лечится подключением головы.

[cogonet]

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

[BoltThrower]

Можно пример где это будет оправдано?

[BVadim]

habrahabr.ru/css/main.css

2911 строк. Лично мне, при разработке подобного объёма было бы удобнее разбить его на много маленьких логически раздельных файлов.

[DerSpinner]

а есть ли статистики по остальным «браузерам»?

[vithar]

Более того, у него ещё уровень вложенности больше 3-х не понимается. И максимальный размер CSS что-то типа 260Кб.

[FloppyFormator]

то есть, 31^3 + 31^2 + 31 — максимальное количество внешних CSS-файлов? :)

[ruskar]

Вам недостаточно?

[Odes]

30783 CSS-файлов — такие монстры существуют?????

[kellas]

как вариант собирать их php скриптом в один файл.

[homm]

А еще у него лимит 20 куков на страницу.

[homm]

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

[zotov]

У Firefox — 50. У Opera — 30.

Только не на страницу, а на весь сайт, даже с учетом разной видимости. То есть если одна кука ставится на /dir1/, вторая на /dir2/ и браузер всегда передаёт серверу только одну куку, то их все равно может быть только 50 (или 30, или 20).

При превышении лимита у Firefox и Opera выталкиваются предпоследняя кука (последовательность типа: 1, 2,… 49, 60)

В MSIE выталкиваются самые первые (2,3,… 22, 23)

[zotov]

Туго с арифметикой :)
В последней строке: 4,5,… 22, 23.

[theRavel]

Как можно пользоваться IE…
Хотя, конечно не спорю, разработчик должен тестировать этот браузер…

[BVadim]

ситуация довольно часто может встречаться на больиших проектах где над вёрсткой работает не один человек или дизайн нетривиальый и требует большого количества цсс. Хранение стилей в одной куче при разработке лично у меня затрудняет восприятие. Для разработки привычнее когда код влезает на 1 экран и разбит на логические части. Но тут уж кому как удобнее.

[apelsyn]

У меня тоже была похожая проблема. Решил «интелектуальной» автосбивкой всего в один css. Проверка осуществляется по времени модификации составных частей css. Посмотреть можно с svn, я еще не зарелизил. Модуль называется CssOptimizer, написан на php, там и рабочее demo.
Качать только с svn (раздел «Source»), в релизе только сборка JavaScrip-ов!

[grep0]

640 килобайт 31 файл хватит на всех!

[bezz]

Ну вы, блин, даете… ©

[pxx]

Естественно, когда сайт пойдёт в продакшн весь CSS будет в одном файле...

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

[crwin]

можно замечательно разделять внутри, не зря же созданы комментарии.
а вот насчёт 31 (!!!) подключаемого файла это уже попахивает плохой практикой

[m-haritonov]

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

[m-haritonov]

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