ugrás a tartalomhoz

CSS Hack for Chrome, Safari and Internet Explorer 7

yaanno · 2009. Feb. 7. (Szo), 12.51
Workaround egyes böngészők furcsaságainak megkerülésére
 ■
1

Egy hack nélküli világ...

Adam · 2009. Feb. 7. (Szo), 16.57
Inkább jobb lenne, ha mindenki igyekezne hack-ek nélkül megvalósítani a terveket. Eddigi tapasztalatom szerint maximum IE6-7 esetén kellett egyszer egyszer kisebb módosításokat eszközölni csak, hogy valami ugyanúgy nézzen ki. Arra meg ott van az underscore hack (_property: value;), ami IE6-ban működik, és pl. !property: value; ami IE6-7 érvényes.
2

Hát ez alapanyag és

Fraki · 2009. Feb. 7. (Szo), 18.37
Hát ez alapanyag és munkastílus kérdése. Milyen mélységben használod ki a lehetőségeket.

Egy másik elegáns módszer lehet a CSS hackek elkerülésére, ha a html elemnek adsz böngészőazonosító osztályt.
<html class="<?php echo $browser ?>">
html.ie7 .asdf {}
html.safari .asdf {}
...
Egyébként ezek a cikkben tárgyalt hackek kifejezetten kreatívak, csak hacker szempontból.
3

Hack free

yaanno · 2009. Feb. 7. (Szo), 20.53
Igyekszem én is távol tartani magam a hackeléstől amennyire lehet; a blogmark oka, hogy pl. a cégnél elkezdték forszírozni a Chrome támogatását, és ez a böngésző bizony még nem teljesen azt nyújtja CSS terén, ami elvárható lenne.

Egy megjegyzés. Ha nincs php, akkor JavaScripttel is van lehetőség egy extra class beszúrására a DOM-ba, a legtöbb JS framework már tud ilyet.
4

Chrome

Poetro · 2009. Feb. 8. (V), 21.03
a cégnél elkezdték forszírozni a Chrome támogatását, és ez a böngésző bizony még nem teljesen azt nyújtja CSS terén, ami elvárható lenne.

Szerintem teljesen jó a CSS támogatás a Chromeban, ami működik Firefoxban, az 99% hogy jól fog kinézni Chrome-ban is. És minden más WebKit motoros böngészőben (pl. Safari)
5

Szerinted

yaanno · 2009. Feb. 9. (H), 09.47
Lehet, hogy szerinted jó, és az is lehet, hogy 99%-ban tényleg jó, ám a hackek éppen erről a minimális, azonban rendkívül idegesítő %-ról szólnak. Több designer/fejlesztő is panaszkodott egyébként, hogy - többek közt - a CSS nincs rendben a Chrome-nál, és ajánlgatják az új, bétaállapotú letöltését.
6

+1 css bugs

Ustak · 2009. Feb. 9. (H), 16.03
A floatolt listaelemek ie 6+ és ff alatt is tökéletesen megjelennek egymás alatt, chrome-ban egymás fölött(!) magyarul 30 menüpontból csak az utolsó látszott :-)
7

konkrét példa?

gex · 2009. Feb. 9. (H), 16.21
ez a "floatolt listaelemek" elég tág, tudsz mutatni konkrét példát? újabban chrome-ban is tesztelek, sőt most egy munkánál külön kérés volt, hogy chrome-ban is minden közel pixelpontos legyen és én nem nagyon találtam ilyen hibát.
8

Sajtok

Ustak · 2009. Feb. 9. (H), 22.20
szegacam.hu
Termékek(click)->Egyéb húskészítmények(click)
jobb oldalt kijön a menüsor, mely ie6+ és firefoxban egymás alatt jeleníti meg a menüpontokat, chrome-ban legutóbb mikor néztem egymásra pakolja őket.
Nem tagadom optimalizálni jócskán lehetne, de gyorsan kellett csinálni :-). Majd ráérő időmben megpróbálok ajaxos megoldást hogy vajon gyorsabb -e.
Érdekes megnézni firefox alatt is, ugyanis ha a jobb oldali menüsort a csúszkával húzzuk, akkor valamiért nálam (ubuntu+ff3) vibrál a felette levő kép. Ie alatt nem. A menüsor absolute pozicionált, a weboldal többi része floatolt (de ennek lehet köze a dologhoz?). Ugyanígy történik ha egy adott termékre kattintva a középen megjelenő leírást csúszkáztatjuk.
9

Ugyanaz

Poetro · 2009. Feb. 9. (H), 23.43
Nálam pontosan ugyanúgy néz ki FF3-ban mint Chrome alatt.
10

A 6-os hsz. nem egy egzakt

Fraki · 2009. Feb. 10. (K), 07.19
A 6-os hsz. nem egy egzakt bugleírás, ehhez minimálteszt kell.

A villódzás megszűnik, ha ezt a szabályt kiütöm:
div#relative_nav_inner {3_col.css (line 361)
Xoverflow:auto;
padding:2px;
}
A content villódzásához meg ezt a szabályt:
#content_inner {3_col.css (line 152)
background-color:#FBEECE;
Xoverflow:auto;
padding-left:20px;
padding-right:15px;
}
Visszatérve a "bugra", ha a 382. sorban lévő width-et kiütöm, a jelenség megszűnik (ez az alatt/fölött megfogalmazás enyhén zavaró volt, mert nem tetted hozzá, hogy az alattat függőlegesen értetted, a fölöttet meg mélységben). Ha viszont ezt az értéked átrakod az a-ban lévő span elemre, akkor megjavul.
ol#navigacios_menu a span, div#fel_nyil a, div#le_nyil a {
	font-family:"Times New Roman", Times, serif;
	font-size:12px;
	cursor:pointer;
	color:black;
	background-color:#fbeece;
	font-weight:bold;
	border:1px solid black;
	padding:2px;
	display:block;
	width:150px;
}
ol#navigacios_menu {
	overflow-x: hidden;
}
11

Köszönöm szépen

Ustak · 2009. Feb. 10. (K), 16.34
sajnos nem értem rá (és nem is értek annyira hozzá) hogy így tesztelgessem, ki is fogom javítani mihelyst odajutok. Az a baj, ha csak a fentebb javasoltakat megcsinálom, tényleg nem villódzik, viszont elvesztem a customSroll() általam írt gyönyörű (:-)) plugin hatását, ami egységes scrollbart készít böngészőtől függetlenül. Ezt biztos lehet orvosolni, és mihelyst időm lesz rá meg is fogom tenni. Addig chrome támogatás ugrik :-)
Viszont ez akkor sem magyarázza meg, hogy szeretett böngészőinkben miért nem jön elő eme "bugnak kinéző de nem bug" és a chrome miért viselkedik így. Arról nem is beszélve hogy a megrendelő ie6 (!) alatt nézi.
Mindenesetre köszi a megoldást, és hogy foglalkoztatok vele!
Üdv:
Gábor

szerkesztve:
ps: emlékszem már, miért kellett az owerfow:auto. Ugye, ha valamit a divbe rakok, és scrollt akarok írni hozzá, akkor tudnom kell a tényleges méretét az után, hogy a tartalmat beletöltöttem. Tehát a divnek arra a méretre kell nőnie, amennyit a tartalom elfoglal, így tudom kiszámolni, mennyit scrollozzak rajta ahhoz, hogy változó tartalmaknál is megfelelő legyen a csúszka nagysága és a scrollozott elem pozíciója.
Ha erre valakinek jobb ötlete van, örömmel várom.
12

Tény, hogy egy egyéni

Fraki · 2009. Feb. 10. (K), 19.22
Tény, hogy egy egyéni szkrollhoz tudni kell minden méretet, a konténerét és a tartalmáét is. De ennek mi köze az overflow:auto-hoz? Az overflow:auto natív sávot jelenít meg, ha a tartalom mérete nagyobb, mint a konténer. Következésképp neked semmiképpen nem kellhet ez, és mindenképpen az overflow:hidden kell. Én, miután a változtatásokat megcsinálom, minden normálisan működik, egyéni szkrollbárral. Milyen hatást vesztesz el?

Egyébként a villódzásról lerí, hogy bug, hiszen látszik, hogy motorprobléma, ilyen viselkedést elvileg nem is kéne tudni előidézni.

A width-es dologra csak azt mondanám, hogy valószínű, de önmagában ebből a jelenségből ezt még nem lehet biztosra kimondani, meg azt sem, hogy ha hiba, js- vagy css-hiba-e. Teszt után ki lehet mondani.
13

overflow:hidden

Ustak · 2009. Feb. 10. (K), 22.04
Teljesen igazad van, tökéletesen működik. Tudatlanságomban azt hittem, hogy csak levágja a tartalom alját és fix marad a méret. De nem!
Köszönöm!
Gábor.
14

Tudatlanságomban azt hittem,

Fraki · 2009. Feb. 11. (Sze), 01.40
Tudatlanságomban azt hittem, hogy csak levágja a tartalom alját és fix marad a méret. De nem!
Ezt speciel jól hitted, csak valószínűleg elfelejtetted, hogy neked erre is van szükséged, mivel saját szkrollbárt írsz hozzá.
15

Akkor most már ösztönből...

Ustak · 2009. Feb. 11. (Sze), 15.56
fogok kódolni :-)

<div id="kulso">
   <div id="belso">
     <h5>Tartalom</h5>
     <p>Mindenféle van itt</p>
   </div>
</div>
Ugye a kulso azonosítóval rendelkező div overflow:hidden-nek kell hogy legyen, ez egyértelmű, valamint egy fix height -el kell rendelkeznie, amiben fog mozogni a belso id-jű div. Viszont a belso div -nek ilyen szempontból teljesen mindegy hogy hidden vagy auto overflow tulajdonságot állítok be (mindazonáltal jobb a hidden, hisz az valóban megszünteti a fent említett villódzást) mivel a height nem fix, így mindkét esetben a div mérete nő és nem jelenik meg scrollbar. Vagy rosszul látom a dolgot?
16

Így van, ha nincs height,

Fraki · 2009. Feb. 12. (Cs), 00.40
Így van, ha nincs height, akkor az overflow hatástalan. És igen, összekevertem a belső meg a külső divet. Szóval a külsőn (relative_nav_div) eddig is hidden overflow volt, természetesen, és ez rendben is van. A belso szkrollozott tartalom (relative_nav_inner) overflow-ja okozta a villódzást. És ugye azt elég kiütni, nem kell se hidden, se auto.

Innentől egyébként már van egy megfogható tesztjelöltünk: ha egy overflow:hidden konténerben egy overflow:auto elem helyzete megváltozik, az villódzni fog. Ezt már érdemes tesztelni, de persze valószínűleg még mindig egyszerűbb metódus a szájtodat lecsupaszítani.

Majd még foglalkozom vele, mert érdekes.
17

Köszi most már nekem is

Ustak · 2009. Feb. 12. (Cs), 16.27
világos:-)!