Wpadłem pomysl zeby zamiast wczytywac 1 wiekszy css podzielic go na "CORE" polowe wagi a reszte styli doczytywac w zależnosci od podstrony. Czy to aby dobry pomysl?
Wedlug was takie odchudzenie opowiedzmy o 5kb docelowo pewnie z 10kb lepsze niz czy gorsze niz 2 http requesty zamiast 1

Czy ja wiem, czy jest sens walczyć o 10kb? Ja sobie zawsze dziele CSS (i JS i PHP itd), ale nie z racji oszczędności (łatwiej się odnaleźć w plikach).

Czytałem ostatnio o testach które mówią jednoznacznie: 1 plik bo requesty powodują dużo większe opóźnienia niż te parę kilobajtów (które i tak się pewnie przyda).

najlepiej puść sobie analizator np http://developers.google.com/speed/pagespeed/insights/ lub http://gtmetrix.com/ i porównaj, ale raczej tak jak wspomniał timon27 liczą się requesty też czytałem że np krótkie pliki należy wrzucać wręcz bezpośrednio do pliku html i im mniej odpytań tym lepiej

Witam.
Temat morze. Moje zdanie jest takie używać tyle ile jest potrzebne. Zakładając że korzystamy z ie 9, który obsługuje css 2, to po co wczytywać style css3. Sprawa następna użytkownik używa Operę, to po co wczytywać style dla Mozilli. Napisałem klasę która układa poszczególne style dla przeglądarki, wersji styli css i responsiwe. Możemy tam też znaleść parę innych dodatków do obsługi strony WWW, które nie są związane z tematem zapraszam do odwiedzenia i zapoznania się z ową klasą. http://www.joomla-cms.com.pl/pl/class-resp...ponsivecss.html

ber32
Owszem może i to jest bez sensu żeby ładować style których dana przeglądarka nie obsługuje ale po pierwsze obciążasz zapytaniami server, a jak zobaczyłem twój konstruktor się zacząłem zastanawiać czy ja dobrze widzę, masz gdzieś testy jednostkowe? bo mam wrażenie, że szybciej pójdzie załadować to wszytko, poza tym poco się tak męczyć jak w JQuery jest tego pełno

Com. Klasa jest dość rozbudowana dlatego jest taki konstruktor. Sam przetestuj, w moich testach wychodzi bardzo dobrze. Dla tego żeby to było w php, bo mam wszystko w jednej klasie i nie muszę wszystkiego szukać to obsługę javascript to jak przeglądarka. Pliki stylów są wczytywane o połowę mniejsze w jQuery nie znalazłem takiej klasy ani plików które by te wszystkie rzeczy obsługiwały. Założę się że sam pakujesz wszystkie style w jeden plik jak większość ludzi nie rozdzielając poszczególnych styli dla danych przeglądarek lub wersji styli css. No i oczywiście responsie. Zauważ ile kodu byś musiał wyświetlić żeby dopasować responsywność do 10 urządzeń. Moja klasa pozwala wczytać tylko jeden dla danego urządzenia. W niedługim czasie sam to zrozumiesz i też będziesz taką technikę stosował.
Zobacz poniżej ile trzeba danych wczytać dla 5 urządzeń

[PHP] pobierz, plaintext 
@media only screen and (max-width: 1024px) {
	.wr{
		width:95%;
	}	
}
@media only screen and (max-width: 640px) and (min-width: 480px) {
	.w{
		width:95%;
	}
	.co{ 
		margin: 1% 0 1% 0%;
	}
	.spa{
		width:94%;
		padding:3%;  
	}
}
@media only screen and (max-width: 480px) {
 
     .w{
		width:95%;
	}		
	.col{ 
		margin: 1% 0 1% 0%;
	}
	.sp{
		width:92%;
		padding:4%;
	}
}
 @media (min-width: 980px) {
  .nav {
    height: auto !important;
    overflow: visible !important;
  }
}
@media(min-width:768px) and (max-width:979px){
.hi{
display:inherit !important
  }}
[PHP] pobierz, plaintext 

Moja klasa pozwala ograniczyć ilość kodu dla jednego urządzenia. Sam zobacz ile to jest linijek.

No dobrze może wszystkiego w jednym nie ma ale dla własnych potrzeb można doklepać parę linijek i dodać to czego brakuje..
nie pamiętam gdzie mam teraz to ale to co znalazłem już jest zadowalające http://leaverou.github.io/prefixfree/# i nie trzeba tworzyć miliona plików dla każdej przeglądarki bo js dostosuje to za nas...

Powiem tak trochę się nie zrozumieliśmy, Twój pomysł jest na pewno dobry ale na pierwszy rzut oka (bo nadal nie mam porównania(czyt. testów) stwierdzam że strasznie zasobożerny, bo trzeba przemielić i wypluć dane dla naszej przeglądarki i co potem robić to za każdym przeładowaniem? chyba że jakoś to usprawniłeś ale to szczegóły, a co do rwd i wgl całego css to skoro chcesz minimalistycznie to czemu nie less ?

a codo media queries to powiedz mi w takim razie co jak sobie np na kompie zmniejszę okienko? albo zamienię orientacje i mi się zwieszy/zmiejszy rozmiar media ma samo dostosować i przeładowac w czasie rzeczywistym a tak to przecież tego nie zrobi bo ma tylko full screen, wide czy coś innego ;P

Zdecydowanie minimalizuj liczbę requestów - tam gdzie się da, stosuj CSS sprites, kompresuj CSS/JS, dla pluginów JS (np. do jQuery) stosuj jeden plik (np. plugins.js tak jak w HTMLB).

@ber32 - pomijając już to, że Twoja klasa jest naprawdę paskudna (straszna sieczka ) to w dodatku wykrywasz przeglądarkę na podstawie USER_AGENT. OK, zgodzę się z tym, że to niby pierdoła (tylko wygląd strony).

Tak naprawdę to jej sens jest... znikomy. W 99% procentach przypadków różnice pomiędzy przeglądarkami innymi niż IE nie wymagają osobnych arkuszy. Naprawdę, większy sens ma kompresowanie i optymalizowanie plików CSS/JS niż pieprzenie się ze stylami dla każdej przeglądarki. Więcej pożytku przyniesie wrzucenie stylów dla mobilek do osobnego arkusza i ładowanie ich za pomocą media-queries niż rozbijanie ich na wiele plików.

Ok zrobilem troche inaczej nie reqestuje plików .css tylko wstawiam sama tresc w wenetrzny arkusz, zrobilem sobie porzadek i css "core" sie odchudzil i co najwazniejsze juz nie bedzie tyl. Dzieki za opinie

pedro84. Muszę się z tobą nie zgodzić co do kwesti

Pokarzę prosty przykład z ładowaniem np. tła strony dla kilu przeglądarek zobacz ile kodu tutaj się znajduje. Oczywiście zakładamy że strona ma obsługiwać praktycznie wszystkie przeglądarki w bardzo dobry sposób.

[PHP] pobierz, plaintext 
  .ga{  
background: rgb(7,7,7); /* Wszystkie prazeglądarki */
background: -moz-linear-gradient(top, rgb(7,7,7) 0%, rgb(89,89,89) 12%, rgb(102,102,102) 25%, rgb(71,71,71) 39%, rgb(44,44,44) 50%, rgb(0,0,0) 60%, rgb(17,17,17) 66%, rgb(43,43,43) 76%, rgb(28,28,28) 91%, rgb(19,19,19) 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgb(76,76,76)), color-stop(12%,rgb(89,89,89)), color-stop(25%,rgb(102,102,102)), color-stop(39%,rgb(7,7,71)), color-stop(50%,rgb(4,44,44)), color-stop(60%,rgb(0,0,0)), color-stop(66%,rgb(17,17,17)), color-stop(76%,rgb(43,43,43)), color-stop(91%,rgb(28,28,28)), color-stop(100%,rgb(19,19,19))); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top, rgb(6,76,76) 0%,rgb(89,89,89) 12%,rgb(102,102,102) 25%,rgb(71,71,71) 39%,rgb(44,44,44) 50%,rgb(0,0,0) 60%,rgb(17,17,17) 66%,rgb(43,43,43) 76%,rgb(28,2,28) 91%,rgb(19,19,19) 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top, rgb(76,76,76) 0%,rgb(89,89,89) 12%,rgb(102,102,102) 25%,rgb(71,71,71) 39%,rgb(44,44,44) 50%,rgb(0,0,0) 60%,rgb(17,17,17) 66%,rgb(43,43,43) 76%,rgb(28,2,28) 91%,rgb(1,19,19) 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top, rgb(76,76,6) 0%,rgb(89,89,89) 12%,rgb(102,102,102) 25%,rgb(71,71,71) 39%,rgb(44,44,44) 50%,rgb(0,0,0) 60%,rgb(17,17,17) 66%,rgb(43,43,43) 76%,rgb(28,28,28) 91%,rgb(1,19,19) 100%); /* IE10+ */
background: linear-gradient(to bottom, rgb(76,6,76) 0%,rgb(89,89,89) 12%,rgb(102,102,102) 25%,rgb(71,71,71) 39%,rgb(44,44,44) 50%,rgb(0,0,0) 60%,rgb(17,17,17) 66%,rgb(43,3,43) 76%,rgb(2,28,28) 91%,rgb(9,19,19) 100%); /*Standart  W3C */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#4c4c4c', endColorstr='#131313',GradientType=0 ); /* IE6-8 */
}
[PHP] pobierz, plaintext 

Zobacz ile jest tutaj kodu nie potrzebnego dla jednej przeglądarki, która przegląda tą stronę. A jest to tylko tło. Teraz jeżeli masz sklep, który np. potrzebuje 20 pozycji do wyświetlania i wczytujesz różne kolory tła za obrazkiem plus sam obraz. To kod rozrasta się w zastraszającym tempie. Klasa pozwala zredukować o jedną piątą ilość kodu przesłanego do przeglądarki. Same obciążenie jak mówisz to jedne zapytanie do serwera, w sumie odwołanie się do biblioteki na serwerze, jest o niebo szybsza, niż wczytanie tej masy niepotrzebnych danych w tym przypadku tła. Nie mówiąc już o kodzie responsywnym, w który powielał byś kod tyle razy ile chciałbyś zastosować daną rozdzielczość masakra. Same te tło zajęło by 200 linijek kodu więc cały plik to jakieś 2000 lini. Teraz dla mnie programisty sprawdzanie tego kodu co zawiera 2000 lini jest męczarnią, ciągłe przeskakiwanie przez taką ilość kodu bo to menu gdzieś na 150 lini nie gra to stopka na 1960 lini jest nie tak to content się rozjechał na 150 lini. Co innego jeżeli całość mieści się w 300 liniach. To praca na takiej ilości kodu to sama przyjemność.
com. dzięki za wskazówki tego nie przemyślałem, może się tak stać, uwzględnie taką sytuację w następnej odsłonie klasy.
Zapraszam na pw jeżeli ktoś jest tematem zainteresowany, chętnie udzielę informacji niezbędnych do obsługi klasy o dodatkową funkcjonalność np. facebook, lub obsługą czcionek google.

Twoja klasa nie ma wiele wspólnego z responsywnością. Mam tablet: 1280x800. Co w przypadku zmiany położenia ekranu? W dalszym ciągu będzie serwowała stary kod. Tak samo jak w przykładzie przytoczonym przez @com.

Druga rzecz, obecnie to nie rozmiar (oczywiście nie mówimy o skali kilku megabajtów) ma największe znaczenie (w szczególności w urządzeniach mobilnych), ale właśnie liczba requestów, którą to powinno się minimalizować.

Inna kwestia to to dzielenie kodu CSS na kod dla poszczególnych przeglądarek. W 95% kod dla przeglądarek (ex. IE) będzie identyczny. Pracowałem z naprawdę dużymi paczkami CSS/JS i w życiu żadnemu frontendowcowi nie przyszło do głowy dzielić tak CSS. To co to Twoje podejście daje, to oprócz pozornej optymalizacji, to dużo syfu w kodzie, podzielony na części wg. jakiejś dziwnej metodologii. To nie ma najmniejszego sensu. Ewentualne korzyści są znikome. A jak nadmieniłem wcześniej, to nie ma nic wspólnego z responsywnością.

PS. Popraw te literówki, bo oczy bolą