Näita sildipilve

Cross-domain fondi probleem ja lahendus

Cross-domain (cross-site) font-face issue solved

Kirjutas ,

Tänapäeval on üpris levinud see, et koduleheküljel kasutatakse oma fonti. Eriti on andnud sellele hoo sisse nn ikoonifontide kasutuselevõtt. Ikoonifondid pakuvad väga head alternatiivi siis, kui soovitakse hoida veebilehe kõiki ikoone ühes failis nii, et need oleksid resolutsioonist sõltumatud. See muudab imelihtsaks kujunduses ikoonide kasutamise, kuna tänu sellele, et tegemist on fondiga, käitub selles ikoonid kui tähed, mida me igapäevases kirjasuhtluses kasutame.

Kui veebileht töötab vaid ühel aadressil (domeenil), on kõik suurepärane. Aga kui tuleb luua veebikeskkonda, millel on näiteks kolm osapoolt ja kõik kolm jagavad ühte ja sama kujundus, aga erinevat domeeni, hakkab oma fondi kasutamine näitama oma kitsaskohti. Just olukorras, kus kõik kolm osapoolt kasutavad ühte ja sama malli, mis tuleb ühest ja samast kohas (aadressilt). See tähendab, et vähemalt kahel osapoolel on olukord, kus rakendus töötab ühel, aga kujundus (sh font) tuleb teiselt aadressilt. Tekib nn mitmedomeeniline (cross-domain) olukord. Mis siis selles halba?

Kui lüüa lahti nii Internet Exploreri kui ka Mozilla Firefoxi dokumentatsioon just sellest kohast, kus kirjutatakse @font-face-st, võime leida, et nemad on oma veebilehitsejasse sisse kirjutanud teatud piirangud. Nemad lubavad kasutusele võtta vaid samalt domeenilt tulnud fonte. Seega nii Internet Exploreris kui ka Mozilla Firefoxis ei näita ikoone, kui fonti küsitakse mõnelt teiselt domeenilt.

HTTP access control

Nii Internet Explorer kui ka Mozilla Firefox võimaldavad aga neid piiranguid pehmendada. Selle jaoks on W3C välja töötanud soovitused Cross-Origin Resource Sharingmis kirjeldab üksikasjalikult meetodeid, kuidas võimaldada kliendipoolsete päringute täitmist. Praeguses kontekstis huvitab meid peatükk 5.1 Access-Control-Allow-Origin Response Header, mis kirjeldab seda osa, kuidas võimaldada valitud domeenidelt päringute täitmist. Tegemist on siis teoreetilise dokumendiga. Aga kuidas see näeb välja praktikas?

Kui sul on SEO sõbralike URL-idega kodulehekülg, siis väga suure tõenäosusega leiad oma serverist faili .htaccess. Tegemist on siis failiga, milles on kirjas kataloogiülesed reeglid. Ehk kui keegi pöördub läbi veebilehitseja selle kataloogi poole, siis selles failis on kirjas, mida selle pöördumisega peale hakata.

<IfModule mod_headers.c>
     <FilesMatch "\.(eot|otf|ttc|ttf|woff)$">
        Header set Access-Control-Allow-Origin "http://example.com"
     </FilesMatch>
 </IfModule>

Lisades .htaccess faili need read, lubame FileMatch tingimustele vastavatele failidele ligi domeenilt http://example.com. Kui aga on soov mitte täpsustada domeeni, võib selle asemel kirjutada ka "*", mis määrab reegliks, et ükskõik milliselt domeenilt on juurdepääs nendele failidele lubatud. Muidugi "*" kasutamisel tuleks kindlasti korraks mõelda, kas nendele ressurssidele ikka peaks igaüks ligi saama.

Oma projektides olen veel täpsustanud seda, milliste MIME tüüpidega fonte veebilehitsejasse saadetakse. Kui saata faile veebilehitsejasse puudulike idetifikaatoritega, võib see tekitada anomaalaid. Seega on igati viisakas täiendavalt lisada ka alljärgnevad read.

<IfModule mod_mime.c>
	 AddType application/vnd.ms-fontobject .eot
	 AddType font/ttf .ttf
	 AddType font/otf .otf
	 AddType application/x-font-woff woff
</IfModule>