Чому ми не використовуємо динамічний (створений на сервері) CSS?

Оскільки HTML, створений на сервері, є тривіальним (і це був єдиний спосіб зробити динамічні веб-сторінки перед AJAX), CSS, створений на сервері, не є. Насправді я ніколи цього не бачив. Є компілятори CSS, але вони генерують файли CSS, які можна використовувати як статичні.

Технічно він не потребує спеціальних бібліотек, тег стилю HTML повинен посилатися на сценарій шаблону PHP (/ ASP / що завгодно) замість статичного файлу CSS, а сценарій повинен надсилати заголовки типу вмісту CSS - ось і все.

Чи є у них проблеми з кешем? Я не думаю, що так. Сценарій повинен надсилати заголовки без кешу тощо. Це проблема дизайнерам? Ні, вони повинні редагувати шаблон CSS (так як вони редагують HTML-шаблон).

Чому ми не використовуємо динамічні генератори CSS? Або якщо є, будь ласка, повідомте мене про це.

Основна причина, чому css рідко генерується динамічно (це справедливо і для javascript), полягає в тому, що вони є хорошими кандидатами для кешування. CSS - це дуже гнучкий спосіб стилювання сторінок, за допомогою правильної комбінації класів ви можете отримати всі різні частини всіх ваших різних сторінок, стилізовані відповідно до всіляких підказок, без необхідності вказувати будь-яку з них у CSS Сам про те, що насправді буває присутнім на цьому перегляді сторінки.

Просто тому, що CSS не потрібно відрізняти на кожній сторінці, це призводить до дуже поширеної практики оптимізації витрат на його завантаження. Більшість сайтів стискають весь CSS за весь свій сайт в один завантажений файл, так що частини, які застосовуватимуться до різних переглядів сторінок, присутні лише в одному завантаженому файлі. Під час кешування вашим клієнтам не потрібно чекати, коли він завантажиться вдруге. Можливо, ще важливіше, що вам, як постачальнику контенту, не доведеться сплачувати витрати на завантаження вмісту більше одного разу; і ви навіть можете розмістити статичний css на сервері, який краще підходить для обслуговування статичного контенту, що звільняє ресурси для фактичного динамічного контенту на серверах ваших додатків.

Ця практика настільки поширена, що багато браузерів просто припускають, що css є статичним; і дуже неохоче завантажують CSS, який вони вже є; навіть якщо користувачі перезавантажують сторінку. Цей спеціальний режим стосується лише CSS; інші типи вмісту перезавантажуються, як очікувалося.

Я вважаю, що ваше припущення є помилковим: у моєму останньому проекті програма використовувала створений серверним CSS, завантажений ajax (адже залежно від розташування карти, яку ви шукали, сторінка була брендована зовсім іншими стилями).

Однак випадки використання, коли отримання додаткового CSS за допомогою ajax вирішило б проблему, є досить рідкісними, це може бути причиною, чому ви ніколи не стикалися з цим: зазвичай простіше підтримувати набір таблиць стилів, які попередньо обробляються під час розгортання (МЕНШЕ + мінімізація) та кешовані ( наприклад, наступна сторінка зможе повторно використовувати таблицю стилів, яку вона кешувала раніше, тому початковий час коротший).

Насправді є випадки використання для динамічного CSS. Я працював з трьома різними видами:

1. Менше - Менше CSS - це розширення мови CSS, яке додає "динамічну поведінку, таку як змінні, комбінації, операції та функції". Це також дозволяє "вкладені правила", що дуже зручно. Я використовував Менше в основному для того, щоб зробити написання CSS менш багатослівним, усунувши частину повторень.

2. Перезапис URL-адрес - Якраз як підтвердження вашої заяви про відсутність проблем із кешем, я давно використовував PHP для подання скриптів у вигляді CSS-файлів із правильними заголовками кешу. Я в основному роблю це для обслуговування файлів CSS з бібліотек, які не знаходяться всередині веб-кореня.

3. Динамічні звіти - В одному проекті, над яким я працював, у нас був створений звіт про всі види даних у системі. Ми виводимо (всередині styleтегів, як ви згадуєте) правила динамічного стилю в основному для кольорів, обраних користувачем у конструкторі звітів.

^{Примітка. Якщо виводити CSS безпосередньо до URL-адреси (наприклад, в 1 або 2 ) і не вставляти її на сторінку, яка вже генерується сценарієм, ви додасте на сервер досить значне навантаження над поданням статичного вмісту. Отже, якщо у вас є значний трафік, хоча ви можете робити це динамічно кожен раз, ви хочете кешувати його як статичний файл, якщо дозволяє ваш випадок використання.}

Але чому це не частіше? Я думаю, що є одна головна причина - CSS насправді не створений для виведення вмісту. Тому просто немає великої потреби. Крім виведення динамічних кольорів, обраних користувачем, як ми це робили, або, можливо, фонових зображень (хоча якщо зображення є вмістом , то це, мабуть, хороший аргумент, щоб використовувати imgтег), що ще потрібно робити динамічно?

Більшість динамічних змін стилю можна здійснити, посилаючись на різні статичні документи CSS.

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

Є два аспекти для динамічного завантаження CSS ...

1. Динамічне генерування CSS-файлу на сервері

   Це досить просто, і багато веб-сайтів роблять це. Це корисно, якщо ви змінюєте свій CSS на основі якоїсь умови. Наприклад, якщо ви вибираєте тему свого сайту на основі географічного розташування користувача.

2. Завантаження файлу CSS на вимогу через завантажувач сценаріїв JS

   Це може стати в нагоді, якщо ви створите велику частину DOM динамічно, а потім завантажите необхідні стилі. АЛЕ як каже автор LABjs ...

   насправді визначити, чи завершено завантаження динамічно завантаженого CSS-файла, насправді досить складно і складно зробити крос-браузер. Події "навантаження" не спрацьовують, як можна було б сподіватися / очікувати. тому додавання такої підтримки додасть LABjs нетривіальний розмір

1. Ми робимо це. Весь час. Особливо для таких речей, як брендинг для клієнтів у додатку SaaS, де кольори тощо надходять із бази даних.
2. Набагато швидше (з точки зору користувача) попередньо генерувати CSS до або під час розгортання або під час завантаження програми, якщо програма має фазу завантаження. Зазвичай ми вважаємо за краще попередньо генерувати статичні файли CSS, коли це можливо.
3. Для досягнення максимальної швидкості (з точки зору користувача) найкраще доставляти статичні CSS-файли на CDN і змусити браузер отримувати їх із CDN, а не з серверів додатків. Це, як правило, можливо лише тоді, коли файли CSS можуть бути попередньо згенеровані до або під час розгортання, і коли частина розгортання доставляє попередньо згенеровані статичні CSS-файли до CDN. CDN зараз дуже дешеві і прості у використанні - перегляньте CloudFront та Cloud Cloud файли Amazon.

Чи є у них проблеми з кешем? Я не думаю, що так. Сценарій повинен надсилати без кешу тощо

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

Що може бути з цієї причини?

Якщо ви хочете змінити стиль на основі різних параметрів, то зробіть це, маючи кілька таблиць стилів та генеруючи HTML, щоб завантажити правильний.

Динамічний CSS досить тривіальний, і навіть якщо його програми більш обмежені (бачачи, як динамічно генерований HTML зі статичним таблицею стилів вирішує найбільш повсякденні потреби, а сам CSS включає декілька механізмів для досягнення напівдинамічного), я ' Я бачив, що він використовувався багато разів, і я сам їх використовую, коли мені потрібно.

Часто "динамічна" частина робить трохи більше, ніж поєднання декількох таблиць стилів в одну (для зменшення кількості запитів HTTP) та їх мінімізація (для зменшення використання смуги пропускання), а прості речі, такі як підміна підмінних (наприклад, використання змінних для кольорів, які використовуються протягом таблиця стилів) може значно полегшити ваше життя. Однак, оскільки у CSS є досить простий синтаксис з кількома застереженнями, для цього зазвичай достатньо системи для обробки тексту тексту або мови сценаріїв, як PHP, і тому ви не бачите багатьох нестандартних систем обробки CSS.

Можливо, ви бачили їх у дикій природі, не впізнаючи їх. Сервери, що надсилають динамічні сценарії, зазвичай використовують переписування URL-адрес, щоб URL-адреса не відрізнялася від вмісту, який розміщується статично. Це необхідно, оскільки деякі веб-переглядачі (особливо IE) розраховують на розширення для правильного виявлення типу MIME за певних обставин, ігноруючи (або відкидаючи) будь-які заголовки типу вмісту, надіслані вами.

Щодо кешування: таблиці стилів втягуються із GET-запитами, і зробити їх кешованими абсолютно важливо для гідного користувацького досвіду. Ви не хочете дивитись поповнення сторінки, оскільки вона повторно завантажує таблицю стилів у кожному запиті. Натомість слід розмістити всі параметри, які змінюють результати обробки вашої таблиці стилів, у рядок запиту; інший рядок запиту дає іншу URL-адресу, що, в свою чергу, призводить до пропуску кешу, тому щоразу, коли параметри будуть змінені, таблиця стилів буде повторно завантажена, навіть якщо клієнт кешує все. Якщо вам дійсно потрібен CSS, який потенційно відрізняється для кожного запиту і залежить від побічних ефектів, подумайте про те, щоб ввести нединамічну частину в таблицю стилів, що обслуговується статично, і обслуговувати лише ті речі, які необхідні для динаміки.

Є кілька сценаріїв, які я хотів би використовувати динамічний CSS, але частіше за все я стикаюся з використанням дизайнерів, яким потрібно трохи допомогти зрозуміти основи CSS. Введення динамічної мови в суміш може насправді вибухнути головою.

Іншим способом дивитися на це було б "якийсь інший хлопець виконує всі хворобливі ручні роботи, не дуже моя проблема, рухаючись далі".