Most, hogy a teljesen rendszertelenül frissülő blogomon a hasznos információkban, illetve érdekes sztorikban egyáltalán nem bővelkedő bejegyzéseimmel elértem az olvasóközönség megtizedelődését, végre nyugodtan beszélhetünk a hüv... olyan témákról, amelyek amúgy sem érdekelnek senkit. Ilyen például az, hogy beágyazott betűkészletek használatakor miért nincsenek szép félkövér és dőlt betűink. Popcornt elő, kezdődik!

Alapszituáció

Régről magunkkal hozott szellemi defektus vagy a múzsa hirtelen homlokunkon csattanó csókjának hatására úgy döntünk, hogy a weboldalunkon megjelenő hosszabb szöveget — cikket, bejegyzést, Coelho-idézetet — a jól megszokott Arial, Georgia és társaik helyett valami egyedi betűtípussal fogjuk szedni, mert az menő dolog. Ez az elhatározás egyben azt is jelenti, hogy láthatatlan lábunkkal automatikusan felrúgunk egy óriási, szintén láthatatlan szarosbödönt is — ennek a feltakarításáról szól a hátralévő hétezer karakter.

(Megjegyzés: az egész problémakör arra az esetre vonatkozik, amikor a betűkészleteket mi magunk készítjük elő a beágyazásra, nem pedig a Google Web Fonts-ot vagy más, hasonló webfont-szolgáltatást használunk. Gondolom azoknál ez egy túlhaladott és magától értetődő dolog, de írjátok meg, ha nem.)

Tegyük fel, hogy minden nehézség ellenére sikerült meglelnünk a tökéletes betűkészletet: magyar ékezetek, élhető élsimítás, kétzónás digitklíma. A példa kedvéért legyen a választottunk a Paratype Serif család. A Fontsquirrel-ről nemcsak beszerezni tudjuk, hanem az ottani font-face kit generátorral el is tudjuk készíttetni a beágyazáshoz szükséges összes formátumot — EOT, WOFF, TTF, SVG —, amivel együtt megkapjuk a stíluslapba illesztendő kódrészletet is. Nekünk a normál készlet kell, a hozzá tartozó kódrészlet:

A stíluslapon tehát ezek után megadjuk, hogy a szöveg betűtípusa PTSerifRegular legyen (vagy át is nevezhetjük, ha a harmadik sorban megváltoztatjuk a nevet) és ha mindent jól másoltunk be, illetve a betűkészlet is a helyére került a tárhelyen, akkor már látjuk is a böngészőben az egyedi megjelenésű szövegünket. És a bödön illatozni kezd:

A szöveg nagyja rendben van, a félkövér betűk csak kicsit furcsák, de a dőlttel szedettek... Nem erre számítottunk. Nem írtunk el semmit, minden elérhető helyen van, a böngészőnk sem régebbi másfél évesnél, akkor mi lehet a baj? Miért olyan ocsmányak a dőlt betűk?

Hamisgulyás

A helyzet az, hogy semmi baj sincsen; amit látunk, az a böngészőnk megfelelő működését mutatja. A jelenség megértéséhez először nézzük meg ugyanezt a weboldalt úgy, hogy a beágyazott betűkészlet helyett Georgiát használunk:

Vegyük észre, hogy a normál betűkhöz képest a félkövér és a dőlt betűk nem csak a dőlésszögben vagy a vonalvastagságukban különböznek, hanem gyakran teljesen más rajzolatúak. Amikor a böngésző azt látja, hogy egy szövegrészletet mondjuk dőlttel kell megjelenítenie, akkor letárgyalja az operációs rendszerrel, hogy van-e a Georgia betűkészletnek elérhető dőlt változata és ha van, abban hogy néznek ki a kérdéses karakterek, aztán szépen kirajzolja őket. (Az előző mondat szakmaiatlansága miatt háborgók tehetnek egy szívességet: írják le a folyamatot kommentben szabatos és közérthető módon! Előre is 10Q!)

Abban az esetben viszont, ha nincs ilyen betűkészlet — és mivel mi csak a PT Serif normál változatát ágyaztuk be, a mi esetünkben is —, akkor a böngésző megpróbálja a kérdéses betűket valahogyan helyettesíteni, hogy dőltnek vagy félkövérnek nézzenek ki, ezt pedig úgy éri el, hogy fogja a normál változat betűformáit és a saját implementációjának megfelelő módon előállítja belőlük a megfelelő vastagított vagy döntött formákat, amik jobb-rosszabb közelítései a kívánt betűalakoknak, de természetesen sohasem fognak úgy kinézni, mint amit a betűtípus tervezője megrajzolt. Ezeket a variánsokat illetik a faux bold, faux italics, faux caps nevekkel.

Mindezek ismeretében mindenki eldöntheti, hogy belefér-e a világképébe, hogy a normáltól eltérően szedett betűinek ilyen a megjelenése vagy veszi a fáradságot és a plusz erőforrásigény ellenére is ragaszkodik a valódi dőlt és félkövér karakterekhez. A döntést jelentősen megkönnyíti, ha a választott betűkészletnek egyáltalán nem léteznek más variánsai, mert vagy beletörődünk ebbe a kis csorbába (ami minden alkalommal szúrni fogja a szemünket életünk végéig vagy a következő dizájnváltásig, attól függ, melyik következik hamarabb), vagy megpróbálunk találni egy másik ingyenes fontot, ami legalább ilyen jó.

Igényelem a nagynevű márkákat

Ha nem tűrünk megalkuvást, akkor a következő a teendőnk.

Először is vegyük észre, hogy a PT Serif családban találunk dőlt és félkövér készletet is (a ptf55f a normál, a ptf56f a dőlt, a ptf75f pedig a félkövér változat neve), úgyhogy a normál mellett ezekből is gyártsuk le a beágyazható formátumokat, majd másoljuk fel őket a tárhelyre, illetve nézzük meg a kapott CSS-t:

Itt az látjuk, hogy immár három betűkészletet definiáltunk (a normált, a dőltet és a félkövért), ám ettől semmi sem fog változni: a böngésző ugyanis azt látja, hogy megadtunk három különböző betűkészletet (hiszen eltér a nevük), ráadásul mindegyik normál stílusú és normál vastagságú betűket tartalmaz. Ilyenformán a szöveget hiába íratjuk ki PTSerifRegular betűtípussal, a variánsai továbbra is csak hamisak lesznek, kivéve, ha felveszünk a CSS-be olyan szabályokat, amik egzaktul megmondják, hogy a félkövért PTSerifBold, a dőltet pedig PTSerifItalic betűvel kell szedni, ami azért eléggé nonszensz.

De nem véletlenül vannak ott a font-face deklarációs blokkok végén azok a font-weight és font-style tulajdonságok! Mindhárom betűkészlet ugyanahhoz a betűtípushoz tartozik, csak eltérő változatok — miért ne lehetne őket a definíciókban is összekapcsolni és megadni, hogy melyik melyik változat? Nos, lehet. Így:

Először is mindhárom blokkban azonosra módosítjuk a betűkészletek hivatkozási nevét (de az src-kben lévő részeket békén hagyjuk), aztán a dőltnél a font-style-t írjuk át italic-ra, a félkövérnél pedig a font-weight-et bold-ra, és a szöveg tulajdonságai között se felejtsük el megváltoztatni a PTSerifRegular-t arra, amit itt megadtunk. Az eredmény:

A dőltbetűs részek gyönyörűek, a félkövérek pedig jóval kevésbé szőrösek. Hazaértünk, mint a láthatatlan légió.

Dolan pls

Innentől kezdve a böngésző már tudni fogja, hogy mikor melyik betűkészletet kell elővennie, mi pedig önfeledten örülhetünk annak, hogy elfecséreltünk másfél órát az életünkből egy olyan problémára, ami rajtunk kívül a világon pont senkit nem bosszant.

A lényeg az, hogy ott belül te tudod, és ez a lényeg. Vagy ezt már mondtam?

Jeffrey Zeldman nemrégiben alaposan átalakította a weboldala arculatát. Íme egy miniatűr képernyőkép, mellette pedig egy 100%-os nagyítású részlet:

Legmarkánsabb változtatásként felhúzta a szövegtörzs betűméretét egészen 24 képpontig, a cikkek leadje pedig ennél is nagyobb betűvel van szedve. Ez néhány olvasójánál kiverte a biztosítékot, Zeldman pedig további hangulatkeltés végett egy kiváló válaszposztot kanyarított. A Web Design Manifesto 2012-ben többek között ezt írja az Instapaper, a Readability meg a dizájn- és hirdetési hatékonyság-központú weboldalak kapcsán:

[...] it indicates how pathetic much of our web design is when our visitors increasingly turn to third party applications simply to read our site’s content.

Azaz ha azt szeretnéd, hogy az olvasóid ténylegesen olvassanak és időt töltsenek el az oldaladon, akkor tálald úgy a tartalmat, hogy szívesen tegyék azt és ne akarják más forrásból vagy bármi módon átalakítva fogyasztani. A tartalom előtérbe helyezése egyébként sem egy elvetendő gondolat, kezdve azzal, hogy az oldaladon megjelenő szöveg lehet a dizájn központi, egyben legfontosabb és leglátványosabb eleme. (Épp ezért is lehet vele nagyon mellényúlni.)

Zeldman szerint egyébként hamarosan eljön közénk a nagybetűs internet:

I don’t think you will see much type quite this big but I do think you will see more single-column sites with bigger type coming soon to a desktop and device near you. [...] In today’s monitors and operating systems, yesterday’s classic web fonts — the ones that come with most everyone’s computer — can look pretty danged gorgeous at large sizes.

Már csak azért is, mert a klasszikus webbiztos betűtípusokkal ellentétben a jelenleg népszerű ingyenes és fizetős beágyazott betűkészletek jelentős része ritka ocsmány módon néz ki 15 pixelnél kisebb méretben (részben, mert eleve ennél nagyobb méretben való felhasználásra lettek tervezve, részben a böngészők és az alattuk elterülő operációs rendszerek eltérő élsimítási megoldásai miatt).

Nekem egyébként tetszik ez az irányzat, még ha nem is konkrétan a plakátra való vonulata. Neked?

Handrás farzsebéből kikandikál az iPhone:

Persze tudom mit fognak sokan mondani, hordjam első zsebben a telefont, de nekem ott nem kényelmes.

Egyrészt őszinte gratulációm, másrészt ez egy régen túlhaladott probléma, de azért nézzünk meg egy alternatívát a kevésbé jók közül:

Eric Meyer bosszankodik egy sort a CSS-re jellemző inkonzisztencián:

The fact that this:

h1 { color: red; }
h1 { color: green; }

…results in green h1 text, but this:

h1 { background-image:
    url(red-wave.gif) repeat,
    url(green-wave.gif) repeat; }

…results in a red wavy h1 background does my head in every single time. And it’s the same with text and box shadows, too! In cases where backgrounds or shadows overlap, the first one you write “wins”, by virtue of being “in front of” the background images that are listed after it.

Végülis érthető. Annak idején számomra a margin, a padding és a többi hasonszőrű tulajdonság értékeinek sorrendje volt a mumus, de aztán egyszer véletlenül jókor néztem rá a karórámra.

Mivel JonC csütörtökön ismét eltörte a blogmotort, nem maradt más választásom, mint hogy előálljak a megoldással a véletlen hozzászólás-duplikátumok keletkezésének problémájára.

A probléma ugyebár annyi, hogy ha írsz egy hozzászólást a blogra és utána újratöltöd az oldalt, akkor a böngésződ az űrlap tartalmát megleli a cache-ben, a ténylegesen beírt dolgok mellett azt is, hogy meg lett nyomva a küldés gomb, és ennek megfelelően ismét odaadja az adatokat a blogmotornak, az meg a szokásos módon végrehajtja a komment rögzítését, mert neki ez a dolga, és máris ott figyel a bejegyzés alatt ugyanaz a hozzászólás kétszer, ötször, tízszer.

Ez több szempontból sem nevezhető jónak. Egyrészt ezeket nekem kell törölgetnem, másrészt néha felborul miattuk a kommentek sorrendje (amit perpillanat nagyon nem értek; egyazon rendezett lekérdezésre az adatbáziskezelőből jó eredmény jön ki, de PHP-val történő kilistázáskor felcserélődnek a rekordok), harmadrészt pedig ennek egyszerűen nem így kellene működnie.

A megoldást abban láttam, hogy az űrlapot és az őt megjelenítő oldalt valahogyan összekössem, pontosabban elérjem azt, hogy a konkrét oldal el tudja dönteni, hogy hozzá tartoznak-e a cache-ben lévő űrlapadatok. Ehhez szükség van egy session változóra és az űrlapot ki kellett egészítenem egy rejtett típusú mezővel. Először generálok egy azonosítót (ami egy MD5-tel kódolt véletlenszám), ezt adom értékül a session változónak és a rejtett mezőnek is minden egyes oldalbetöltés során. Ha megtörténik az űrlap elküldése, a komment rögzítését végző alprogram ellenőrzi, hogy az űrlap rejtett mezőjének értéke és a session változó értéke megyegyezik-e. Ha megyegyeznek, akkor elmenti a hozzászólást és visszatérünk a bejegyzéshez, egyébként viszont zero fucks are given. Ismét megjelenik az oldal, a változónk kap egy új értéket, akárcsak az űrlap rejtett mezője.

Amikor ugyanis a hozzászólás küldése után megnyomod az F5-öt (és leokézod a figyelmeztetést), a szkript újra leellenőrzi a két érték egyezését, csakhogy a session változó értéke azóta megváltozott, a rejtett mező értékét viszont továbbra is a cache-ből szedi a böngésző, amik így nyilván nem fognak egyezni, azaz a komment egy duplikátum, tehát eldobható.

Az egésznek tehát az a lényege, hogy ezentúl mindenki pontosan annyi hozzászólást fog beküldeni a blogra, ahányszor megnyomja az űrlap végén a gombot. Tiszta Amerika!