Viszont vannak dolgok, amikhez még kép se kell.

Navigációnál és UI kezelőfelületeknél gyakran láthatunk kicsi, egyszerű háromszögekből álló nyilakat. Ezeket elkészíthetjük képpel, esetleg valamely UTF8 karakterrel a html kódban. Előbbi megoldás minden színvariációra és állapotra külön képet igényel, utóbbival pozícinálási gondok lehetnek más-más böngészőkben, és megzavarhatja a felolvasó programokat – nem valami akadálymentes megoldás.

Mi más lehetőség marad? Ma már lehet vektorosan canvas illetve VML elemekre rajzolni, színezni, tetszőleges módon scriptelni különböző állapotokra, hogy nézzen ki az elem… de ez már érezhetően aránytalanul nagy ráfordítás ekkora feladatra.

Egy lehetőség maradt, amivel egyszerű, színes poligonokat rajzolhatunk és nem kell hozzá plugin, kép, de még javasript se: a css keret.

A böngészők egy elemet körbevevő, vastag keretet, azok találkozásánál egy sima, ferde egyenes mentén illesztik, ezzel elkerülve azt a problémás kérdést, hogy melyik keret hol lógjon túl az elem szélén és mennyire. A html és css vízszintes és függőleges világában ezek a ferde vonalak eléggé meglepően hatnak, ritkán is fordulnak elő, mivel csak eltérő színű és esetleg vastagságú kereteknél válnak láthatóvá.

Ha egy ilyen elemen a magasságot és a szélességet nullára vesszük, négy “nyilat” kapunk. Innen már csak a nemkívánatos kereteket kell áttetszővé állítani, és marad egy.

Apróságokra persze oda kell figyelni,pl. a pozicionálásnál, a html elem ilyenkor mindíg a nyíl csúcsa.

Előjött egy IE6 bug és annak körüljárása is, úgyfest IE6 nem kezeli rendesen a transzparens kereteket, kivéve, ha solid stílus helyett dotted -re állítjuk. Mivel ez a keret amúgy se látszik, tökmindegy mire állítjuk, és ha ezzel a trükkel az összes böngészőben jó, akkor miért ne.

Végül a css kód ennyi:

span.arrow {
	display: block;
	width: 0px;
	height: 0px;
 
	overflow: hidden;
 
	border-top: 20px dotted transparent;	
	border-right: 0px dotted transparent;
	border-bottom: 20px dotted transparent;	
	border-left: 20px solid green;
}

Ezáltal egy jól használható, testreszabható kis elemet kapunk, amit a mai egyszerű weboldalak és html alapú alkalmazások jól használhatnak.

Demo, és pár példa itt látható
Tesztelve: IE6, 7, 8, chrome, ff3, safari 4.

Előnyök:

• html-css, nincs plusz kép, kevesebb http lekérés
• gyors megjelenítés
• testreszabhatóbb
• mouseover adott a DOM-ból

Hátrányok:

• kicsit nagyobb html kód (vagy js futásidő, ha utólag teszed a DOM-ba, de ez elkerülhető)
• nem teljes a testreszabhatóság, pl nem lehet neki keretet rajzolni
• talán valahol megtöri a rétegszemléletet, plusz html kód a design-hoz
• IE alatt pixelesedés előfordulhat, ezt a nyil méretein finoman korrigálva javíthatjuk

Az alapok

Maga a kód ilyen:

filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled='true', src='/images/alpha.png', sizingMethod='image');

Ez egy DirectX szűrő, amit lehet IE alatt a stíluslapokban használni. Két paraméterre figyeljünk:

• src
  ami a kép elérése, az oldal gyökeréhez relatívan ( a stíluslapoktól eltérően, ahol a relatív címzés a css állomány útvonalához képest értendő)
• sizingMethod
  ennek három beállítása van: image, scale és crop.
  Ha image-re állítod, a png azzal a méretekkel jelenik meg ami a kép valós mérete, függetlenül az őt tartó elem méreteitől.
  A scale mód kinyújtja a képet az őt tartó elem méreteinek megfeleően. Ez ideális egy tengely mentén nyújtott háttereknél, amikor más esetben egy tengely mentén ismétlődő hátterünk lenne – ennél a megoldásnál sajnos nincs ismétlődés, tehát így kell tervezni vele.
  Crop mód esetén levágja a kép kilógó részleteit ha kissebb, és eredeti méretben mutatja, ha nagyobb a hordozó elem. Ez közelíti meg leginkább a background-image viselkedését.

Hátrányok

A HTML elem, amire ráhúzod ily módon az alfacsatornás képet, elérhetetlenné válik bizonyos felhasználói interakciókra. A háttér úgy viselkedik, mintha az az elem és annak összes aleleme fölé lenne lebegtetve, holott az alelemek is jól jelennek meg (tehát nem a kép alatt). Maga az elem kattintható, de az alelemei már nem, a tartalmukat nem lehet kijelölni. Igy ha kicsit is komplexebb HTML szerkezetekre akarjuk ezt használni, javaslom az alábbi megoldást.

Minden ilyen elem esetén elhelyezek plusz egy layert, utolsó gyerek elemként abban az elemben, amire a png-t tenném. Mivel az IE7 és szinte minden nem-IE böngésző már jól kezeli az alfacsatornás png-ket, feltételes kommentet használok, hogy csak a kívánt böngészőkre jelenjen meg így és ne terheljen másokat.

<!--[if lt IE 7]>
<div class="bg"></div>
<![endif]-->

Ugyanezzel a megoldással egy stíluslapot is beemelek az oldal elején ami lekezeli ezeket az eseteket. A megoldás minimális extra kódot igényel, idővel, ha az IE6 sírba vonul, problémamentesen kivehető, egyszerű és működik. Nem valid CSS megoldás, de a css amiben használom, a feltételes komment segítségével kerül be az oldalba és csak az IE6 vagy korábbi verziói látják, így emiatt se kell aggódnom.

Olyan megoldásokra vannak példák IE alatt, hogy CSSben javascript számolásokat végzünk, de ezek természetesen nem szabványos megoldások, s mint ilyenek, nem feltétlenül működnek a többi böngészőben. Mások szerveroldali megoldásokkal definiálnak változókat a css-ben, pl ruby segítségével, de ez meg véleményem szerint sérti a rétegszemléletet, stíluslapokhoz ne nyúljunk szerveroldalon.

Nem, itt másról van szó, egy eszközről, amivel áttekinthetőbbé és kezelhetőbbé tudjuk tenni a stíluslapjainkat.

Pár css okítás megemlíti, hogy könnyebbé tehetjük életünk, ha bizonyos szövegformázásokat vagy oldal elemeket vázlatszerűen dokumentálunk a stíluslapokban, pl:

/**
 *	szöveg színek
 *
 *	link kék		:  #0099ff;
 *	cím piros		:  #cf1855;
 *	idézet szürke	:  #dedede;
 */
 
h1 {
	color: #cf1855;
}
p a {
	color: #0099ff;
}
blockquote {
	color: #dedede;
}

Ezt a logikát követi a most beemelt megoldás, csak igazi funkcionalitást ad az egésznek, az előző példa így nézhet ki:

/**
 *	szöveg színek
 */
@variables {
	link_kek:		#0099ff;
	cim_piros: 		#cf1855;
	idezet_szurke:	#dedede;
}
 
h1 {
	color: var(cim_piros);
}
p a {
	color: var(link_kek);
}
blockquote {
	color: var(idezet_szurke);
}

Látható, hogy segítségével apróbb, de következetes módosításokat végezhetünk a stíluslapjainkon, csak jól kell használni. A használata kiterjed az @import által beemelt stíluslapokra is, tehát nem szükséges fileonként beállítani. A @variables defíníciónál lehetőség van média típust is megadni, tehát nem szükséges komplikálni a nyomtatási stílusokat.

A WebKit nem egy elterjedt böngésző, viszont példaértékűen elöljár a szabványok beemelésében, és sok más böngészőnek a motorja. Innen már csak az a kérdés a többi böngészőfejlesztő mikor csatlakozik, illetve – érdekességképpen -  melyik Adobe AIR verzióban használhatjuk majd.

Aki kedvet kap hozzá, szerezzen be egy friss webkitet, és lesse meg a tesztoldalakat.

a firefox 3 “rátelepedett” a ctrl-shift-s billentyűkombinációra (nézet -> oldalsáv -> könyvjelzők). remélem hamar megoldódik, mert én is sokat használom | gex hozzászólása

Nos a megoldás egy keyconfig nevű extension lehet, amivel kényünk kedvünk szerint módosíthatjuk a billentyűkombinációkat és jelzi ha ugyanaz a kombináció van beállítva több funkcióhoz.

Amire ilyenkor viszont mindíg figyelni kell, az az, hogy a nagy cache fileok felzabálhatját a tárhelyed, ha nem ellenőrzöd ezeket a kéréseket rendesen. Megvallom, főleg front-end fejlesztőként bele se gondoltam pár dologba.

Mivel a CSS fileok szabadon elérhetőek kell legyenek a böngésző számára, lehetséges módosítani a lekérést, átrendezni a lekért fileok sorrendjét, duplikálni egy vagy több file nevét, s ezzel akár több ezer variációt is létrehozhatunk, ami simán betelítheti a tárhelyünket css fileokkal.

A hozzáférés szabályozása lehet komplikáltabb, figyelni a lekérések elemeit, sorrendiséget, vagy egyszerűbb, pl egy konkrét lekérdezést engedélyezni, ami lehet elég is, ritka az hogy egy sitehoz újabb css file-t adunk hozzá a napi karbantartás során. A lényeg az, hogy ilyen egyszerű dolgok is biztonsági kockázatot jelenthetnek egy oldal illetve szerver működése szempontjából.

A “Gray” és “grey” szavak a fekete és a fehér közötti színárnyalatot jelentik.

Az Internet Explorer szerint a “grey” nem szín. A “gray” az.

Az előbbi mód mellett érdekes módon a kód átláthaóságát hozzák fel fő érvként, hisz egymás alatt látjak a selectorokat, könnyű keresni.

Engem anno hagyományos módon tanitottak programozni, a logikai blokkok szépen elkülönítve, kódsorok egymás alatt. Hamar megtanultuk, hogy kódban – aminek makacs tulajdonsága, hogy egy idő után lefelé nyúlik a szerkesztőfelületen – vízszintesen scrollozni néha maga a pokol. Ugyanez vonatkozik a css kódokra is.

Az első érv pedig – a selectorok átláthatósága – nem sokat ér, ha egy rendes szerkesztőben egy outliner-el nézzük a kódot, ahol – legyenek a valóságban bármilyen sorrendben a selectoraink – általában abc sorrendben is megnézhetjük a kódunk szerkezetét.

Persze lehet, hogy nem a fejlesztő, hanem az általa megszokott eszköz a hibás, de vélemenyem szerint valahol jellemzi a fejlesztőt és munkamenetét az eszköz amit használ. Munkacsoportokban, ahol mindenki a saját megszokott eszközével dolgozik, a következő ember aki a kódhoz nyúl, lehet, hogy sorokra tördeli a kódot, ekkor – az eszköz hibájából – az előző fejlesztő már lehet, hogy hátrányban lesz.

Másik gyenge érv amit hallani lehet, a kód “tömörsége”, de ez rendes CDN-ekkel, szerveroldali cachelessel elegánsan megoldható, ettől a fejlesztőknek nem kéne a tömör kódot “visszafejteni”.