Aetles » Webbutveckling

Google Web Fonts i Internet Explorer 7 och 8

Adrian Bengtson — Tue, 20 Dec 2011 12:38:00 +0000

Hur man löser problemet med vikter och stilar i Internet Explorer 7 och 8 när man använder Google Web Fonts.

Tänk att webben äntligen fått fungerande användning av typsnitt. Inte nog med det, utöver ett gäng utmärkta kommersiella tjänster för webbtypsnitt har Google släppt ett antal fria webbtypsnitt samt ett bra verktyg för att testa utseende och kombinationer tills man är nöjd. När man är är klart får en enkel rad att lägga in i HTML-koden på webbsidan och så är det bara att tuta och köra!

Det vill säga, ända tills man kollar hur det ser ut i Internet Explorer.

Detta är ett exempel på en kodrad från Google Web Fonts där jag valt ut två typsnitt och lite olika stilar och vikter:

Man lägger in koden på sidan, skapar lite CSS-mallar och sen kan det se såhär fint ut (skärmbild från Firefox):

Inte så dumt va? Enligt Google ska Google Web Fonts fungera även med Internet Explorer, men det kan vara värt att kolla en gång. Här är en skärmbild från Internet Explorer 8:

Aj då. Inte fullt så bra. Låt mig belysa vad som är fel (jämför med den tidigare skärmbilden från Firefox):

Vad som händer här är att Internet Explorer laddar in typsnitten, men bara i standardformen, dvs ”regular”-varianten av typsnittet. Sen görs falsk fet stil och falsk kursiv stil. Falsk kursiv stil är lätt att se på bokstäver som lilla a och g som ser helt annorlunda ut i äkta kursiv stil.

Problemet med Google Web Fonts i Internet Explorer beror delvis på att Internet Explorer (i version 8 och tidigare) inte laddar typsnitten rätt när det finns flera varianter och delvis på Googles upplägg. Ett lösning som kan hjälpa till en viss del är att ladda Googles CSS separat för varje typsnitt:

Detta är dock inte en tillräcklig lösning för det hjälper inte när vi vill ha flera vikter av samma stil (normal, fet, extra fet osv) eftersom Internet Explorer inte hanterar flera vikter av ett och samma typsnitt. Det blir dessutom onödigt många förfrågningar till Google.

Ett bättre sätt är att kopiera Googles @font-face-definitioner direkt in i vår egen CSS. Då kan man nämligen byta namn på typsnitten och komma runt problemet med olika vikter. Här är en skärmbild från Internet Explorer 8 där jag använt mig av denna teknik.

Och nu fungerar både kursiv och fet stil så som det är tänkt, hurra! Läs vidare för mer info om denna lösning ser ut.

För att kopiera Googles CSS laddar man helt enkelt URL:en i Internet Explorer, till exempel:

http://fonts.googleapis.com/css?family=Lato:900

Som svar från Google får man då:

@font-face { font-family: 'Lato'; font-style: normal; font-weight: 900; src: url('http://themes.googleusercontent.com/static/fonts/lato/v4/BjDVcwQGWPX2RAidnkd0Bw.eot'); src: local('Lato Black'), local('Lato-Black'), url('http://themes.googleusercontent.com/static/fonts/lato/v4/BVtM30trf7q_jfqYeHfjtA.woff') format('woff'); }

Det är denna kod vi ska använda, men vi ska byta namn på typsnittet. I detta fall byter vi Lato mot LatoBlack:

font-family: 'LatoBlack';

Detta får man göra för varje variant man vill använda i sitt dokument. Kom ihåg att typsnitt tar tid att ladda in, så används så få typsnitt och så få varianter som möjligt på en sida, för att din sida inte ska bli tungladdad för besökarna.

Vi vill inte att varje webbläsare ska läsa in detta dock, utan bara Internet Explorer 8 och tidigare. Därför använder vi ”conditional comments” för att bara ge vår extrakod till rätt webbläsare:

Förutom @font-face-definitionen behöver vi även ange extra CSS för att säga åt IE att använda vårt nya namn på typsnittet:

.test { font-family: 'LatoBlack', serif; }

Ett komplett exempel skulle därmed kunna se ut såhär med tre varianter av Lato:

Test of Google Web Fonts

Making the Web Beautiful!



Making the Web Beautiful!


Making the Web Beautiful!

Svårare än så var det inte :) Här finns ovanstående kod som fristående sida.

Jag har testat lösningen i Internet Explorer 7 och 8 och så vitt jag kan se fungerar det bra. Ett tänkbart problem skulle kunna vara att Google ändrar sina @font-face-definitioner som vi nu hårdkodad in på vår sida, det kan vara något man behöver hålla under uppsikt. I moderna webbläsare som Safari, Chrome och Firefox är det inget problem att använda Google Web Fonts.

Den här diskussionen hos Google hjälpte mig på traven för att lösa detta problem som Google själva inte verkar vilja lösa.

Uppgraderad till WordPress 2.7

Adrian Bengtson — Sun, 14 Dec 2008 04:24:08 +0000

Jag har precis uppgraderat denna WP-installation till 2.7. Jag var rätt noggrann med alla steg för att få en så fräsch installation som möjligt.

Sen redde jag en gång för alla upp den soppa som skapades av att WP en gång i tiden använde ISO Latin 1 som teckenkodning och det som låg i databasen var en slags specialfelkodad historia som fungerade, men krävde lite hack. Jag fick helt enkelt söka för hand igenom en export av databasen på jakt efter alla udda tecken (åäöÅÄÖéèáàüÉÈÁÀ osv) och ersätta dom med de rätta. Samt ställa in alla fält i alla databastabeller att använda UTF-8. Så nu har jag förhoppningvis lämnat teckenkodningshelvetet bakom mig och kommit till det förlovade landet av enbart UTF-8 när det gäller denna sida.

Nästa steg blir att jämföra temat här (som är en egen översättning av WordPress gamla default-tema) med det senaste default-temat så jag drar nytta av de senaste tema-relaterade funktionerna (främst kommentarer har fått lite nya finesser i 2.7).

WordPress-folket har förövrigt gjort ett otroligt bra jobb de senaste året med att ta WP till en ny nivå och 2.7 är en riktig milstolpe. Jag jobbar mycket med Drupal i mitt dagliga jobb och det är inte utan att man ibland man önskar att Drupal hade tagit samma elefantkliv mot användarvänlighet som WordPress gjort senaste åren.

Drupal är fortfarande bättre för mer avancerade sajter, men WordPress är mycket mera behagligt att använda för enklare sajter. Bara att applådera och hoppas att Drupals core-utvecklare slutar med sitt löjliga ”Drupal is not WordPress” och istället inspireras och kopierar det som WordPress-folket gjort bra med WordPress.

Popup visar faran med obevakad gästbok

Adrian Bengtson — Sun, 16 Sep 2007 21:29:20 +0000

Förra hösten anordnade Umeå Open en mycket trevlig endagsfestival vid namn Popup. Lisa Miskovsky och Khoma var två av artisterna och det var grymma spelningar. Det sägs att festivalen även blir av i höst med bland annat Sahara Hotnights på scen. Men hemsidan visar dock ingen information om ny festival ännu.

Vad Popups hemsida däremot har – och vad som detta egentligen handlar om – är en gästbok som de ansvariga glömt bort.

Gästboken innehåller just nu när detta skrivs 7653 inlägg. Det vore en bra siffra om det inte vore för att endast 24 inlägg är riktiga inlägg, de resterande 7629 inläggen är spamkommentarer!

Jag har berört ämnet tidigare i samband med mina egna problem med spamkommentarer. Man kan inte låta sidor som anonymt tar emot kommenterar ligga obevakade som Umeå Open gjort i detta fall. Nu har de på sin egen hemsida 7629 inlägg som gör reklam för allt från Anabolic Steroid till free porn video clips.

Detta handlar inte om att hänga ut den utmärkta Popupfestivalens webbansvariga, utan om problemen idag på nätet med spamkommentarer. Skripten som automatiskt postar kommentarer är obevekliga och under ett års tid hinner det samlas stora mängder ifall ingen håller koll på det.

Jag jobbar bland annat med en sajt där elever kan skriva artiklar som de sparar så administratörerna kan gå igenom dom och lägga ut dom på hemsidan. Detta är ett hemmabygga och det är ingen stor sajt utanför sina kretsar, men lik förbannat hittade spambotarna dit och började skicka in artikel efter artikel.

Spamartiklarna hamnade aldrig på hemsidan eftersom de måste godkännas manuellt, men det blev ett drygt jobb för administratörerna att rensa, innan jag kunde vidta åtgärder som stoppade botarna. Spambotarnas försök var alltså dödfött från början, men det spelar förstås ingen roll eftersom allting är automatiserat. De letar ständigt på nätet efter alla typer av formulär där de kan skicka in sitt spam, i förhoppningen om att det landar på en webbsida någonstans.

Jag har på senare tid även början kika närmare på Project Honey Pot som är ett intressant försök att fånga spambotar med så kallade ”honey pots”, ungefär på samma sätt som man fångar getingar med en burk med lite honung i. Jag har skapat en egen honey pot, men än så länge inte fångat några spambotar.

Ny version – tillfälligt utseende

Adrian Bengtson — Tue, 17 Jan 2006 12:36:51 +0000

Jag har uppdaterat WordPress från den uråldriga 1.2 som drev Aetles fram till den senaste versionen, 2.0 (2.0.1 är visst pågång snart, men den verkar fungera så jag kör med 2.0 tills vidare). Jag har dock inte gjort ett tema av Aetles gamla utseende. Därför kör jag på det förvalda temat som finns i WP (dock den svenska varianten) tills jag gjort detta. Därför ser det så annorlunda ut här jämfört med hur det brukar se ut.

WP 1.2 har fungerat bara fint för mig faktiskt, men på sistone har jag börjat få så mycket kommentarsspam. Visserligen kom det nästan aldrig ut på sidan, men jag fick massa mejl (ett för varje spam) och det började bli tröttsamt. Sedan tidigare har jag kört WP 1.5 på bröllopssajten och det har fungerat bara fint det med.

Förbättring av ”Fade Anything Technique”

Adrian Bengtson — Thu, 06 Oct 2005 10:28:13 +0000

Jag har använt mig av en javascript-teknik på vår bröllopshemsida för att få en lite flashig effekt på länkarna i menyn. Tekniken är en egen vidareutveckling av Richard Livseys variant av Adam Michelas ”Fade Anything Technique” (en länk som inte verkar fungera längre, tyvärr). Tekniken, som förkortas FAT, är i sin tur inspirerad av 37 Signals ”Yellow Fade Technique”.

Min variant av FAT har fungerat utmärkt i webbläsare som Firefox och Internet Explorer 6. I Safari har den fungerat, men bara delvis, och det har stört mig. Men nu har jag äntligen löst detta problem!

Tekniken går ut på att tona bakgrundsfärgen av ett objekt från ursprungsfärgen till en vald färg när man för pekaren över ett (annat eller samma) objekt. När man flyttar muspekaren från objektet ska färgen tonas tillbaka till ursprungsfärgen.

Problemet i Safari var att javascriptet inte lyckades få Safari att läsa av ursprungsfärgen korrekt. Jag har gjort en exempelsida för att visa detta.

Såhär ser koden ut för att läsa av bakgrundsfärgen på objektet ”o” i scriptet:

if (window.getComputedStyle) c = window.getComputedStyle(o,null).getPropertyValue("background-color");

if (o.currentStyle) c = o.currentStyle.backgroundColor;

if ((c != "" && c != "transparent") || o.tagName == "BODY") { break; }

Första raden (det är tre rader kod i scriptet, även om det kanske är brutet extra här på denna sida) använder getComputedStyle för att läsa av bakgrundsfärgen, vilket fungerar i Mozilla-webbläsare. Andra raden använder currentStyle för att läsa av bakgrundsfärgen, vilket fungerar i Internet Explorer. Tredje raden kollar om någon färg har hittats och om den inte är ”transparent” eller om objektet är BODY, i så fall bryts loopen som koden ligger i. Bryts inte loopen så testas det överliggande objektet för att se om det har en bakgrundsfärg, ända upp till BODY alltså.

Problemet är att getComputedStyle inte fungerar på samma sätt i Safari som i Mozillas webbläsare. För det först verkar man måste anropa det på ett annat sätt och för de andra returnerar det ett annat svar om bakgrundsfärgen är transparent. För att läsa detta fick jag ändra ovanstående kod till följande kod:

if (window.getComputedStyle) c = window.getComputedStyle(o,null).getPropertyValue("background-color");

else if (o.currentStyle) c = o.currentStyle.backgroundColor;

else c = document.defaultView.getComputedStyle(o,null).getPropertyValue('background-color');

if ((c != "" && c != "transparent" && c != "rgba(0, 0, 0, 0)") || o.tagName == "BODY") { break; }

Här har jag möblerat om lite så att det blir en ”if – if else – else”-sats istället och lagt till en rad som anropar getComputedStyle på ett annorlunda sätt som fungerar i Safari. På sista raden har jag även lagt till Safaris variant av att säga att färgen är genomskinlig, nämligen ”rgba(0, 0, 0, 0)”.

Detta är i princip allt som behövdes för att lösa problemet, det ser enkelt ut men det tog mig några timmars felsökning att komma fram till det. Testa det fungerande exempelscriptet för att se hur Safari hittar rätt bakgrundsfärg.

En liten redesign

Adrian Bengtson — Mon, 15 Nov 2004 01:31:55 +0000

Jag har gjort en rejäl ansiktslyftning på hemsidan för min egen enskilda firma, Adagio design. Sidorna är inge märkvärdiga, det finns inte så mycket att läsa där, men det är ändå ett stort lyft mot de gamla sidorna. Jag har försökt skriva lite mera säljande text och förklara bättre vad jag kan, men framförallt har jag använt mig av lite modernare webbtekniker, nu är det en CSS-baserad layout som validerar. Och så har jag börjat använda nya loggan.

Nästa steg är att fylla på med lite mera info, till exempel en presentation av mig personligen med foto och sånt. Men först ska jag kontrollera att sidorna ser bra ut i IE/Win, jag befarar att det antagligen ser skräp ut, för det har en tendens att göra det, speciellt när man börjar använda de nya webbstandarderna. I Safari och Firefox på mac är sidorna i alla fall tipptopp.

Firefox-sökplugin för hitta.se

Adrian Bengtson — Wed, 07 Jul 2004 17:41:38 +0000

Jag har precis skapat en sökplugin för hitta.se som fungerar i Firefox 0.9.1 (bland annat). Med ett klick kan du installera denna sökplugin och söka på personnamn, företagsnamn, telefonnummer och mobilnummer direkt i webbläsaren. Mycket smidigt!

Lycka är lyckad problemlösning

Adrian Bengtson — Fri, 11 Jun 2004 01:17:31 +0000

Klockan är på tok för mycket och jag kommer att vara alldeles förstörd imorgon bitti, men just nu är jag väldigt nöjd och glad. Jag är så stolt över en bit php-kod jag skrev för min hemsida, adrianb.info. Det är problemlösning och programmering som är vardagsmat för riktiga programmerare, men för en hackare som jag är det väldigt tillfredsställande och egoförstärkande att lyckas med sådant.

Jag har sedan tidigare en funktion på mitt fotoalbum som slumpar fyra bilder från albumet, men koden var väldigt simpelt gjord (även om jag är stolt över den också). Nu ville jag utöka antalet bilder och istället för att bara bygga på nuvarande kod bestämde jag mig för att göra det snyggt istället. Det som var omständligt i min gamla kod var kontrollen av att inte två slumptal var lika. Samt att jag nästan inte använde några loopar, utan skrev alla steg fyra gånger. Lätt kod att förstå, men oflexibel och arbetsam att modifiera. Och alldeles för många rader.

Min nya slumpfunktion är mycket snyggare gjort och jag behöver bara justera en enda variabel för att utöka eller minska antalet bilder. Och bäst av allt, den fungerade på första försöket! Tillfredsställelsen går nästan inte att beskriva. Geekigt, javisst. Men oavsett vad man tar sig för här i livet så tror jag man blir väldigt nöjd när man löser problem på ett bra sätt och det fungerar som tänkt. Jag har dock inte självförtroende nog att publicera koden. Så bra är den inte. :)

Resultatet kan i alla fall beskådas på adrianb.info. En sida som jag förövrigt jobbat mycket med överhuvudtaget. Jag plockar de senaste texterna från denna blogg (tack till utvecklarna av WordPress för att det är så otroligt enkelt att jobba med) samt slumpar ett gäng bilder från mitt fotoalbum. Designen är tagen från denna blogg, eftersom det är den design jag jobbat så mycket med nyligt.

Nästa steg är att få mitt fotoalbum att följa samma design. Det ska blir spännande och vore det inte för att jag ska vara på jobbet om ungefär 6 timmar och inte har sovit något ännu så skulle jag sätta igång med det omedelbart.

En bit på vägen

Adrian Bengtson — Wed, 09 Jun 2004 00:03:02 +0000

När man ska lära sig bygga CSS-baserade webbsidor (istället för att harva på i ”tabellträsket”) måste man lära sig två saker:

1) CSS, dvs modellen, syntaxen, osv.
2) Alla buggar och felaktigheter i de olika webbläsarna som gör att CSS inte fungerar som tänkt.

I en värld där alla använder Firefox/Mozilla skulle punkt 2 inte behövas. Men där är vi inte. I en värld där alla hade senaste modellen av valfri modern webbläsare skulle punkt 2 vara lindrig. men där är vi inte. Tyvärr.

Utan att vara någon CSS-expert (långt ifrån) så påstår jag ändå att nästan allting fungerar faktiskt som tänkt i Mozillas renderingsmotor. Safari är inte lika bra, men nästan. När jag gjorde iordning den här designen jobbade jag i Firefox och Safari och allting såg mycket bra ut. Sen kollade jag det i IE5/Mac och IE6/Win och då var det inte lika kul längre.

Med hjälp av en kollega och lite testande så lyckades jag få till flera av problemen med IE6/Win genom att ändra lite mindre detaljer. Men i IE5/Mac var det värre. Texten i löpet på sidan förskjöts åt höger mer och mer för varje ny text och rubrik. IE5/Mac är en ganska bra webbläsare, när det gäller att följa CSS-standarden. Den är i alla fall betydligt bättre än IE5/Win som är skräckexemplet. Men av någon anledning uppstod detta förskjutningsfel i IE5/Mac och bara där.

Efter mycket letande, och framförallt läsande, på nätet hittade jag till slut vad jag råkat ut för: Incorrect inheritance of positioning information to children of relatively positioned elements. Denna något torra, men korrekta, definition betyder i klartext att element ärver positionsegenskaper som inte ska ärvas. Testa den här sidan i IE5/Mac för att se ett exempel. (Jag borde förstås ha tagit en skärmdump om jag varit lite mera ambitiös, men jag vill helst slippa lägga mer tid på detta.)

Jag hade position: relative och left: 148px på det element som omsluter hela min huvudspalt, den jag kallar löpet. Buggen i IE5/Mac innebär att de element som befinner sig inuti löpet felaktigt ärvde denna positionsinformation. Därmed förskjöts de 148 pixlar åt höger för varje nytt element (nästan varje – det skedde inte riktigt alltid). Även om jag uttryckligen satte dessa element till position: static.

Lösningen blev att ta bort position: relative och left: 148px och istället använda margin-left: 148px. Det ser bra ut i IE5/Mac och förstås Firefox/Safari. Nu bävar jag för att kolla i IE6/Win igen, men jag hoppas det ska fungera.

Så mycket jobb för att anpassa sig till buggar i webbläsare, men en nyttig erfarenhet om jag ska kunna börja bygga standardbaserade webbsidor professionellt. Jag har dock fortfarande det värsta framför mig, nämligen att kolla hur det ser ut i IE5/Win. Jag är rätt säker på att det ser ännu värre ut där, eftersom IE5/Win har fått hela CSS:s box model om bakfoten.

Nåja, jag är en bit på vägen till en fungerande sajt i alla fall. Och jag har lärt mig en hel del.

Problem med designen i IE

Adrian Bengtson — Mon, 07 Jun 2004 21:15:43 +0000

Naturligtvis skulle min nya fina design för Aetles inte fungera i den mest hatade (av webdesigners) och samtidigt mest använda webbläsaren: Internet Explorer. Det ser riktigt illa ut, både i IE/win och IE5/mac. Nu måste jag lära mig alla fula … Continue reading →