ugrás a tartalomhoz

CSS Hacks

yaanno · 2007. Május. 19. (Szo), 22.56
Áttekintés a főbb böngészőkhöz használható "hackelési" módszerekről.
 ■
1

Csak körültekitéssel

Jano · 2007. Május. 20. (V), 11.51
Egy újonnan felfedezett értelmezőbeli hibát nem ugyanúgy kell kezelni mint egy új feature-t! Vagiys nem kell egyből elkezdeni kihasználni! Csak azok a hack-ek biztonságosak amik olyan hibára épülnek amiket már kijavítottak, mert azoknak lehet pontosan megjósolni a hatását!

Aki CSS hackol az olvassa el a következő írást mindenképpen:
Keep CSS Simple
4

Pragmatikus álláspont a hibák kihasználásával kapcsolatban

yaanno · 2007. Május. 21. (H), 08.01
Ezzel kapcsolatban csak annyit, hogy (a belinkelt cikkel jórészt összhangban) az élő böngészők számára nyújtott stílusapok tervezésekor jó észben tartani, hogy x böngésző mire képes és hogy furcsaságait miképpen tudjuk legyőzni. Ha az adott böngésző esetében nincs más mód, mint "hackelni" (így, idézőjelesen), akkor azt kell tenni. A fejlesztő ugyanis a megbízójától kapja a fizetését, nem a böngészőt gyártó cégtől/közösségől. Szóval szvsz a css(ek) annyira lesz(nek) egyszerű(ek), amennyire a feladat megkívánja. Okos tervezéssel már kezdetben elkerülhetők/bekaulkulálhatók a bosszantó dolgok - tehát csak proaktívan érdemes hozzákezdeni :)
5

Megrendelőnek jövőben sem eshet szét

Jano · 2007. Május. 21. (H), 11.06
Egyetértünk. A lényeg, hogy a hack ne az első, hanem az utolsó megoldási ötletünk legyen és akkor is lehetőleg olyan hack módszert használjunk ami "jövőbiztos".
2

Strict XHTML 1.0

ralesk · 2007. Május. 20. (V), 18.04
Ha valaki valid XHTML 1.0 Strictet használ, nagyon sok hajtépéstől mentheti meg magát – nekem legalább is minimális IE hackre van ekkor szükségem, az általában kezelhető a „* html” trükkel (mindenki másnak ez semmire sem match-el, hiszen a html senkinek sem gyermeke, IE6 viszont boldogan ráhúzza az elemekre ezeket a szabályokat).
3

Másik megoldás

ada · 2007. Május. 20. (V), 20.36
Szerintem sokkal többet számít egy kódnál hogy okosan átgondolt a szerkezet mint hogy valid, persze az is hozzátartozik.

Egyébként én a

<!--[if IE]>
	<style type="text/css">
		@import url('iefix.css');
	</style>
<![endif]-->
megoldást preferálom, mégpedig azért, mert ha így etetsz meg CSS-t az IE-vel, akkor a validatorok nem fogják látni, és nem dobják ki hibának a behavior, vagy a filter, IE only szabályokat.
6

Nem elég a Strict?

Wabbitseason · 2007. Május. 21. (H), 13.28
Azt mondod, nem elég a Strict, feltétlenül szükséges az XHTML is?
7

HTML vs. XHTML

kris7topher · 2007. Május. 21. (H), 17.30
Az XHTML a jövőbiztos. A HTML még nem XML hanem csak SGML alapú, egy fejletlenebb megoldás. És az XML előnyeit sem élvezi. Ettől függetlenül nem ettől függ, hogy a CSS hackelés mikor és hogyn kell (vagy csak a legritkább esetben) ha van Strict.
8

HTML is sokáig meg marad

Jano · 2007. Május. 21. (H), 18.30
Egyelőre úgy néz ki, hogy a HTML is sokáig velünk marad még.
9

fejletlenebb???

Hodicska Gergely · 2007. Május. 21. (H), 22.11
Azért elég erős az SGML-t fejletlenebbnek mondani az XML-nél.


Üdv,
Felhő
10

Az XHTML 1 halott

Wabbitseason · 2007. Május. 22. (K), 09.22
Az XHTML a jövőbiztos.

Ellenkezőleg. (XHTML vs HTML FAQ)

Az XHTML 2 nem kompatíbilis az XHTML 1-gyel, ráadásul még az MSIE 8-ban sem ígérik az XHTML támogatását, tehát amit a világ ma XHTML néven használ, az vagy HTML-ként parse-olt kód (text/html mime kóddal kiszolgálva), vagy a böngészgető emberek többsége nem fér hozzá.

Ennek egyáltalán nem örülök, mert szimpatikusabbnak találom az XHTML szigorúságát és szabályosságát, de nem is csodálkozom, hiszen internetes technológiákról van szó, ahol az elmélet és a gyakorlat között óriási a szakadék -- CSS hackek nélkül aligha boldogulnánk.