Ritkán látni olyan leírást, mely a CSS float tulajdonsága kapcsán nem csak azt mondja el, hogy eredetileg mire szánták, illetve hogy hogyan működik, de azt is részletesen, ábrákkal és példakódokkal bemutatja, hogy mire és hogyan használható, milyen problémák léphetnek fel, s ezekre mi a megoldás. Az All About Floats című írás ezt a feladatot elég jól teljesíti. Tudtad, hogy a “float” gumimatracot is jelent?
A képekkel elég gazdagon (és jól) illusztrált írás bemutatja, hogy a float tulajdonság segítségével lehet egész oldalrészek, és kisebb elemek megjelenését is módosítani, és felsorolja a lehetséges problémákat, mint a csak floatolt elemeket tartalmazó elem “összecsuklása”, a clear és az új sor kapcsolata, a túl hosszú tartalmak miatt széteső oldal. És persze részletes választ és megoldási módokat is kínál.
A float kapcsán azért még érdemes megemlíteni a Floatutorial című összefoglalót, mely konkrét példák megvalósításán keresztül járja be ezt a kérdéskört, a Smashing Magazine CSS Float Theory írását linkekkel gazdagon illusztrálva, és magát a W3C “szabványt” is persze.
tényleg jó összefoglaló, de azért ezt:
* html .clearfix {height: 1%;}
feltételes komment helyett nem kellene!
Nem az lenne az ilyen összefoglalók lényege, hogy a kezdők ne kövessék el újra és újra ugyanazokat az alaphibákat?
És a jó cikkbe belerak egy tipikus bad practice-t erősítő példát!
Ejnye!
teamtom: Nem értek egyet. Az említett megoldás valóban egy hack, azonban egy jelentős előnnyel bír az említett feltételes megjegyzéssel szemben: nem kell feldarabolnod a CSS-ed böngészők szerint, és a változásokat külön fájlban karbantartanod. Plusz nincsen egy extra HTTP kérés sem. Könnyen kiszűrhető, később megtalálható és módosítható megoldás, szerintem több előnyt kínál mint hátrányt ad (nincs valódi hátrány).
Én úgy tudom, hogy az ie7-et már nem lehet átverni a “star html” trükkel. Ez az igazi probléma szerintem, és ezért bad practice kategória.
Mert egy böngésző átmeneti tökéletlenségeit kihasználni nagyobb probléma szerintem, mint 1 sztenderd és 1 (esetleg 2) IE specifikus css fájlt használni.
Annyira nem szeretem a hack-eket, hogy azt a pár darab IE specifikus definíciót simán beleraknám a html-be (template-be) feltételes kommentek közé, ha az extra HTTP forgalom valóban akkora probléma
teamtom: IE7-re van megoldás, lásd ezt a blogbejegyzést (a friss böngészőkkel így is, úgy is foglalkozni kell): http://www.456bereastreet.com/archive/200603/new_clearing_method_needed_for_ie7/ — Bevallom fogalmam sincs hogy Firefox 3 esetén mi a helyzet (hiszen az inline-block-ot támogatja), de szerintem ott is működik.
teamtom: ie7 standards mode-ban tényleg átugorja ezt a rulet, ettől függetlenül még egy takarékos és ügyes filter lehet ie6-hoz, ill. a quirks mode problémáihoz; további megfontolások (ezek közül András is említett párat) itt
Az én gyakorlatomban nincs szükség számos css fájlra, és az a pár sor (gyakorlatilag annyi, ami a clearfix módszerhez kell) sem kell, hogy külső fájlra mutasson.
Általában bad practice-nek és nem “ügyes filter”-nek tartom a hack-eket, rövid távú előnyökkel.
yaanno: nekem szerencsére nem muszáj az ie6-ot quirks módban bármire is rábírnom (vagy félreértettem valamit?).
Nekem a “takarékos és ügyes”-ről a szelektorok elé írt “_” vagy “xx” jut eszembe, amik ugyan gyorsan és ügyesen ártalmatlanítják a kommentelendő definíciókat, viszont rendszerint benn is maradnak a css fájlban, nem növelve az “elegancia-faktort”.
teamtom: “nekem szerencsére nem muszáj az ie6-ot quirks módban bármire is rábírnom (vagy félreértettem valamit?).” – IE7 quirks módban + IE6 any módban
– ezekre működik a star html, így értettem
az nyilvánvaló, hogy nem kell mindenáron hackelni, sőt, amennyire lehet, kerüljük – szerintem ebben nincs vita köztünk; előfordul azonban, amikor több száz / ezer soros (szabványkövető) css megírása után bizony elő kell venni a bevált trükköket, mert nem nagyon van más lehetőség / idő; azért is linkeltem be a hack management linket, mert nem az a kérdés, hogy hackeljünk-e, hanem, hogy miképp
yaanno: az érdekelne, hogy a te gyakorlatodban hol/hogyan kerül elő a nem szabványkövető mód.
Nekem nem kell ie6 “alatt” vagy legacy kódokkal dolgoznom szerencsére. Vajon ezért lehet, hogy a hackelést el tudom/tudtam kerülni (azért a box-model-hack nekem is megvolt…) ?
elnézést a blog háziurától, ha offolnék ezzel!
Mi a különbség?
1.)
<!--[if IE]>...<![endif]-->2.) * html …
a “* html” selectornak nincs értelme, mert a html őselem nem kerülhet más elemek kontextusába
az ie6 és elődei viszont “benyelik” és értelmezik azokat a definíciókat is, ahol ez a cseles előtag kontextusként szerepel
gyakorlatban ez a definíciópáros:
#content { color: #000; }
* html #content { color: #f00; }
szabványkövető böngészőnél és ie7-nél fekete; ie6 és alatta piros betűszínt állít be.
Nem ez lett volna a kérdés lényege.
De kösz a leírást!
Továbbra sem látok lényegi különbséget a kettő között. Főleg nem olyat, amiért kardot ragadnék, hogy márpedig tessék ezt vagy azt használni!
teamtom: Belefér ennyi off.
Balogh Tibor: (Kérésednek megfelelően javítottam a hozzászólásod megjelenésén.) Az első egy a szabványhoz igazodó, egyedi, dokumentált megoldás, HTML kódrészt lehet vele IE6-ra (a példádban összes IE-re) célozni. A második egy böngésző hibát kihasználó hack, CSS kódrészt lehet vele IE6-ra célozni. Gyakorlati különbséget nem látok a kettő között, egyik sem rontja el az oldal validációját, általában véve ízlés kérdése hogy ki melyiket használja ha IE6-ról van szó. A float kérdést illetően én a csilagos megoldást tartom praktikusabbnak, mivel egy helyen tartja az összetartozó CSS definíciókat (az IE6-nak, és a más böngészőnek szólót), egyszerűbb a karbantartás. Ha nem IE6 targetálás a cél, akkor meggondolandó a feltételes megjegyzés. Alapjában véve ugye nem jó ötlet konkrét böngészőre külön lőni, de adott esetben célszerű lehet.
Erre gondoltam:
- A conditional comment egy akart, de nem szabványos – a html szabvány nem tartalmaz ilyet – dolog.
- A * html css jelölés valószínűleg egy bug, egy nem akart dolog, de kvázi szabványos működésként használják, és mert nem szabványos, így ie6 szűrésre jó.
teamtom: “az érdekelne, hogy a te gyakorlatodban hol/hogyan kerül elő a nem szabványkövető mód.”
Röviden: sajnos lépten-nyomon
Hosszabban: munkahelyen például rettenet hosszú (több ezer soros) css-ek vannak, eléggé bonyolult dokumentumszerkezetekkel fűszerezve; mivel több fejlesztő is dolgozik / dolgozott a kódon, nehéz karbantartani, lecserélni a legacy kódrészeket, új megoldásokat implementálni stb.
Példának okáért e blog szerzője sokat tett azért, hogy teszem azt IE5.5 (sok más, akkoriban kevésbé jó böngésző) alatt is működjenek dolgok, amik bonyolultságuk miatt nem triviálisak. Ilyenkor egy idő után előjön, hogy X böngésző menjen a szülő anyjába és betesz egy workaroundot v. hacket, amiért szvsz nem hibáztatható.
A kód nagyságrendekkel való növekedése és a dependenciák miatt a helyzet oda vezetett, hogy az egyik programozónk készített egy ügyes kis eszközt arra, hogy anélkül, hogy új css filet nyitnál mondjuk az ie6 dolgainak v. inline style-t használnál, az adott cssből egy szervlet “kiemeli” ezeket az ie6 ruleokat, létrehoz egy cdata leválogatást és cachelve küldi az ie6nak a speciális css fájlt. Még emellett az igen hasznos megoldás mellett is tömegesen jön elő például z-index csúszás v. a másik kedvenc, a haslayout probléma.