Pojedynczy ogromny plik .css vs. wiele mniejszych określonych plików .css? [Zamknięte]

258

Czy istnieje korzyść z posiadania pojedynczego pliku .css potwora zawierającego elementy stylu, które będą używane na prawie każdej stronie?

Myślę, że ze względu na łatwość zarządzania chciałbym wyciągnąć różne typy CSS do kilku plików i dołączyć każdy plik do mojego głównego, <link />czy to źle?

Myślę, że tak jest lepiej

  1. position.css
  2. buttons.css
  3. tables.css
  4. copy.css

vs.

  1. site.css

Czy widziałeś jakieś problemy z robieniem tego w jedną stronę w drugą stronę?

Nate
źródło
1
To NAPRAWDĘ stare pytanie, ale w obliczu tego samego problemu znalazłem takie, które moim zdaniem jest najlepszym rozwiązaniem na wypadek, gdyby ktoś dostał się na tę stronę. Wiele plików, które są kompresowane za pomocą PHP i wysyłane za pomocą pojedynczego żądania.
Francisco Presencia
3
@FrankPresenciaFandos robi to dobrze w przypadku witryn o niskim natężeniu ruchu, ale uruchamianie tego skryptu w kółko na witrynach o dużym natężeniu ruchu wydaje się trochę nie w porządku. Jeśli używasz skryptu kompilacji, możesz mieć to, co najlepsze z obu światów, i nadal utrzymywać wydajny serwer WWW, ponieważ nie uruchamia on skryptu php (nigdy).
Chase Florell
2
Byłby uruchamiany tylko przy każdej zmianie css, a następnie musiałbyś dołączyć wynikowy plik css.
Francisco Presencia

Odpowiedzi:

85

Kompilator CSS, taki jak Sass lub LESS, to świetna droga. W ten sposób będziesz w stanie dostarczyć pojedynczy, zminimalizowany plik CSS dla witryny (który będzie znacznie mniejszy i szybszy niż zwykły pojedynczy plik źródłowy CSS), przy jednoczesnym zachowaniu najładniejszego środowiska programistycznego, ze wszystkim starannie podzielonym na komponenty.

Sass i LESS mają dodatkową zaletę zmiennych, zagnieżdżania i innych sposobów ułatwiających pisanie i obsługę CSS. Gorąco polecam. Teraz osobiście używam Sass (składnia SCSS), ale wcześniej użyłem LESS. Oba są świetne, z podobnymi korzyściami. Po napisaniu CSS za pomocą kompilatora, jest mało prawdopodobne, że nie chciałbyś się bez niego obejść.

http://lesscss.org

http://sass-lang.com

Jeśli nie chcesz się bawić w Ruby, ten kompilator LESS dla komputerów Mac jest świetny:

http://incident57.com/less/

Lub możesz użyć CodeKit (przez tych samych facetów):

http://incident57.com/codekit/

WinLess to graficzny interfejs użytkownika systemu Windows do kompilacji MNIEJ

http://winless.org/

Marc Edwards
źródło
2
Zmieniam tutaj moją zaakceptowaną odpowiedź, ponieważ w dzisiejszych czasach jest to naprawdę dobra droga. Kiedy pierwotnie zapytałem, nie czuję się tak, jakby Sass lub LESS naprawdę wystartowali.
Nate
144

Trudno na nie odpowiedzieć. Obie opcje mają swoje zalety i wady.

Osobiście nie lubię czytać jednego OGROMNEGO pliku CSS, a jego utrzymanie jest bardzo trudne. Z drugiej strony podzielenie go powoduje dodatkowe żądania HTTP, które mogą potencjalnie spowolnić działanie.

Moja opinia byłaby jedną z dwóch rzeczy.

1) Jeśli wiesz, że Twój CSS NIGDY nie zmieni się po jego utworzeniu, zbudowałbym wiele plików CSS na etapie programowania (dla czytelności), a następnie ręcznie je połączę przed uruchomieniem (w celu zmniejszenia żądań HTTP)

2) Jeśli wiesz, że od czasu do czasu zmienisz swój CSS i musisz zachować jego czytelność, zbudowałbym osobne pliki i używałbym kodu (pod warunkiem, że używasz jakiegoś języka programowania), aby je połączyć czas kompilacji środowiska wykonawczego (minimalizacja / kombinacja środowiska wykonawczego jest świnią zasobów).

W przypadku obu opcji zdecydowanie zalecam buforowanie po stronie klienta, aby jeszcze bardziej ograniczyć żądania HTTP.

EDYCJA:
Znalazłem tego bloga, który pokazuje, jak łączyć CSS w czasie wykonywania, używając tylko kodu. Warto rzucić okiem (choć sam tego jeszcze nie testowałem).

EDYCJA 2:
W czasie projektowania postanowiłem używać osobnych plików oraz procesu kompilacji w celu zminimalizowania i połączenia. W ten sposób mogę mieć oddzielny (zarządzalny) css podczas tworzenia i odpowiedni monolityczny zminimalizowany plik w czasie wykonywania. Nadal mam pliki statyczne i mniejszy narzut systemowy, ponieważ nie wykonuję kompresji / minimalizacji w czasie wykonywania.

Uwaga: jeśli chodzi o kupujących, zdecydowanie polecam użycie narzędzia bundler jako części procesu kompilacji. Niezależnie od tego, czy budujesz z poziomu IDE, czy ze skryptu kompilacji, program pakujący może być uruchamiany w systemie Windows za pomocą dołączonego exelub może być uruchamiany na dowolnym komputerze, na którym jest już uruchomiony plik node.js.

Chase Florell
źródło
Czy oprócz mniejszej liczby żądań HTTP jest pojedynczy plik monolityczny? Mój css może się zmieniać z czasem, ale liczba użytkowników będzie dość niewielka, większość uzyskuje dostęp za pośrednictwem szybkich połączeń. Myślę więc, że przewaga wielu plików będzie znacznie większa niż mniejsza liczba żądań HTTP ...
Nate
1
powodem jest mniejsza liczba żądań HTTP. zatrzymywanie użytkowników jest priorytetem nr 1, więc jeśli strona ładuje się wolno, jest mniejsze prawdopodobieństwo, że pozostaną. Jeśli masz możliwość łączenia (widzę, że używasz asp.net), zdecydowanie polecam to zrobić. To najlepsze z obu światów.
Chase Florell,
3
„Myślę więc, że przewaga wielu plików będzie znacznie większa niż mniejsza liczba żądań HTTP ...” Nie, nie, nie… dokładnie odwrotnie. W przypadku połączenia o dużej szybkości czas przetwarzania żądań HTTP stanowi wąskie gardło. Większość przeglądarek domyślnie pobiera tylko dwa pliki na raz, więc przeglądarki wykonują 2 żądania, czekają, szybko pobierają pliki css, wysyłają 2 kolejne żądania, czekają, szybko pobierają pliki. W przeciwieństwie do jednego żądania HTTP dla jednego pliku css, pobiera się szybko. Komunikacja z serwerem byłaby powolna.
Isley Aardvark,
1
Możesz budować i testować funkcje za pomocą oddzielnych arkuszy stylów i łączyć je w jeden mongo jeden w czasie kompilacji. W ten sposób nie utrzymujesz jednego pliku mongo, ale wiele mniejszych plików. Robimy to, a także kompresujemy wszystkie białe znaki i komentarze, które ułatwiają ludziom czytanie, ale nie mają znaczenia dla twoich stron internetowych.
Brak zwrotów Brak zwrotów
2
Należałoby zaktualizować tę odpowiedź teraz, gdy http2 zmniejsza zaletę mniejszej liczby żądań.
DD.
33

Wolę wiele plików CSS podczas programowania. W ten sposób zarządzanie i debugowanie jest znacznie łatwiejsze. Sugeruję jednak, aby przy okazji wdrożenia użyć narzędzia minimalizacji CSS, takiego jak YUI Compressor, które scali twoje pliki CSS w jeden plik monolityczny.

Randy Simon
źródło
@Randy Simon - ale co jeśli zawsze edytujemy css bezpośrednio na ftp.
Jitendra Vyas
15
Nie znam twojej konfiguracji, ale nie wydaje mi się to dobrym pomysłem. Powinieneś testować zmiany przed ich wypchnięciem.
Randy Simon
1
@RandySimon link kompresora YUI jest uszkodzony.
zreformowany
16

Chcesz oba światy.

Chcesz wielu plików CSS, ponieważ twoje zdrowie psychiczne jest straszną rzeczą do stracenia.

Jednocześnie lepiej mieć pojedynczy, duży plik.

Rozwiązaniem jest posiadanie mechanizmu, który łączy wiele plików w jeden plik.

Jednym z przykładów jest coś takiego

<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />

Następnie skrypt allcss.php obsługuje łączenie plików i ich dostarczanie.

Idealnie byłoby, gdyby skrypt sprawdzał daty modyfikacji we wszystkich plikach, tworzy nowy kompozyt, jeśli którykolwiek z nich się zmieni, następnie zwraca ten kompozyt, a następnie sprawdza nagłówki HTTP If-Modified, aby nie wysyłać zbędnego CSS.

To daje najlepsze z obu światów. Działa świetnie również dla JS.

Will Hartung
źródło
7
jednak kompresja / minimalizacja środowiska wykonawczego ma narzut systemu. Musisz rozważyć zalety i wady. Jeśli masz witrynę o dużym natężeniu ruchu, nie jest to optymalne rozwiązanie.
Chase Florell
5
@ChaseFlorell - wystarczy raz kompresować / minimalizować i buforować
Siler
@Siler, wiem, dlatego opublikowałem swoją odpowiedź. stackoverflow.com/a/2336332/124069
Chase Florell
14

Posiadanie tylko jednego pliku CSS jest lepsze dla czasu ładowania stron, ponieważ oznacza to mniej żądań HTTP.

Posiadanie kilku małych plików CSS oznacza, że ​​tworzenie jest łatwiejsze (przynajmniej tak myślę: posiadanie jednego pliku CSS na moduł Twojej aplikacji ułatwia rzeczy) .

Istnieją więc powody w obu przypadkach ...


Rozwiązaniem, które pozwoliłoby uzyskać najlepsze z obu pomysłów, byłoby:

  • Aby rozwinąć za pomocą kilku małych plików CSS
    • tj. łatwiejsze do opracowania
  • Aby mieć proces kompilacji aplikacji, który „łączy” te pliki w jeden
    • Ten proces kompilacji może również zminimalizować ten duży plik, btw
    • To oczywiście oznacza, że ​​twoja aplikacja musi mieć pewne elementy konfiguracyjne, które pozwalają na przejście z „trybu wielu plików” do „trybu mono-plików”.
  • I do wykorzystania w produkcji tylko duży plik
    • tzn. szybsze ładowanie stron

Istnieje również oprogramowanie łączące pliki CSS w czasie wykonywania, a nie w czasie kompilacji; ale robienie tego w czasie wykonywania oznacza zjedzenie nieco więcej procesora (i oczywiście wymaga trochę mechaniki buforowania, aby zbyt często nie generować dużego pliku)

Pascal MARTIN
źródło
13

Historycznie jedną z głównych zalet x posiadania pojedynczego pliku CSS jest większa szybkość przy korzystaniu z HTTP1.1.

Jednak od marca 2018 r. Ponad 80% przeglądarek obsługuje teraz HTTP2, co pozwala przeglądarce na jednoczesne pobieranie wielu zasobów, a także na wyprzedzanie. Posiadanie jednego pliku CSS dla wszystkich stron oznacza większy niż konieczny rozmiar pliku. Przy odpowiednim projekcie nie widzę żadnej przewagi w robieniu tego poza łatwiejszym kodowaniem.

Idealnym projektem dla HTTP2 dla najlepszej wydajności byłoby:

  • Posiadaj podstawowy plik CSS, który zawiera wspólne style używane na wszystkich stronach.
  • Umieść CSS specyficzny dla strony w osobnym pliku
  • Użyj CSS push HTTP2, aby zminimalizować czas oczekiwania (plik cookie może być użyty, aby zapobiec powtarzaniu wypychania)
  • Opcjonalnie oddziel nad foldem CSS i popchnij to najpierw, a później załaduj pozostały CSS (przydatne w przypadku urządzeń mobilnych o niskiej przepustowości)
  • Możesz również załadować pozostały CSS witryny lub określonych stron po załadowaniu strony, jeśli chcesz przyspieszyć ładowanie stron w przyszłości.
DD
źródło
1
To powinna być przyjęta nowoczesna odpowiedź RE. Niektóre inne odpowiedzi są nieaktualne.
SparrwHawk
Jeśli budujesz SPA (aplikacja jednostronicowa), uważam, że najlepszym rozwiązaniem jest zbudowanie wszystkich plików css i js w dwóch kompletnych plikach. „app.js” i „vendor.js” Wszystkie pliki HTML i style są kompilowane do wbudowanego pliku JS w vendor.js. Oznacza to, że „bootstrap.css i bootstrap.js” znajdują się w vendor.js i są zminimalizowane przy pomocy sourcemaps do „ vendor.min.js ”. To samo dotyczy aplikacji, z tym wyjątkiem, że używasz HTMLa do wbudowanego transpilatora js, więc nawet Twój plik HTML aplikacji znajduje się w pliku js. Możesz hostować je w sieci CDN, a przeglądarki będą je buforować. Możesz nawet kompilować obrazy do stylów i do JS.
Ryan Mann
12

Monolityczne arkusze stylów oferują wiele korzyści (które są opisane w innych odpowiedziach), jednak w zależności od ogólnej wielkości dokumentu arkusza stylów możesz napotkać problemy w IE. IE ma ograniczenia dotyczące liczby selektorów, które odczyta z jednego pliku . Limit wynosi 4096 selektorów. Jeśli jesteś monolityczny arkusz stylów będzie miał więcej niż to, będziesz chciał go podzielić. To ograniczenie tylko pokazuje jego brzydką głowę w IE.

Dotyczy to wszystkich wersji IE.

Zobacz blog Ross Bruniges i stronę MSDN AddRule .

TheClair
źródło
7

Jest punkt zwrotny, w którym korzystne jest posiadanie więcej niż jednego pliku css.

Witryna z ponad 1 milionem stron, o których przeciętny użytkownik może zobaczyć tylko powiedzmy 5, może mieć arkusz stylów o ogromnych proporcjach, więc próba zaoszczędzenia na nakładzie pojedynczego dodatkowego żądania na ładowanie strony przez masowe początkowe pobranie jest fałszywa gospodarka.

Rozciągnij argument do skrajnego limitu - to tak, jakby sugerować, że powinien istnieć jeden duży arkusz stylów dla całej sieci. Wyraźnie bezsensowne.

Punkt zwrotny będzie jednak różny dla każdej strony, więc nie ma twardej i szybkiej reguły. Będzie to zależeć od liczby unikalnych css na stronę, liczby stron i liczby stron, które przeciętny użytkownik może rutynowo napotykać podczas korzystania z witryny.

Claud
źródło
Tak. Oto pytanie, o które tu przyszedłem. Wszyscy koncentrują się na rozwoju kontra produkcji. Oczywiście twoje środowisko programistyczne może różnić się od twojej działającej witryny, ale która z nich jest lepsza? Wydaje się, że nikt tak naprawdę się tym nie zajmuje. Czy znasz jakieś zasoby dotyczące znajdowania punktu krytycznego?
Dominic P
5

Zwykle mam garść plików CSS:

  • „globalny” plik css do resetowania i stylów globalnych
  • „modułowe” określone pliki css dla stron, które są logicznie pogrupowane (może każda strona w kreatorze płatności lub coś takiego)
  • „css” określone pliki css dla przesłonięć na stronie (lub, umieść to w bloku na indywidualnej stronie)

Nie jestem zbytnio zainteresowany wieloma żądaniami stron dla plików CSS. Większość ludzi ma przyzwoitą przepustowość i jestem pewien, że istnieją inne optymalizacje, które miałyby znacznie większy wpływ niż łączenie wszystkich stylów w jeden monolityczny plik CSS. Kompromis polega na szybkości i łatwości konserwacji, a ja zawsze skłaniam się w stronę łatwości konserwacji. Kompresory YUI brzmią całkiem fajnie, być może będę musiał to sprawdzić.

Nicholas Cloud
źródło
To właśnie robię i działa dobrze dla mnie. Co najwyżej dostajesz 3 pliki css dla każdej strony, co jest całkiem rozsądne
Ricardo Nunes
4

Wolę wiele plików CSS. W ten sposób łatwiej jest zamieniać „skórki”, jak chcesz. Problem z jednym plikiem monolitycznym polega na tym, że może on wymknąć się spod kontroli i jest trudny do zarządzania. Co jeśli chcesz niebieskie tło, ale nie chcesz zmieniać przycisków? Po prostu zmień plik tła. Itp.

Robusto
źródło
problem polega na tym, że jest to dość samolubne z punktu widzenia programistów. Gdy skończysz, rzadko musisz wracać, ale wszyscy odwiedzający muszą czekać, aż strony załadują niepotrzebne pliki css. (To samo dotyczy Javascript)
Chase Florell,
3
@rockin: Sprawdzając jedną z moich stron z 5-CSS po wyczyszczeniu pamięci podręcznej, odkryłem, że całkowity czas ładowania całego CSS był mniejszy niż 10 sekund. Jeśli ludzie nie mogą czekać tak długo, myślę, że potrzebują więcej Ritalinu lub czegoś takiego. Dużo większym problemem są oddzwanianie do witryn reklamowych, takich jak dwukrotne kliknięcie itp., Które mogą powodować OGROMNE opóźnienia, jak widać na tej samej stronie w ciągu ostatniego tygodnia.
Robusto,
Świetnym narzędziem do testowania prędkości witryny jest Firebug w połączeniu z YSlow. Powinno to zapewnić dokładne przedstawienie prędkości witryny.
Chase Florell,
4

Może rzucisz okiem na kompas , który jest strukturą tworzenia kodu CSS typu open source. Opiera się na Sass, więc obsługuje fajne rzeczy, takie jak zmienne, zagnieżdżanie, mixiny i import. Szczególnie importowanie jest przydatne, jeśli chcesz zachować osobne mniejsze pliki CSS, ale automatycznie połączyć je w 1 (unikając wielu powolnych połączeń HTTP). Compass dodaje do tego duży zestaw wstępnie zdefiniowanych miksów, które są łatwe w obsłudze w różnych przeglądarkach. Jest napisany w Rubim, ale można go łatwo używać z dowolnym systemem ....

stikkos
źródło
3

oto najlepszy sposób:

  1. utwórz ogólny plik css z całym udostępnionym kodem
  2. wstaw cały określony kod css strony do tej samej strony, w tagu lub używając atrybutu style = "" dla każdej strony

w ten sposób masz tylko jeden css z całym udostępnionym kodem i stroną HTML. przy okazji (i wiem, że to nie jest właściwy temat) możesz również kodować swoje obrazy w base64 (ale możesz to również zrobić z plikami js i css). w ten sposób redukujesz jeszcze więcej żądań HTTP do 1.

Ismael Miguel
źródło
2

SASS i LESS sprawiają, że to wszystko jest naprawdę sporne. Deweloper może skonfigurować skuteczne pliki składników i podczas kompilacji połączyć je wszystkie. W SASS możesz wyłączyć tryb skompresowany podczas programowania, aby ułatwić czytanie, i włączyć go ponownie w celu produkcji.

http://sass-lang.com http://lesscss.org

Ostatecznie potrzebny jest pojedynczy zminimalizowany plik CSS, niezależnie od stosowanej techniki. Mniej CSS, mniej żądań HTTP, mniejsze zapotrzebowanie na serwerze.

auguron
źródło
1

Zaletą pojedynczego pliku CSS jest wydajność przesyłania. Każde żądanie HTTP oznacza odpowiedź nagłówka HTTP dla każdego żądanego pliku, co wymaga przepustowości.

Służę CSS jako plik PHP z typem mime „text / css” w nagłówku HTTP. W ten sposób mogę mieć wiele plików CSS po stronie serwera i użyć PHP obejmuje wypchnięcie ich do jednego pliku na żądanie użytkownika. Każda nowoczesna przeglądarka odbiera plik .php z kodem CSS i przetwarza go jako plik .css.


źródło
Więc jeśli używam ASP.NET, ogólna procedura obsługi .ASHX byłaby idealną drogą do przejścia, która łączy je w jeden plik, aby uzyskać to, co najlepsze z obu światów?
Nate,
Tak, użyłbym IHttpHandler, aby połączyć twój CSS w czasie wykonywania (patrz nr 2 w mojej odpowiedzi powyżej)
Chase Florell
@Nate: Kiedy pracowałem w ASP.Net, użyliśmy plików szablonów, aby osiągnąć to samo.
Robusto,
@Robusto, czy możesz wyjaśnić, co to jest plik szablonu? Chyba nigdy o tym nie słyszałem. Użyłem App_Themes, ale nadal nie łączy CSS.
Chase Florell,
1
tylko jako aktualizacja. Użycie IHttpHandler lub pliku PHP do połączenia css po stronie serwera może zaoszczędzić przepustowość i przyspieszyć żądania, ale także dodaje niepotrzebnego obciążenia na serwerze. Najlepszym sposobem na to jest połączenie / zminimalizowanie pliku css / js podczas kompilacji / publikacji witryny. W ten sposób masz pojedynczy plik statyczny, który nie wymaga przetwarzania przez serwer. Najlepsze ze wszystkich światów, pasek BRAK.
Chase Florell
1

Możesz po prostu użyć jednego pliku css do wydajności, a następnie skomentować następujące sekcje:

/******** Header ************/
//some css here

/******* End Header *********/


/******** Footer ************/
//some css here

/******* End Footer *********/

itp

Kocia ryba
źródło
4
To nie ułatwia utrzymania, ponieważ wciąż muszę przewijać mile niezwiązanego css, aby dostać się do tego, czego szukam ...
Nate
2
@Nate: Czy zastanawiałeś się nad przejściem na edytor tekstu z przyzwoitą funkcją wyszukiwania? Moje osobiste preferencje to pojedynczy plik css i nigdy go nie przewijam. Po prostu wpisuję „/ classname” (używam pochodnej vi) i bam - jestem na tej klasie.
Dave Sherohman,
3
Trudniej jest także utrzymać go w środowisku wielu programistów. Co to jest „nagłówek” w powyższym przykładzie? Co jeśli ktoś inny nie myśli geograficznie, ale pod względem podstawowych elementów projektu, takich jak przyciski lub menu, podczas gdy inni myślą inaczej? Gdzie idzie menu, jeśli znajduje się w nagłówku? Co powiesz, jeśli tak nie jest? Myślę, że łatwiej jest egzekwować tego rodzaju dyscyplinę w osobnych aktach. Dlaczego twórcy aplikacji nie stworzą jednej ogromnej klasy aplikacji ze wszystkimi dodatkami zamiast struktury z hierarchią klas? Wydaje się podobny do mnie.
Robusto,
Co jeśli nie pamiętasz nazwy klasy, której szukasz? Lub jak zdecydujesz, gdzie dodać nową klasę?
Nate
Jeśli to tylko strona z kilkoma stronami, to naprawdę nie jest taka wielka sprawa. Po prostu sugeruję inny sposób robienia rzeczy.
Sum
1

Używam Jammit do zarządzania moimi plikami css i używam wielu różnych plików dla zapewnienia czytelności. Jammit wykonuje całą brudną pracę związaną z łączeniem i kompresowaniem plików przed wdrożeniem w środowisku produkcyjnym. W ten sposób mam wiele plików w fazie rozwoju, ale tylko jeden plik w produkcji.

jlfenaux
źródło
0

Dołączony arkusz stylów może obniżyć wydajność ładowania strony, ale im więcej stylów, tym wolniej przeglądarka wyświetla animacje na stronie, na której jesteś. Jest to spowodowane ogromną ilością nieużywanych stylów, które mogą nie znajdować się na stronie, na której jesteś, ale przeglądarka nadal musi to obliczyć.

Zobacz: https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/

Zalety dołączonych arkuszy stylów: - wydajność ładowania strony

Wady dołączonych arkuszy stylów: - wolniejsze zachowanie, które może powodować niepewność podczas przewijania, interaktywność, animację,

Wniosek: Aby rozwiązać oba problemy, w przypadku produkcji idealnym rozwiązaniem jest spakowanie całego css w jeden plik, aby zapisać na żądania HTTP, ale użyj javascript do wyodrębnienia z tego pliku, css dla strony, na której jesteś, i zaktualizuj za jej pomocą nagłówek .

Aby dowiedzieć się, które współdzielone komponenty są potrzebne na stronę i aby zmniejszyć złożoność, dobrze byłoby zadeklarować wszystkie składniki, których używa ta strona - na przykład:

<style href="global.css" rel="stylesheet"/>
<body data-shared-css-components="x,y,z">
Steve Tomlin
źródło
-1

Stworzyłem systematyczne podejście do rozwoju CSS. W ten sposób mogę wykorzystać standard, który nigdy się nie zmienia. Najpierw zacząłem od systemu siatki 960. Następnie stworzyłem pojedyncze linie css dla podstawowych układów, marginesów, wypełnienia, czcionek i rozmiarów. Następnie łączę je w razie potrzeby. To pozwala mi zachować spójny układ we wszystkich moich projektach i wielokrotnie korzystać z tych samych plików css. Ponieważ nie są one specyficzne. Oto przykład: ---- div class = "c12 bg0 m10 p5 biały fl" / div --- Oznacza to, że pojemnik ma 12 kolumn, wykorzystuje bg0 ma marginesy 10 piks. Dopełnienie 5, tekst jest biały i unosi się lewo. Mógłbym łatwo to zmienić, usuwając lub dodając nowy - To, co nazywam „lekkim” stylem - Zamiast tworzyć jedną klasę z tymi wszystkimi atrybutami; Po prostu łączę pojedyncze style, kodując stronę. To pozwala mi tworzyć dowolną kombinację stylów i nie ogranicza mojej kreatywności ani nie powoduje tworzenia ogromnej liczby podobnych stylów. Twoje arkusze stylów stają się o wiele łatwiejsze w zarządzaniu, zminimalizowane i pozwalają na wielokrotne ich używanie. Ta metoda okazała się fantastyczna do szybkiego projektowania. Nie projektuję też już najpierw w PSD, ale w przeglądarce, co również oszczędza czas. Ponadto, ponieważ stworzyłem również system nazewnictwa dla moich środowisk i atrybutów projektu strony, po prostu zmieniam plik obrazu podczas tworzenia nowego projektu. (Bg0 = tło ciała zgodnie z moim systemem nazewnictwa) Oznacza to, że gdybym wcześniej miał biały tło z jednym projektem po prostu zmieniając go na czarny oznacza po prostu, że w następnym projekcie bg0 będzie czarnym tłem lub innym obrazem .....

raquel
źródło
12
Czy wiesz, do czego służą akapity?
Em 1
Jest to „UI Framework”, podobnie jak Bootstrap lub inne. Gdy poznasz leksykon, do którego chcesz się udać, chodzi o krzywą uczenia się i akceptację używanych terminów. Mimo to mogę wymyślić kilka bardzo konkretnych przypadków, w których twój przykład będzie miał trudności z spełnieniem wymagań projektantów.
augurone