Dlaczego nie używamy dynamicznego (generowanego po stronie serwera) CSS?

Ponieważ HTML generowany po stronie serwera jest trywialny (i był to jedyny sposób tworzenia dynamicznych stron internetowych przed AJAX), CSS generowany po stronie serwera nie jest. Właściwie nigdy tego nie widziałem. Istnieją kompilatory CSS, ale generują one pliki CSS, które można wykorzystać jako statyczne.

Technicznie nie wymaga specjalnych bibliotek, znacznik stylu HTML powinien odwoływać się do skryptu szablonów PHP (/ ASP / cokolwiek) zamiast statycznego pliku CSS, a skrypt powinien wysyłać nagłówek typu CSS - to wszystko.

Czy ma problemy z pamięcią podręczną? Nie wydaje mi się Skrypt powinien wysyłać nagłówki bez pamięci podręcznej itp. Czy to problem dla projektantów? Nie, powinni edytować szablon CSS (podczas edycji szablonu HTML).

Dlaczego nie używamy dynamicznych generatorów CSS? Jeśli jest, proszę dać mi znać.

Głównym powodem, dla którego css jest rzadko generowany dynamicznie (dotyczy to również javascript), jest to, że są dobrymi kandydatami do buforowania. CSS to bardzo elastyczny sposób na stylizację twoich stron, z odpowiednią kombinacją klas, możesz uzyskać wszystkie różne części wszystkich różnych stron stylizowanych zgodnie z wszelkiego rodzaju wskazówkami bez konieczności warunkowania żadnej z nich w CSS na temat tego, co faktycznie dzieje się w tym wyświetleniu strony.

Po prostu dlatego, że CSS nie musi być różny dla każdej strony, prowadzi się do bardzo powszechnej praktyki optymalizacji kosztów pobierania. Większość witryn przepycha wszystkie pliki css dla całej witryny w jednym pliku do pobrania, dzięki czemu części, które dotyczą różnych odsłon, znajdują się tylko w jednym pobranym pliku. Dzięki buforowaniu klienci nie muszą czekać na pobranie go po raz drugi. Co ważniejsze, jako dostawca treści nie musisz ponosić kosztów przesyłania treści więcej niż jeden raz; możesz nawet umieścić statyczny css na serwerze, który lepiej nadaje się do obsługi zawartości statycznej, co zwalnia zasoby dla faktycznej zawartości dynamicznej na serwerach aplikacji.

Ta praktyka jest tak powszechna, że ​​wiele przeglądarek zakłada, że css jest statyczny; i bardzo niechętnie pobierają już CSS; nawet jeśli użytkownicy ponownie załadują stronę. To specjalne traktowanie dotyczy wyłącznie CSS; inne typy zawartości zostaną ponownie załadowane zgodnie z oczekiwaniami.

Wierzę, że twoje założenie jest błędne: w moim ostatnim projekcie aplikacja używała wygenerowanego przez serwer CSS załadowanego przez ajax (ponieważ, w zależności od lokalizacji mapy, na którą patrzysz, strona była oznakowana zupełnie innymi stylami).

Jednak przypadki użycia, w których pobranie dodatkowego CSS przez ajax rozwiązałoby problem, są dość rzadkie, dlatego może się nie zdarzyć: zwykle łatwiej jest utrzymać zestaw arkuszy stylów, które są wstępnie przetwarzane w czasie wdrażania (LESS + minification) i buforowalne ( np. następna strona będzie mogła ponownie użyć arkusza stylów, który wcześniej była buforowana, więc początkowy czas jest krótszy).

W rzeczywistości istnieją przypadki użycia dla dynamicznego CSS. Pracowałem z trzema różnymi rodzajami:

1. Mniej - mniej CSS to w zasadzie rozszerzenie języka CSS, które dodaje „dynamiczne zachowanie, takie jak zmienne, miksy, operacje i funkcje”. Pozwala także na „zagnieżdżone reguły”, co jest bardzo wygodne. Użyłem Less głównie po to, by CSS pisał mniej gadatliwie, eliminując część powtórzeń.

2. Przepisywanie adresów URL - Jako dowód na twoją wypowiedź, że nie ma problemów z pamięcią podręczną, od dłuższego czasu używałem PHP do obsługi skryptów jako plików CSS z poprawnymi nagłówkami pamięci podręcznej. Robię to głównie w celu udostępniania plików CSS z bibliotek, które nie znajdują się w katalogu głównym.

3. Raporty dynamiczne - nad jednym projektem, nad którym pracowałem, mieliśmy narzędzie do tworzenia raportów dla wszystkich rodzajów danych w systemie. Generujemy (wewnątrz styletagów, jak wspomniałeś) dynamiczne reguły stylu głównie dla kolorów wybranych przez użytkownika w narzędziu do tworzenia raportów.

^{Uwaga: Kiedy wysyłasz CSS bezpośrednio do adresu URL (jak w 1 lub 2 ) i nie osadzasz go na stronie, która jest już generowana przez skrypt, znacznie zwiększysz obciążenie serwera w związku z udostępnianiem zawartości statycznej. Tak więc, jeśli masz spory ruch, nawet jeśli możesz to robić dynamicznie za każdym razem, możesz buforować go jako plik statyczny, jeśli pozwala na to przypadek użycia.}

Ale dlaczego nie jest to bardziej powszechne? Myślę, że istnieje jeden główny powód - CSS nie jest tak naprawdę zbudowany do wyświetlania treści. Więc po prostu nie ma wielkiej potrzeby. Oprócz generowania dynamicznych kolorów wybranych przez użytkownika, tak jak my, lub ewentualnie obrazów tła (chociaż jeśli obraz jest treścią , prawdopodobnie dobrym argumentem jest użycie imgznacznika), co jeszcze musisz zrobić dynamicznie?

Większość dynamicznych zmian stylu można uzyskać, odwołując się do różnych statycznych dokumentów CSS.

Jest to z pewnością możliwe, jak myślałeś, ale po prostu nie ma zbyt wielu powodów, aby to zrobić.

Dynamiczne ładowanie CSS ma DWIE osobne aspekty ...

1. Dynamiczne generowanie pliku CSS na serwerze

   Jest to dość proste i robi to wiele stron internetowych. Jest to przydatne, jeśli zmienisz swój CSS na podstawie pewnych warunków. Na przykład, jeśli wybierzesz motyw witryny na podstawie położenia geograficznego użytkownika.

2. Ładowanie pliku CSS na żądanie za pomocą modułu ładującego skrypt JS

   Może się to przydać, jeśli dynamicznie tworzysz dużą część DOM, a następnie ładujesz wymagane style. ALE Jak mówi autor LABjs ...

   ustalenie, czy ładowanie dynamicznie ładowanego pliku CSS zostało zakończone, jest w rzeczywistości dość skomplikowane i trudne w przeglądarkach. Zdarzenia „ładowania” nie uruchamiają się tak, jak można by się spodziewać. więc dodanie takiej obsługi dodałoby niebanalny rozmiar do LABjs

1. My to robimy. Cały czas. Szczególnie w przypadku takich marek, jak branding klienta w aplikacji SaaS, gdzie kolory itp. Pochodzą z bazy danych.
2. O wiele szybsze (z punktu widzenia użytkownika) jest wstępne generowanie CSS przed lub podczas wdrażania lub podczas uruchamiania aplikacji, jeśli aplikacja ma fazę rozruchu. Zazwyczaj preferujemy wstępne generowanie statycznych plików CSS, gdy tylko jest to możliwe.
3. Aby uzyskać maksymalną prędkość (z punktu widzenia użytkownika), najlepiej jest dostarczać statyczne pliki CSS do CDN i aby przeglądarka pobierała je z CDN, a nie z serwerów aplikacji. Zasadniczo jest to możliwe tylko wtedy, gdy pliki CSS można wstępnie wygenerować przed wdrożeniem lub w jego trakcie oraz gdy część wdrożenia dostarcza wstępnie wygenerowane statyczne pliki CSS do CDN. Sieci CDN są teraz bardzo tanie i łatwe w użyciu - sprawdź Amazon CloudFront i Cloud Files Rackspace.

Czy ma problemy z pamięcią podręczną? Nie wydaje mi się Skrypt powinien wysłać bez pamięci podręcznej itp

Wszystko bardzo dobrze, ale to znaczna część ogólnie statycznych informacji, które użytkownik prosi użytkownika o pobranie za każdym razem, gdy ładuje stronę. Więc lepiej mieć dobry powód.

Jaki może być ten powód?

Jeśli chcesz zmienić styl na podstawie różnych parametrów, możesz to zrobić, mając wiele arkuszy stylów i generując kod HTML w celu pobrania poprawnego.

Dynamiczny CSS jest dość trywialny i chociaż jego aplikacje są bardziej ograniczone (biorąc pod uwagę, jak dynamicznie generowany HTML ze statycznym arkuszem stylów zaspokaja większość codziennych potrzeb, a sam CSS zawiera kilka mechanizmów pozwalających osiągnąć pół-dynamiczny), „ widziałem, że był używany wiele razy i używam ich osobiście, kiedy tylko muszę.

Często część „dynamiczna” robi niewiele więcej niż łączenie kilku arkuszy stylów w jeden (w celu zmniejszenia liczby żądań HTTP) i ich minimalizowanie (w celu zmniejszenia wykorzystania przepustowości), ale proste rzeczy, takie jak zastępowanie zmiennych (np. Używanie zmiennych dla kolorów używanych w całym tekście arkusz stylów) może znacznie ułatwić Ci życie. Ponieważ jednak CSS ma dość prostą składnię z kilkoma zastrzeżeniami, zwykle wystarcza do tego ogólny system przetwarzania tekstu lub język skryptowy, taki jak PHP, dlatego nie widzisz wielu gotowych systemów przetwarzania CSS.

Może widziałeś ich na wolności, nie rozpoznając ich. Serwery wysyłające skrypty dynamiczne zwykle używają przepisywania adresów URL, dzięki czemu adres URL staje się nie do odróżnienia od treści udostępnianych statycznie. Jest to konieczne, ponieważ niektóre przeglądarki (w szczególności IE) polegają na rozszerzeniach do prawidłowego wykrywania typu MIME w określonych okolicznościach, ignorując (lub odrzucając) wszelkie nagłówki typu treści, które mogłeś wysłać.

Odnośnie buforowania: Arkusze stylów są pobierane z żądaniami GET, a ich buforowanie jest absolutnie ważne dla przyzwoitego doświadczenia użytkownika. Nie chcesz oglądać ponownego wczytywania strony, ponieważ ponownie pobiera arkusz stylów na każde żądanie. Zamiast tego należy umieścić wszystkie parametry zmieniające dane wyjściowe przetwarzania arkusza stylów w ciągu zapytania; inny ciąg zapytania daje inny adres URL, co z kolei powoduje brak pamięci podręcznej, więc po zmianie parametrów arkusz stylów zostanie ponownie pobrany, nawet jeśli klient buforuje wszystko. Jeśli naprawdę potrzebujesz CSS, który jest potencjalnie inny dla każdego żądania i zależy od skutków ubocznych, rozważ umieszczenie części niedynamicznej w arkuszu stylów obsługiwanym statycznie i obsługuj tylko te rzeczy dynamicznie, które są absolutnie wymagane, aby być dynamicznym.

Istnieje kilka scenariuszy, w których chciałbym używać dynamicznego CSS, ale najczęściej utknąłem przy użyciu projektantów, którzy potrzebują pomocy w zrozumieniu podstaw CSS. Wrzucenie dynamicznego języka do miksu może spowodować wybuch głowy.

Innym sposobem spojrzenia na to byłoby: „jakiś inny facet wykonuje całą tę bolesną pracę fizyczną, a nie mój problem, przechodząc dalej…”