ugrás a tartalomhoz

Statikus file-ok organizációja

Török Gábor · 2009. Szep. 18. (P), 19.59
Brunner Ádám módszerei
 ■
1

Rossz CSS megoldás erőltetése

Wabbitseason · 2009. Szep. 21. (H), 10.49
A cikk érdekes, de meglepett, hogy a szerző szándékosan elbarmoltatja még az esetleg valid CSS kódot is a javasolt CSS tömörítőjével.

Az Explorerek megcélzására nem javaslom, hogy a CSS tulajdonságok neveit különféle varázsbetűkkel csúfítsuk el, hiszen ezektől invalid lesz a CSS.

Ehelyett használjuk ki az IE útvonalértelmező kódjának hibáit, tehát:
p {color: red}/* minden UA */
* html p {color: purple}/* IE6 és elődei */
*:first-child+html p {color: pink}/* IE7 */
További CSS trükkökkel kapcsolatos tanácsok:
http://www.webdevout.net/css-hacks
2

Nem valid CSS tömörítő?

Max Logan · 2009. Szep. 21. (H), 11.48
Itt pontosan melyik részre gondolsz? Arra, aminek a címe "Tartalom minimalitzálása"? Ha igen, akkor itt mi lesz nem valid a tömörítés után?
4

Igen, arra a részre

Wabbitseason · 2009. Szep. 21. (H), 14.45
Igen, arra a részre gondoltam, ahol a potenciálisan valid kódot invaliddá konvertálja minimalizálás közben.

Ha aláhúzásjellel kezded a szabály nevét, invaliddá teszed a CSS-t.

A helyes megoldásra már mutattam példát.
6

Két külön dolog ...

Max Logan · 2009. Szep. 21. (H), 15.00
... a browser hack-es rész és a minimalizálás regex-ekkel.

Ebben a regex csokorban nincsen _ jel, ergó szerintem ez nem rontja el az egyébként is valid-ként megírt CSS-t.

Ezeket csinálja a minimalizáló regex csokor:
  • Felesleges sor eleji és végi whitespace-ek és kommentek törlése;
  • Felesleges egynél hosszabb whitespace-ek cseréje egy space-re;
  • A szabalyokban lévő felesleges whitespace-ek törlése;
  • "a b a b" értékek átalakítása "a b"-re;
  • "a b c b" értékek átalakítása "a b c"-re;
  • Mértékegységgel rendelkező 0 értékek cseréje mértékegység nélkülire;
  • Felesleges whitespace-ek eltávolítása a kapcsoszárójelek és vesszők körül;
  • #rrggbb színkódokból #rgb-t csinálunk;
  • !important előtt felesleges a whitespace;
  • Szabályokban az utolsó pontosvessző felesleges, ezeket töröljük.
Szerintem ezek nem rontanak a valid kódon, de javítsál ki, ha tévedek.
7

"Böngészőspecifikus hackek

Wabbitseason · 2009. Szep. 21. (H), 16.34
"Böngészőspecifikus hackek alkalmazása"

Mintakód
'min-height: $1; _height: $1',
'min-width: $1; _width: $1',
9

Szezon vs. fazon

Max Logan · 2009. Szep. 21. (H), 18.10
Ezért kérdeztem, hogy melyik részre gondolsz. Ez már nem a minimalizáló kód része, hanem a browser hack-et automatizáló rész, mely a "Böngésző specifikus hack-ek alkalmazása" címet viseli. Az a fázis már a tömörítés után jön, azaz nem a tömörítés része. Tehát a tömörítő kód nem csinál unvalid CSS-t.
3

invalid css?

gex · 2009. Szep. 21. (H), 12.28
én is szívesen használom az _ és ! hack-eket, egyrészt mert lényegesen kisebb lesz a css fájlom, másrészt meg egy _width attribútumot nem fog semelyik normális böngésző értelmezni, úgy veszik mint ha ott sem lenne (ezt talán pont a szabvány mondja ki de ebben egyáltalán nem vagyok biztos, valaki javítson ki ha tévedek). a szabványhoz akkor kell ragaszkodni ha értelme is van, én úgy gondolom hogy a css-ben kevésbé fontos a szabványosság mint pl a html-ben.
5

Az a néhány byte, amit a

Wabbitseason · 2009. Szep. 21. (H), 14.50
Az a néhány byte, amit a valid hack miatt pazarolsz, kevesebbet árt, mint amikor syntax highlightos szerkesztőben megnyitod a CSS-t, és mást sem látsz, mint hibajelzéseket.

Az így teleszemetelt hibalistában nehezebb kiszúrni a valódi hibákat, elgépeléseket.

Mindenkinek javaslom, hogy figyelmesen tanulmányozza azt a linket, amit az első hozzászólásomban megadtam, mert rengeteg hasznos trükköt lehet ott találni.
12

Az a néhány byte, amit a

Adam · 2009. Szep. 22. (K), 10.23
Az a néhány byte, amit a valid hack miatt pazarolsz

Ha csak mondjuk 1KB-val számolsz és napi 1 millió látogatód van is már 1GB felesleges forgalmazásod volt. Tény, ez nem kimagasló sávszélesség növekedés, de felesleges, emiatt kidobott pénzbe kerül.

De mi van akkor, ha sokan nem bekapcsolt cache-sel böngésznek? Ez a szám még magasabb lesz! És ez elfogadhatatlan. Inkább legyen invalid amit forgalmazunk, sem többe kerüljön az egész.
8

A browser hack-ek

Adam · 2009. Szep. 21. (H), 17.36
@Wabbitseason: az, hogy egy CSS file nem lesz valid, igazából egyik böngészőt sem bántja. A HTML validságáról korábban már egészen flame szerű értekezés bontakozott ki itt a WL-en is. A CSS-nél szerintem értelmetlen lenne újrakezdeni az egészet.

A CSS file-oknál az ott említett hack-eket azért szükséges meglépni, hogy a fejlesztőnek ne kelljen foglalkoznia ezen hack-ek mindenkori felesleges begépelésével. Az általam a cikkben "javasolt" – pontosítva általunk használt – módszer előnye, hogy minimális mérettel növeli meg a CSS file-unkat. Ha külön CSS file-ba raknánk, úgy a legtöbbet használt böngészővel látogató felhasználóknak növelnénk meg a szerver felé a lekérések számát, növelve a betöltési idejüket, ami nem cél!

Úgy érzem a validság csak egy hiú cél, amit nagy terheltségnél egyszerűen túl költséges betartani és még előnye sem származik belőle a látogatónak.
10

Nem kell külön file

Wabbitseason · 2009. Szep. 22. (K), 09.39
Nincs szükség arra, hogy valid CSS hackeket külön file-ba kelljen rakni. Erre láthatsz példát az első kommentemben.
11

Más megközelítés

Adam · 2009. Szep. 22. (K), 09.59
Az ott említett oldalon a következőket javasolja, amik valid css-t eredményeznek:
  1. Conditional comments
  2. Easy selectors
  3. Minimized attribute selectors
  4. !important
  5. @import "…" all;
  6. body[class|=""]

Namost az 1., 2., 3., 5., 6. pontokat a korábbi okok miatt (file méret növekedés, külön CSS file, stb.) nem tudjuk alkalmazni.

A 4. pontban leírtat korábban már alkalmaztam, ellenben mivel moduláris felépítésű a CSS-ünk, emiatt ha felül kellett írni pl. az általad kritizált min-height-et, akkor az !important miatt az egy rémálom volt, mivel nem tudhattad kapásból — hacsak nem te írtad azt a modult is —, hogy ott most van-e min-height, és az !important-tel van-e megoldva, vagy sem, emiatt sokszor "sok" időt vett igénybe annak kiderítése, hogy miért is nem azt csinálja, amit szeretne az ember.

Emiatt is döntöttünk amellett, hogy a CSS validsága egyáltalán nem fontos. Mivel generált CSS tartalomról van szó, emiatt azt nem fogjuk betölteni editor-ba, amit meg szerkesztünk, abban meg nincsenek ezek a hack-ek, szóval nem fog világítani a szerkesztőd.
13

Lehet, hogy rosszul számolok

yaanno · 2009. Szep. 22. (K), 13.15
De mi is okozna méretnövekedést, ha a conditional comment-es megoldást használnánk? Valami ilyesmi lenne a példa:

x. style.css + style.ie.css: ie és nem-ie szabályok külön (nem-ie csak a style.css-t, ie pedig mindkettőt letölti)
y. style.css: ie és nem-ie szabályok együtt (ezt minden böngésző letölti)

Szerintem x = y, már ami a méretet illeti ie esetén, x < y nem-ie esetén; ha ellenben a letöltési szálakról beszélsz, abban már van valami.

Mivel generált CSS-ről van szó, ezért gondolom, úgy is lehetne generálni, hogy az IE (verziók stb.) külön CSS-be kerüljenek. Én most itt elsősorban az adott modulba írt IE specifikus kódról beszélek, nem a normalizáló CSS-ről, amit külön említesz.

Tetszik egyébként a style guide (az is nagy szó, hogy van ilyen nálatok!), jól átgondolt, hasznos.
14

Röviden: igen(?) :)

Adam · 2009. Szep. 22. (K), 15.37
Ha belegondolsz:
  • plusz lekérés a legtöbbet használt böngészőt látogatóknál – ez plusz terhelés a felhasználónak, a szervernek és növeli a letöltési időt a felhasználónál;
  • nem csak a tulajdonságokat rakod át a külön file-ba, hanem a selector-okat is;
  • a generálónak így nem kell a teljes CSS-t tokenizálnia – ami nem egyszerű, írtam már és jó lassú :) –, csak magukra a tulajdonságokra kell illeszkednie, könnyíti az új megoldások felvitelét.


Tényleg számunkra nem az a lényeg, hogy a szakmai felhasználók lássák, hogy itt minden valid, hanem hogy mindenki számára a lehető leggyorsabban töltődjön be a tartalom. A validság szerintem nem is szabadna jelen böngésző-piaci körkép tekintetében mérvadónak lennie. [OFF]Vulgárisan: f*szver*s az egész[/OFF]

Amire viszont kiváncsi lennék, hogy hogyan látjátok a selector-okkal kapcsolatosan felvetett problémámat:
A kérdés persze az, hogy vajon miért is teszik ezt a böngészők? Illetve akkor mi értelme van egyáltalán a selector-oknak a CSS-ben és miért kellett újabbakat létrehozni a CSS3-ban? Illetve, hogy a HTML méret növekedése és a DOM-beli attribútumok számának növelése lassítja jobban a betöltést, vagy a "felesleges" CSS selector-ok?
15

Még nem vagyok meggyőződve

yaanno · 2009. Szep. 22. (K), 20.01
Még nem vagyok meggyőződve arról, hogy rosszul számoltam, de majd ha lemegy az agyamról a nátha, még egyszer nekimegyek :)

miért is teszik ezt a böngészők?

Szerintem ezek a betöltéssel és a css renderelésével kapcsolatos kérdések csak nagyon kritikus esetekben jönnek elő, teszem azt egy sok-sok ezer soros css-el, javascript-tel, esetleg flash-sel megvert, netán vastagklienses alkalmazásnál.

Sajnos volt alkalmam szembesülni olyan kóddal (részben én írtam), ahol egy egyszerű color és font-size stílus renderelése is "fájt" már a böngészőknek (a webkiteseket leszámítva), egyszerűen látható volt, hogy a szöveg az egyik pillanatban még fekete, aztán piros... Ez van, amikor mindent a böngészőben akarunk összeszerelni :)

A Google-os Meiert például ellene van a "classt és idt mindenhova" elvnek, és én is hajlok arra, hogy a selectorok jók, használjunk kombinációkat (kivéve ie6), a html meg legyen sovány és tiszta, de ez egy másik szempontot hoz be, a fenntarthatóságét, ami (megint csak szerintem) legalább olyan fontos, mint az optimalizálás.

Picit off, de az istenített Yahoo! címlap ugyan kevés dom nodeot tartalmaz alapból, de csak addig amíg rá nem eresztik a rengeteg szkriptet :) Az ilyen oldalak éppen csak élvezhetők mondjuk egy netbookon vagy kéziszámítógépen/mobilon, mert rengeteg cput zabálnak.

Update: Az ominózus kérdéskört tesztelő postot akkor ide be is szerkesztem.