Våra värsta år: IE Internet Exploder hasLayout hacks fixar

Internet Exploder Bugs
Postad: 08.02.2021 | CSS · HTML

Den här artikeln handlar om IE Internet Exploder hasLayout css-hacks bugg-fixar.

Även obsoleta (föråldrade) css-kombinationer är viktiga lärdomar om hur man förr löste css-problem med olika hacks. Vem vet, du som ännu inte riktigt hade påbörjat din karriär när man slet som värst kan komma att ha nytta av den här kunskapen idag. Historian skapar ju framtiden!

Alla utgående (externa) länkar i artikeln öppnas i nya fönster.

Det här är en lång artikel med stor igenkänningsfaktor för vissa

Front End Developer

Säg Internet Explorer och många av oss som minns suckar tungt. Nämn sedan IE 5.5, 6, 7 och vi kvider. Internet Explorer kom att bli ett skällsord, en webbläsare vi endast använde för att ladda ned andra bättre webbläsare med.

IE var webbens största bromskloss.

IE Webbens största bromskloss

Jag vill uppmärksamma Dig som läser att texten i den här artikeln varvas fortlöpande av flera intervjuer och mellansnack med fyra ”gamla rävar” som var med och slet sitt hår på den tiden.

Om du vill kan du redan här bekanta dig med dem via deras biografier: Robert Nyman, Åke Järvklo, Daniel Hansson och Joel Arvidsson, annars träffar du på dem i artikeln.


IE NetScape CSS-hacks fixar I slutet av 1990-talet och några år framöver så var det mellan IE och Netscape kriget om den bästa webbläsaren stod.

Netscape kallades Nätskräp av de som använde IE.
Internet Exploder svor alla andra som föredrog Netscape.

Internetmuseum har lagrat en artikel om just webbläsarkriget som kan vara spännande att läsa. Skrolla ned en bit. Artikeln finns på vänster sida om tidslinjen.

Elegant Themes skriver också om detta i sin blogg men tar även upp det andra webbläsarkriget som började i mitten av 2000-talet och höll på fram till ~2014. Kände du till det kriget?

De här kamperna inspirerade till att flera började illustrera “Battle of the Browsers” Artworks, ett krig som sedermera utökades med fler webbläsare vilka slogs om herraväldet.

Daniel om de tidiga webbläsarna

Daniel Hansson Det största problemet var det stora browserkriget när alla tillverkare körde sitt eget race och webbläsarna oftast kom på en CD från en datortidning, eller hade blivit hemskickad i brevlådan.

Olika versioner, Rendering, javascriptmotor, stöd för standarder – allt skilde sig mellan läsarna.

Mosaic dog av snabbt, Internet Explorer kom plötsligt förinstallerat och tog därmed över som standard, trots att det var en sämre läsare än Netscape eller Opera. Många internetleverantörer hade också sina egna brandade webbläsare som AOL, CompuServe, MSN, etc. Sedan dök Safari också upp och mac-versioner av alla ovanstående.

Tracie Masek skriver i sin artikel A brief history of the original browsers and the First Browser War hur allt egentligen började. Först att Tim Berners-Lee var den som den 12 mars 1989 kom på idén om en World Wide Web. Sedan att den första webbläsaren hette just WorldWideWeb men att den snabbt bytte namn till Nexus. 1993 släpptes Mosaic vilken var den första webbläsaren som visade bilder på samma sida som texten.

Vi får följa Tracies tidslinje med olika spännande nedslag i webbens historia. Vill du hellre kort kika på nedslagen så gör ett besök hos The History of Web och deras tidslinje.

Åke minns webbläsarkriget

Åke Järvlo De starkaste minnena var kanske just det här eviga böljandet av åsikter fram och tillbaka kring vilken webbläsare som var ”bäst” och all energi vi som branch lade på att polarisera mellan olika fabrikat ”best viewed in X” och allt det där.

Som webbstandardsafficionado kände jag att det nog egentligen kanske inte spelade så stor roll. Man lärde sig hur man skulle undvika att använda just den CSS-snutten som fick en viss webbläsare att få Windows att ”blåskärmskrasha” för folk som surfade in på sidan. Man lärde sig skillnaderna mellan MSIE och Netscape helt enkelt och på den vägen är det…

Även om de ofta används omväxlande, är tekniskt sett Internet och World Wide Web två olika saker. WWW aka ”webben” är en samling information (programvara) som nås via Internet, vilket är infrastrukturen (hårdvara)

Robert om webbläsarkompatibilitet

Robert Nyman Det finns några saker som sticker ut mer. 1998 lärde jag mig HTML och CSS och byggde min första webbplats.

Testade bara i IE4 och allt såg toppen ut. Tog för givet att det skulle se likadant ut mellan webbläsare. Testade några månader sedan i Netscape 4 och allt såg fruktansvärt ut…

Det var den första smällen med buggar/brist på kompatibilitet. Sedan, i början av min karriär, så handlade det mycket om vad som då kallades DHTML* och där var browser sniffing en naturlig del med att anpassa saker efter IE4 och Netscape 4, där IE använde absolut positionerade divar och Netscape hade ett eget layer-element.

[Artikelförfattarens tillägg] * DHTML = Dynamisk HTML

Mozilla Firefox webbläsaren som klarade rendera web standards Ironiskt nog skulle det framöver visa sig att många som använde och vurmade för IE valde att gå över till Mozilla Firefox när den webbläsaren etablerades. En webbläsare som delvis är byggd på just – Netscape.

Troligtvis berodde detta på att Mozilla Firefox var skapad att rendera web standards, något Internet Explorer inte alls klarade av att göra. Idén om att skapa en global web standard på webben började nämligen vid den här tiden att växa, vilket jag 2004 skrev om i artikeln Webbstandard: framtidens gemensamma språk?

Webbläsarna var med andra ord tvungna att följa med strömmen för att överleva.

Vilken webbläsare arbetade du helst med då/nu?

Åke Järvklo

Åke Järvlo Haha – i begynnelsen (runt sekelskiftet, när jag först hittade webben) var det faktiskt helst MSIE.

Som jag minns det var Microsoft väldigt tidigt framme med CSS-stöd, och under hela ”browser-wars”-eran upptäckte jag snart att oavsett vilken webbläsare som var ”bäst” för stunden – så kunde jag spara tid genom att först få de webbar jag utvecklade att funka i IE – och sedan ”lägga på ” ytterligare ”finesser” i andra webbläsare (om det krävdes) – jag började tidigt uppskatta progressive enhancement (kanske mycket för att jag också började intressera mig för webbtillgänglighet redan under det sena 90-talet)


Joel Arvidsson

Joel Arvidsson Jag har alltid varit macanvändare vilket var relativt udda i utvecklarkretsar på den tiden när allt i Sverige handlade om Microsoft.

För att undvika att styckas upp av anti-trustlagar i USA behövde Microsoft ett livskraftigt Apple, så de lanserade bland annat Internet Explorer 5 för Mac.

Det tog emot lite att använda IE, men det var helt klart den bästa webbläsaren då – även om det inte fanns så mycket konkurrens. Problemet var dock att den inte hade något gemensamt med Windowsvarianten förutom namnet – den hade en annan renderingmotor och hade bättre stöd för W3C-standarder.


Robert Nyman

Robert Nyman Någonstans kring år 2000 kom också Internet Explorer 5 för Mac, vilket var en stor nyhet och den hade på den tiden också en väldigt bra anpassning efter rådande webbstandarder.

Däremot hade nästan ingen Macar som arbetsverktyg, alla utom designers hade PC, oavsett om de jobbade med Microsoft- eller Java-miljöer. Jag flörtade lite fram och tillbaka med att ha en Mac, men dels var det saker som var annorlunda, dels var det svårt att få det att fungera på arbetsplatser där alla jobbade med Microsofts .NET-plattform. Några år senare, jag tror det var 2007, så vågade jag ta det slutgiltiga steget till att jobba på Mac, och har gjort det sedan dess.

Det intressanta att se nu på Google är att de flesta har Mac eller använder Linux eller Chromebooks – antalet datorer med Windows omkring mig är väldigt få.


Daniel Hansson

Daniel Hansson Favorit webbläsare då: Netscape Navigator
Favorit webbläsare nu: Chrome

IE buggar loss

Jag kommer lyfta fram några buggar man tyckte var överj*vliga. Om det fanns fler? Oh ja. Det var en tid när man utgick från hur många buggar man var tvungen att dräpa just den dagen.

Samtidigt kan jag på något vis idag känna att jag inte vill vara den tiden förutan. Trots all frustration, tårar av ilska och svettiga utbrott, så lärde jag mig massor. Och även om jag stundtals kände mig så usel att jag bara ville skicka datorf*n genom fönstret så visste jag ju att jag inte var ensam om att känna så.

Det blev på något vis en folkrörelse, en sorts stark gemenskap som enade människor på internet. A None IE-Club. Jag är så otroligt tacksam över att få ha upplevt den tiden, men aldrig att jag önskar mig tillbaka. Inte chans!

OK, åter till bugg-länkarna. Väljer du att gå till respektive bugg direkt så kommer du att missa intervjuerna och mellansnacket. Det vore ju synd, eller hur?

Obs! Flera av de kommande texterna är autentiskt utformande och hänvisar till samtidens kodning, på så vis de kunde ta sina uttryck på den tiden. Många av dem är dessutom lösta efter stor frustration.
Var du en av dem? Kommentera gärna!

Centrera ett element i IE6
Box Model-Hack versus Box-Sizing
IE6 Ghost Text Bug
:first-child CSS bug in IE 7
Double Margin Bug Fix
Conditional Comments
Min-Height for IE
position:relative och overflow i Internet Explorer
Zoom
Peek-a-boo Bug
IE8 noscript-ghost bug
Explorer Z-index bug
IE/WIN Guillotine Bug
Slutord
Dåtidens populära bloggrulle
Källor och referenser
Dåtidens CSS BUGGAR FIXAR & AVANCERADE TUTAR


Åke om buggarna

Åke Järvlo Jag försöker istället (mer eller mindre desperat ibland skall väl medges – men ändå) att komma ihåg det *bra* jag lärde mig med åren och då kanske också hellre tänka på alla de kollegor jag lyckats hjälpa att undvika i alla fall en del smärta och frustration genom att föra typ den där insikten vidare mellan projekt jag varit inblandad i istället.

Jag upplever att webben har utvecklats *enormt* mycket till det bättre bara de senaste två-tre åren och att *så* mycket av det vi kämpade med förr, typ ”bara fungerar” numera.
To infinity and beyond!” :D

Men först en ”Crash Course”: IE hasLayout

Alltså, kan det verkligen vara sant att IE hade alla dessa buggar? Är det ens möjligt? Jag tvivlar. Var det inte olika varianter på en och samma bug eller tema? Kanske fanns det bara en eller två buggar – inte tiotals eller flera hundra! För att besvara dessa frågor börjar vi med en återblick på IE hasLayout från och med IE5.5.

Internet Explorer har liksom alla webbläsare något som kallas för en renderingsmotor. Det är en intern komponent vilken formaterar informationen hos en webbsidas märkspråk och CSS som den sedan visar upp på datorskärmen.

Den primära uppgiften för en renderingsmotor är att analysera (parsa) HTML. Som standard visar den HTML, XML och bilder och stöder andra datatyper via plugin eller tillägg

Egenskapen hasLayout introducerades bara i IE5.5 innan IE klassificerade vissa CSS-egenskaper som ”layout-egenskaper”. Sedermera skulle det visa sig att hasLayout följde med IE till nyare versioner.

En hasLayout-fix innebär inget annat än att man deklarerar en CSS-egenskap som gör att ett element får en ”layout” när det vanligtvis inte har en layout som standard.

När vi hör ordet layout så tänker vi automatiskt på hela färdiga webbsidor! Så icke i detta fall. Själva ordet Layout bör här mer liknas vid en uppställning och/eller sammansättning av ett element än en full komposition/design.

Varför framkommer senare i texten.

IE Exploder Bugg hasLayout Bildkälla: https://i.kym-cdn.com/photos/images/newsfeed/000/215/821/1323635452001.png

Det enklaste sättet för ett element att få en layout är att det har en CSS-egenskap applicerad. Punkt!

Beter sig din webbsida konstigt i IE, försök då med att ställa in en CSS-egenskap på ett element, exempelvis bredd eller höjd så att den får en layout.

Kanske problemet försvinner?

I Internet Explorer är ett element antingen ansvarigt för storlek och ordning av sitt eget innehåll, eller så förlitar den sig på ett överordnat element för att dimensionera och ordna innehållet.

Vad den här egenskapen hasLayout faktiskt åstadkommer är att avgöra (IE:s renderingsmotor) om ett enskilt element har layout eller inte.

Robert om IE hasLayout och buggar

Robert Nyman Nästa stora utmaning några år senare, efter IE4 och Netscape 4, var med IE6. När den kom var den en fantastisk webbläsare med massor av kraftfulla features, men också sina buggar. Den blev den helt dominanta webbläsaren och Microsoft slutade utveckla den. Så vad som först var en bra webbläsare blev över åren en webbläsare som var mer och mer efter, och den hade ett väldigt stort problem som blev identifierat som hasLayout.

När folk väl hittade att det här var orsaken till massor av problem så blev det massor av hack för att trigga hasLayout i IE, såsom den helt oväntade zoom-propertyn eller height: 1%. Det var dock gott om konstiga CSS-buggar i IE! :-)

Och även om det finns, och har funnits många utmaningar, skulle jag ändå vilja våga påstå att webbplatformen och skillnader mellan webbläsare – eller superallvarliga buggar – inte alls är lika mycket av ett problem nu som då. Även om de förstås existerar.

Ett ”layoutelement” kan vara ett element som har layout som standard, eller ett element som får layout genom att ställa in vissa CSS-egenskaper.

Internet Explorer had to deal with very old legacy code from before CSS was really in full swing. As an architectural decision to make the browser easy to add CSS on to it, the hasLayout flag was used to trigger certain CSS properties so the page would be rendered correctly. This dates back to around the time of IE4.

Så det var därför det påverkade vår CSS på skärmen?

Precis, när det hämtar ett värde som anger OM objektet har en layout, så gör den det utifrån att egenskapen hasLayout är boolesk, det vill säga i termer ”antingen eller”.

Den får således bara ett av följande värden.

False: Standard. Objektet har ingen layout.
True: Objekt har layout.

De flesta IE-displayfel kan korrigeras genom att man ger elementet ett hasLayout-attribut.

Som tidigare nämnt kan du följaktligen aktivera elementets hasLayout med bland annat CSS-egenskaperna bredd/höjd så att den ”äger layouten”.

Därtill genom att ange följande CSS-egenskaper.

* Display: inline-block
* Höjd: (valfritt värde utom Auto)
* Flyta: (vänster eller höger)
* Position: absolut
* Bredd: (valfritt värde utom Auto)
* SKRIVLÄGE: TB-RL
* Zoom: (valfritt värde utom normalt)

Varje control, iframe, image, marquee, horisontell linje och tabell har sin egen layout. Att ha layout betyder internt att ett element är ansvarig för att ”rita” sitt eget innehåll.

Objektmodellen i Internet Explorer bör ses som en hybrid av en dokumentmodell och deras egen traditionella applikationsmodell.

I Internet Explorer 5.5 innebar ”ha layout” i grunden att ett element var rektangulärt. Om ett layoutelement dessutom hade ett innehåll så förutbestämdes layouten utifrån innehållet av dess avgränsande rektangel.

Man kan till och med göra så att alla element har layout genom att ange en bredd eller höjd, positionera dem eller göra innehållet redigerbart.

Site Point har en bra artikel om hasLayout och IE om du vill läsa mer om det.


Joel Arvidsson

Joel ArvidssonJag heter Joel Arvidsson och jobbar som Principal Engineer på Klarna. Jag började mina första stapplande steg med webbutveckling med att skriva av kodexempel från Internetworld i andra halvan av nittiotalet när jag gick i mellanstadiet och kodat professionellt i runt 15 år nu.

Som utvecklare gjorde det att det alltid såg annorlunda ut på Windows när man försökte göra något spännande med CSS. Efter ett tag lärde man sig dock alla buggar, hur man kunde koda defensivt mot dem men även utnyttja dem för att uppnå vad man ville.

Mitt minne av den tiden är framförallt hur väldigt många svenska utvecklare och biblioteken de använde genererade undermålig kod vars syntaxfel bara IE på Windows tolkade på det sättet de förväntade sig. Att använda banktjänster på mac gick oftast inte.

På internet fanns det då en stark rörelse för webbstandarder, semantisk HTML och tillgänglighet – bland svenskar så lärde jag mig massor från de på den tiden populära bloggarna av Roger Johansson och Robert Nyman. Jag har en känsla av att i takt med att bygga gränssnitt blivit allt mer ingenjörsinriktat så har vi börjat tappa de bitarna.

Tycker du att alla buggproblem då har vidgat ditt kunnande idag för att snabbare upptäcka felaktigheter öht och om du därigenom blivit en bättre problemlösare?

Även kunskapen om voodookonsten för hur man arbetar runt renderingsbuggar i gamla browsers är värdelös idag, så har det gett mig insikt i hur en browser/layoutmotor fungerar som forfarande är högst relevant. Många hatar buggar, men jag tycker det är roligt att grotta ner mig och är för mig fortfarande det absolut bästa sättet att lära mig hur ett system fungerar.

Här hittar du Joel:

Twitter: https://twitter.com/trastknast
Webbsida: https://oblador.se/
GitHub: https://oblador.github.io/

#Centrera ett element i IE6

Säg den webbutvecklare som aldrig någon gång försökte sig på att centrera ett element i IE6. Enklast var då att bara lägga till margin: auto;

Koden härunder centrerar ett element oberoende upplösning/webbläsarbredd. Fast IE6 i quirks-mode hanterade naturligtvis detta på just sitt speciella Internet Exploder-vis: inte alls.

Vi hade denna kod:

#container{
    border: solid 1px #ccc;
    background: #999;
    width: 400px;
    height: 160px;
    margin: 30px 0 0 30px;
}
 
#element{
    background: #f1f4ad;
    border: solid 1px #fff;
    width: 300px;
    height: 100px;
    margin: 30px auto;
     
}

…och vi ville ha detta:

IE Centering Right Way

Fast det här är vad vi istället fick av IE. Jättekul! *ironisk*

IE Center Fail

Främst berodde det på att IE6 i quirks-mode och lägre versioner inte kände igen marginalvärdet auto.

Fixen då?

Det mest pålitliga sättet på den tiden att centrera innehållet för IE6 och lägre versioner var att tillämpa text-align: center; på det överordnade elementet (#container) och sedan tillämpa text-align: left; på elementet som skulle centreras för att se till att texten inuti blev rättjusterad.

Jo du läste rätt. Positionen på elementet var tvunget att anges utifrån hur en text skulle positioneras med värdet left eller right. Skumt, eller?

#container{
    border: solid 1px #ccc;
    background: #999;
    width: 400px;
    height: 160px;
    margin: 30px 0 0 30px;
    text-align: center;
}
 
#element{
    background: #f1f4ad;
    border: solid 1px #fff;
    width: 300px;
    height: 100px;
    margin: 30px 0;
    text-align: left;   
}

CSS Centering – fun for all! – á la Russ Weakly

Centrering av flytande layouter
Flytande layouter är enkla att centrera med hjälp av marginaler på vardera sidan om boxen. Marginalerna kan ställas in med em, pixel eller procentenheter.

.container
{
	margin-left: 10%;
	margin-right: 10%;
}

Centering fixed-width layouter
Teoretiskt sett bör du kunna använda automatiska marginaler till vänster och höger om det innehållande blocket och det ska vara centrerat på sidan.

W3C: s visuella formateringsmodell säger:

Om både ’marginal-vänster’ och ’marginal-höger’ är satt på auto är deras användarvärden lika. Detta centrerar elementet horisontellt med avseende på kanterna på det innehållande blocket.

Så, ett block inuti bör kunna centreras med följande regler:

.container
{
	margin-left: auto;
	margin-right: auto;
	width: 50em;
}

Men det fanns givetvis problem

Vissa webbläsare centrerade inte blocken som innehöll den här metoden eftersom de ignorerade de automatiska marginalerna.

  • NN4 (Mac och Win)
  • Win/IE4
  • Win/IE5
  • Win/IE5.5
  • Win/IE6 (i quirks-mode)

Genom att lägga till två enkla regler kunde detta problem övervinnas i alla webbläsare som nämns ovan, exklusive NN4 (NN4 = Netscape Navigator 4.x).

1. Centrera body
Medan dessa webbläsare ignorerar automatiska marginaler som margin:auto; följer de i alla fall ”text-align: center”. Om detta tillämpas på body centreras det innehållande blocket korrekt.

Så en ny regel läggs till:

body
{
	text-align: center;
}

.container
{
	margin-left: auto;
	margin-right: auto;
	width: 50em;
}

2. Återställ textjustering
Det enda problemet med den här nya regeln är att allt innehåll på sidan nu är mittjusterat. text-align: center;

För att övervinna problemet med detta läggs en ny deklaration till för blocket .container inuti – ”text-align: left”.

Den slutliga CSS-koden är denna:

body
{
	text-align: center;
}

.container
{
	margin-left: auto;
	margin-right: auto;
	width: 50em;
	text-align: left;
}

Källa: Återgett från http://maxdesign.com.au/articles/center/ den 8 November, 2003

#Box model-hack versus Box-sizing

Lillan om boxmodellen

Lillan CCC3 Att IE6 stundtals gav oss gråa hår var definitivt inte överdrivet.

I synnerhet boxmodellen, som inte blev implementerad på rätt vis utan css-hack, var otroligt frustrerande. Det omfattade även positioneringen av dessa boxar. *suckar* Det var nära att jag skickade ut datorn genom fönstret, inte bara en gång om jag säger så.

Jag publicerade artikeln Boxmodelhack star-HTML 2006 i Pellesoft Tech Forum och 2004 här på kaxigt.com.

Boxmodelhack star-HTML starfloatcommando

IE (IE5/Windows IE5.5/Windows IE6/Windows) har problem med att hantera padding och border för att den lägger värdet inuti boxen istället för att läsa av boxens bredd och sedan lägga till värdena.

Låt oss kika på detta fenomen!

div box1{
width: 200px;
padding: 10px;
border: #fff 10px solid;
}

Först skapade vi oss en box på 200px bredd. Till denna box knöt vi en padding på 10px samt en border på 10px.

Vad som händer är att enligt IE är boxen fortfarande 200px bred men att innehållet i denna box har minskat med 40 pixlar varför det endast återstår 160pixlar att arbeta med.

Valida webbläsare läser istället av värdet så här:
200px (boxens bredd) + 10px + 10px (paddingen 10px gånger 2 = 20px) + 10px + 10px (bordern 10px gånger 2 = 20px) = 240px bredd.

IE:s tolkning

Som du säkert upptäckte så ”bakar” IE in dessa värden i det ursprungliga värdet 200px medan FireFox och andra webbläsare ”plussar” på det värdet som ett tillägg till det ursprungliga, utanför boxen.

Konsekvensen blir givetvis att om du inte använder dig av ett hack så kommer dina boxar att uppträda som de själva vill beroende på om det är IE eller någon annan webbläsare som läser av din css.

Och det vill vi ju inte – eller hur!

Selektorer

Ett sätt att komma undan detta problem är att skapa två stycken selektorer där den ena skapar boxens värde för IE medan den andra ger information om boxen till de andra webbläsarna.

div box1{
width: 200px;
}
div box1{
\width: 240px;
w\idth: 200px;
}

Vad säger då detta oss?

Granskar vi den översta nya selektoren så har vi bara angett vårt värde width:200px. Denna selektor riktar sig därför till de webbläsare som klarar av att rendera koden på ett riktigt sätt. Typ Mozilla, Firefox, Opera osv.

Selektor nummer två med värdet \width:240px; är till för att Opera eller andra valida webbläsare inte ska komma i konflikt med värdet 240px eftersom dessa webbläsare redan från början tolkar padding och border som ett tillägg utanför det ursprungliga värdet.

Bakåtslashen

På ett enkelt sätt kan man alltså säga att slashen är ett redskap för att få dessa webbläsare att ignorera värdet i denna selektor. Värdet riktar sig nämligen till IE 5 och 6 i quirks mode.

Värdet w\idth: 200px; vänder sig slutligen till de webbläsare som inte hamnar i konflikt med slashen samt IE 6.0 i ett non-quirks mode. Värdet återställs i denna kod till sitt rätta värde, 200px.

Men – det finns fortfarande en webbläsare som inte klarar av att läsa in hack med slashen utan crashar på grund av detta. Netscape 4.0.

StarHTMLHack by Tantek

För att tillgodose en rendering för IE ska vi använda oss av något som kallas för Tanteks starHTMLhack.

Tanteks starHTMLhack utgår från IE:s (5 och 6 quirks mode) oförmåga att rendera koderna på ett rätt sätt eftersom denna webbläsare inte verkar för att HTML-taggen är rotelementet i ett dokument.

Genom att då använda ett starfloatcommando kan man lura IE att läsa in din css på ett korrekt sätt utan att de andra webbläsarna påverkas. Vi ska här kika på ett exempel och vi börjar med vår ursprungliga kod.

div box1{
width: 200px;
padding: 10px;
border: #fff 10px solid;
}

Ett starfloatcommando kan användas olika.

Ibland kanske man vill ge ett globalt värde i dokumentet så samtliga webbläsare ska tolka koderna som man vill. Då infogar man starfloat + värdet man vill ha högst upp i cssdokumentet, för att sedan mer ingående för varje div definiera respektive värde.

Star-HTML

Här ska vi infoga den lilla stjärnan tillsammans med attributet html och således tvinga IE att läsa in koden från roten. Minns också vad jag skrev ovan – IE tror inte att html utgår från roten i ett dokument. Men det gör det ju.

Lägger vi då till stjärnan i css-koden så talar den om för webbläsaren att den ska utgå ifrån roten.

För att ytterligare undaröja missförstånd så lägger vi till attributet html.

* html div box1 {
width: 240px;
w\idth: 200px;
}

Granskar vi sedan själva koden så känner vi igen dem – width: 240px; och w\idth: 200px;. I detta fall riktar vi oss direkt till Internet Explorer varför märkningen av värdet innebär detta:

width: 240px; omfattar IE5 och IE6 i quirks mode
w\idth: 200px; är till för IE6 i standard mode

Utifrån den ursprungliga css-koden hade vi också kunnat skriva om koden så här enligt Tanteks hack:

div.box1 { width:240px;
voice-family: "\"}\"";
voice-family:inherit;
width:200px; }
html>body .box1 {
width:200px; }

Starfloatcommando

Detta första starfloathack inkluderar både border och padding. Vi ser det i värdet width:240px; kontra width:200px;. Det andra html-hacket måste omedelbart följa det första och är ett hack så att Opera kan tolka slasharna utan att crasha.

Tantek kallar det för ”Be nice to Opera 5 rule” och eftersom Opera är en valid webbläsare anger vi vidden 200px.

Med andra ord har du angett värdet width:200px för alla valida webbläsare, sedan styr du in andra webbläsare som Opera att ignorera slasharna för att till sist tvinga IE att läsa av koden på rätt sätt.

Idag kan vi göra så här och använda box-sizing

För enkelhetens skull använder jag samma CSS som i länken ”Centrera ett element i IE6”.

#container{
    box-sizing: border-box;
    border: 1px solid #000;
    background: #999;
    width: 400px;
    height: 160px;
    padding:30px 0;
}
 
#element{
    background: #f1f4ad;
    border:1px solid #000;
    width: 300px;
    height: 100px;
    margin:0 auto;
    padding:10px;  
}
Här är elementet centrerat. Jag använder dessutom box-sizing.
The box-sizing property is used to alter the default CSS box model used to calculate width and height of the elements. It is possible to use this property to emulate the behavior of browsers that do not correctly support the CSS box model specification.

Jeffrey Way på code.tutsplus.com hade funderingar flera år senare om det faktisk inte var så att IE trots allt tolkade koderna rätt i box-model mode och att det kanske istället var webbutvecklarna som påtvingade webbläsaren att göra som de ville.

IE6 var inte gjord att kunna det och vi kan se resultatet när vi applicerar box-sizing på ett element som jämförelse.

Om vi då ska ta till oss Jeffrey’s frågeställning så självklart måste vi svara JA på den. IE tolkade koderna rätt just för att den webbläsaren inte visste om någonting annat sätt.

Kärnfrågan, som jag ser det, handlade mer om IE:s oförmåga att följa utvecklingen med de nya krav som ställdes.

Samtidigt behövs det nog mer än en gång påpekas att utvecklingen av CSS handlade just om att ”hacka” sig fram till nya egenskaper som därefter kunde skrivas om och implementeras av webbläsarnas renderingsmotorer.

Det fanns ju ingen box-sizing på den tiden, så vad dåtidens utvecklare gjorde var att ”skapa” en form av ”box-sizing” med den tidens css-hack. Det är tack vare dem och deras hårda arbete vi slipper det idag.

I backspegeln är det dock en intressant fråga Jeffrey för fram, och det är alltid lätt att vara efterklok.

Box-sizing

Initial Value: content-box

/* Keyword values */
box-sizing: content-box;
box-sizing: border-box;

/* Global values */
box-sizing: inherit;
box-sizing: initial;
box-sizing: unset;

box-sizing MDN Web Docs

Lillan Backa

Lillan CCC24 Jag är en Senior Front End Designer och har varit på webben sedan 1996/97. I början använde jag IE men bytte sedan till Mozilla som jag har varit trogen sedan dess. Den första aha-upplevelsen varför standards var viktigt kom när jag började använda just Mozilla och upptäckte hur våra webbsidor betedde sig på skärmen.

I början på 2000-talet påbörjade jag därför ett arbete med att synliggöra Web Standards som var förvånansvärt okänt, och för många ointressant, här i Sverige.

Ett buggminne jag svor mig svetting på var boxmodellen. Att bygga ett box-element är en sak, att bygga en hel layout med flera block och få dessa att hålla ihop och passa i webbläsarna var en helt annan. Pixelprecision! Vi fick hacka både för Opera och IE5/mac vid sidan av IE5-6/ms.

Jag deltog i Carlstad Code Camp24h 2011. Ett 24-timmars ”hackaton” som arrangerades av Carl-Fredrik Herö och Gustaf Karlsson och gick av stapeln på Karlstad Universitet. Det var urhäftigt, men aldrig mer för en gammal kärring som jag ;)

Jag minns även hur vi på webbforumen (dåtidens sociala media) diskuterade om framtida CSS skulle överta flera av photoshops funktioner så vi skulle kunna designa en webbsajt enbart med olika css-egenskaper.
❤ Nu är vi där!


#IE6 Ghost Text Bug

Ett annat underligt problem som ibland uppstod längst ner på skärmen var det vi kallade för IE ghost text bug – texten upprepade sig!!!

Ghost Text Bugg IE 6
Bildkälla:https://lh5.ggpht.com/_nY9q6c1Jf_A/Sl4JVyPHHYI/AAAAAAAAAN0/MCrTXS6kPq4/s1600/ghostTextBug%5B3%5D.jpg

I ovan exempel upprepas orden ”been adjusted accordingly” två gånger.

Kommentarer och <DIV> -taggar

Det här var ett vanligt problem med IE6. Och det hade att göra med att man skrev kommentarer mellan flytande <DIV>. Underligt nog var det bara den sista delen av texten som blev upprepad.

Kika på ordningen här under.

1: <!-- IE6 gillar alltså inte dessa kommentarer -->
2: <div class = "floating_div">
3: <... lite markering ...>
4: </div>
5: <!-- IE6 gillar definitivt inte dessa kommentarer -->

Hade du ett innehåll som omslöt elementet utanför border på innehållet i en div, dvs att det fyllde hela bredden, då triggade det texten att upprepas eftersom IE6 hade ett 3-pixlars buffert-utrymme på höger sida.

Tips på lösning:

a) använd <!-- [IF! IE]> taggar runt kommentarerna.
b) ta bort kommentarerna
c) lägg till en stil i föregående float {display: inline;}
d) använd –ve marginaler på lämpliga flytande (float) div.
e) lägg till extra &nbsp; (ca 10 stycken) till originaltexten (the hacky way)

Ok, du tog bort alla kommentarer från markeringen men problemet kvarstår. Vi fortsätter.

{display: none} eller dölj det specifika elementet

IE Knocks Out Nu tar du kanske bort display:none på alla <div> -taggar och ler glatt. Tyvärr. Ingen förändring.

*smärta*

Vi testar något annat – igen!

Vad sägs om att prova mellanslag mellan listkoderna
<ul> <li> eller <dl>?

Webbläsare ska i allmänhet inte bry sig om blanksteg, men IE6 har som vanligt helt andra idéer. Den här lösningen ska fungera bara om det är ovanstående taggar som orsakar problemet.

*håller tummarna*

*käftsmäll*

Haha. Glöm det!

*ridå*
Bildkälla: https://i.kym-cdn.com/photos/images/original/000/346/560/157.jpg

Några lösningar till slut

  1. LÖSNING: Placera kommentaren precis innan den avslutande DIV-taggen.
    <div id="mitt_element">
    <p>Här kommer lite innehåll</p>
    <!-- här under avslutar jag min div, då kan jag kommentera här -->
    </div>
  2. LÖSNING: Justera marginalen till ett negativt värde.
  3. LÖSNING: Använd display: inline
  4. LÖSNING: Conditional Comments.
    <!--[if !IE]>Här lägger jag in min kommentering...<![endif]-->

Så kom Internet Explorer 7 *dubbelsuck*

# :first-child CSS bug i IE 7

Historien fortgår.

En liknande eländig bugg hittades nu i IE 7 ända tills Robert Nyman lyckades identifiera den, en bugg han inte ens var orsak till. Nyckeln till problemet var nämligen att html-kommentaren föregick det första LI elementet!

Känns det igen? *återigen ironisk*

<ul>
    <!-- First item is special -->
    <li>item</li>
</ul>

Hur han löste buggen? Robert Nyman – How to solve :first-child CSS bug in IE 7 (min svenska översättning).

Robert Nyman

Robert Nyman Jag heter Robert och har varit aktiv inom IT-branschen sedan 1999, alltid med ett fokus på frontend-utveckling. Jag skulle kunna säga att jag har programmerat ända sedan dess men de senaste åren har det varit väldigt lite av det. Jag jobbar inom Developer Relations på Google sedan 6 år tillbaka, och innan dess var jag på Mozilla knappt 4 år som Technical Evangelist. Webbplatformen har alltid varit mitt stora intresseområde.

Mycket av det jag fokuserar på är att försöka hjälpa utvecklare att lättare kunna bygga bra saker på webben, och en stor del av det är att förså de problem och utmaningar de har och att sedan försöka förbättra webbplatformen. Detta har bland annat synts i stora rapporter och samarbeten tillsammans med Mozilla, Microsoft, W3C, Samsung m fl i MDN DNA (Developer Needs Assessment) 2019 och 2020 och en djupdykning med MDN Browser Compatibility Report 2020.

Under 2021 har vi ett stort samarbete mellan webbläsare för att försöka åtgärda de största compatibility-problemen och göra den delen mycket bättre och pålitligare för webbutvecklare. Jag har också varit med och startat Open Web Docs och är med och driver det, med syftet att försäkra oss om en långsiktig plan för dokumentation av webbplatformen på de facto resurser som MDN Web Docs, oberoende av en ensam webbläsare eller organisation.

Tycker du att alla buggproblem då har vidgat ditt kunnande idag för att snabbare upptäcka felaktigheter öht och om du därigenom blivit en bättre problemlösare?

Oj, bra fråga! Jag kände mig ganska bra på det för ett antal år sedan, när man var mitt i det. Man kände till de vanliga fallgroparna och hur man skulle ta sig förbi dem. Och om man inte förstod var det var så visste man vilken tråd man skulle börja dra i för att förstå mer. Nuförtiden handlar problemlösning mer om relationer mellan individer, i communitys och kring hur man kommunicerar. Det är en egen typ av problem, och jag vet inte om problemlösning inom programmering har hjälpt mig där. :-)

Det jag minns från många år sedan var att jag önskade att det fanns en Undo (Ctrl/Cmd + Z) i det riktiga livet. Man vande sig så mycket med att programmering handlade om trial and error, man provade lite och fungerade det inte så gjorde man Undo så det aldrig hänt, och provade på ett annat sätt.

Här hittar du Robert:

Webbsida: Robert’s talk – Web development and Internet
Twitter: https://twitter.com/robertnyman

IE7 och hasLayout

hasLayout IE7 IE7 var en förbättrad version av IE6 men som fortfarande bara komplicerade saker och ting genom att behöva olika hack för att uppnå samma gamla renderingseffekter.

Blev vi förvånande? Icke! Även om vi hoppades på motsatsen.

Det fanns 193 buggar i Internet Explorer 7 för Windows! Yepp!

Jag tänker dock inte lista dem alla utom några få.

Bildkälla: http://www.gtalbot.org/GRAPHICS/JPG/web-developer-affected-hasLayout.jpg

Vi går tillbaka till Internet Explodunder 6

#Dubbel-marginal Bug Fix

Dubbel Margin Bug

Den här buggen fanns redan i äldre versioner av IE. Men det gör den inte mindre eländig.

Om du hade ett flytande element med marginaler antingen till vänster eller till höger eller rent av på båda sidor så ökade IE6 marginalens värde till det dubbla.

Margin-left: 5px; dubblerades till 10px.

Man kunde lösa det genom att lägga till display: inline; till det flytande elementet. Fast egentligen var det ingen lösning att hurra för – vi kan ju inte ställa in statiska bredder på inline-element!

div#content {
float:left;
width:200px;
margin-left:10px;

/* fix för double margin error */
display:inline;
}

Bildkälla:https://cssdeck.com/blog/wp-content/uploads/2008/06/doublemargin-400.gif

Åke om progressive enhancement och conditional comments

Åke JärvloAtt använda progressive enhancement som grundprincip hjälpte. När Microsofts Mac-team införde möjligheten att styra ”mode” i IE5/Mac (de var först med att ge oss möjlighet att hantera en webbsida ”mer standardiserat” om man använde en ”korrekt doctype”, och ”bakåtkompatibelt” med i princip alla kända gamla CSS-buggar i full sving annars).

Microsoft hade också ett tag något de kallade ”conditional comments” – som gav möjlighet att rikta olika CSS mot olika versioner av MSIE så att man kunde bygga en ”fungerande grund” (som funkade i typ ”alla” webbläsare som man kände till) – och sedan lägga på specialriktade stilar mode de ”nyare” versionerna av IE för att kunna utnyttja de framsteg de (som jag upplevde det) faktiskt gjorde.

Nåja – det var inte utan viss friktion och med tiden blev IE5/Mac ett bojsänke man gärna försökte förtränga (MS slutade utveckla den och det gjorde att den förföll rätt snabbt – men den levde alldeles för länge i mitt tycke).

#Conditional Comments och CSS-hacks

Alltså, det här blev vår räddning. Villkorliga kommentarer var ju inte heller främmande för IE. Kunde det äntligen vara slutet på en del överjä*liga CSS-hacks?

Dåtidens bästa CSS webbläsar-hacks

IE 6 och lägre
Använd * html {} för att välja html-elementet.
IE 7 och lägre
Använd *+html, * html {} för att välja html-elementet.
IE 7 endast
Använd *+html {} för att välja html-elementet.
IE 7 och endast moderna webbläsare
Använd html>body {} för att välja html-elementet.
Endast moderna webbläsare (inte IE 7)
Använd html>/**/body {} för att välja html-elementet.

Fast Conditional Comments var ju bra mycket bättre

Conditional comments har funnits sedan Internet Explorer 5, men deras användning är faktiskt inte begränsad till IE. De kan också användas för att anpassa ett innehåll att levereras till både högre- och lägre webbläsares versioner.

Just det gör det enkelt för webbutvecklare att skriva sidor som nedgraderar fint även i mindre kapabla webbläsare. Samtidigt är det enkelt att dra nytta av de förbättrade funktionerna och prestandan som erbjuds av Internet Explorer 5 och senare versioner.

HTML-kommentaren känns igen av praktiskt taget alla webbläsare. Med denna typ av kommentarer ignoreras allt innehåll i taggen helt av webbläsaren.

HTML som visas i syntaxblocket i var och en av de villkorliga kommentarerna betecknar alla block med HTML-innehåll, inklusive skript.

Lägg märke till versalerna i scriptet. Versaler var ”så viktiga” på den tiden och när jag läste programmering 1996/97 skulle vi absolut använda versaler i markupen.

<!--[if IE 5]>
<SCRIPT LANGUAGE="Javascript">
alert("Gratulerar. Du använder IE5 eller en nyare version!");
</SCRIPT>
<P>Tack för att du stänger denna box</P>
<![endif]-->

Båda typerna av conditional comments använder ett villkorligt uttryck vilket känns igen i Internet Explorer 5 och senare versioner. Om uttrycket är sant analyseras innehållet i kommentarblocket och renderas.

<!--[if gte IE 10]> Vill du tex att den ska rikta sig från IE 10 och uppåt anger du det märkningen gte <![endif]-->
<!--[if lt IE 9]>Vill du däremot att den ska rikta sig från IE 9 och nedåt anger du det märkningen lt <![endif]-->
<!--[if lte IE 7]>För likvärdig, eller lägre, IE 7 används märkningen lte <![endif]-->
<!--[if gt IE 6]>Sist har vi denna som riktar sig till IE som är större än IE 6. Märkningen för detta är gt <![endif]-->

gt betyder större än – greater than
lte betyder mindre än eller lika stor – less than (or) equal

Negativ conditional comment

<!--[if !condition]><![IGNORE[--><![IGNORE[]]> HTML <!--<![endif]-->

Läs mer om conditional comments istället för IE-hacks

Daniel Hansson

Daniel Hansson Jag heter Daniel Hansson, och har kodat och programmerat professionellt sedan 1998, och idag arbetar jag som business analyst.

Jag ramlade in i webben som grafisk formgivare i mitten på 90-talet. Det fanns inga egentliga utbildningar, så det var att lära sig själv och omsätta i praktiken som gällde. Några av mina tidigaste sidbyggen är för gamla för Wayback Machine.

Det största problemen vi hade var kompabilitet mellan webbläsare. När man byggde en sida (i tabeller – lol) så fick man konstant testa av så att sidorna och javascripten fungerade mellan de olika läsarna. Detta felsökande var återkommande tillsammans med skiftande skärmstorlekar, egna varianter på javascript, skiftande stöd för CSS, och anpassning till en begränsad bandbredd.

Vi lärde oss vad som idag kallas för holistiskt tänkande kring felsökning och lärde oss att förutse och sätta begränsningar på ambitionerna – bara för att något är möjligt, kanske det inte är en bra idé om det sabbar för andra.

Genom konstant sökande efter buggar och bygga workarounds i javascript och HTML lärde jag mig läsa kod som jag kunde applicera på PHP och ASP och senare .NET, likväl som javascript-frameworks.

Nu för tiden slipper man ju mycket av kompabilitetsproblemen tack vare frameworks, och att webbläsarna har börjat följa standarder vilket är en vägsignelse.

Tycker du att alla buggproblem då har vidgat ditt kunnande idag för att snabbare upptäcka felaktigheter öht och om du därigenom blivit en bättre problemlösare?

Problemlösningen från den tiden ledde mig senare in på UX/UI där det handlar om användarupplevelser, vilket i sin tur ledde till större problemlösning som verksamhetsanalyst där man tar ett ännu större grepp från ax till limpa på olika arbetssätt i en organisation, samt deras tekniska lösningar som kanske följer gamla arbetsmönster som bör göras om från grunden. Utan lärdomarna från nätets ungdom hade jag nog inte hamnat där jag är idag.

Här hittar du Daniel:

Linkedin: http://www.linkedin.com/in/danielhansson
Webbsida: www.neocreo.net

#Min-Height för IE

IE ignorerade egenskapen min-height, istället tolkade webbläsaren det deklarerade värdet som minsta höjd. Följande hack fixade det genom att lägga till !important-deklarationen. Tack till Dustin Diaz.

Fix nummer ett

selector {
  min-height:500px;
  height:auto !important;
  height:500px;
}

Fix nummer två

Det andra sättet var att dra nytta av det faktum att IE inte kunde parsa child selektorer.

#element {
    min-height: 150px; 
    height: 150px;
}
    
html>body #element { 
    height: auto;
}

#position:relative och overflow i Internet Explorer

Jonathan Snook förklarar hur han löste denna bugg som återfinns både i IE6 som i IE7 (fritt översatt).

Jag arbetade med en layout som hade element #b placerat position:relative med css-egenskapen overflow inuti #container. Allt såg bra ut tills jag bytte till IE7 och upptäckte att mitt positionerade element #b förblev fixed. Här är en kod för att demonstrera problemet:

<div id="container">
    <div id="a"></div>
    <div id="b"></div>
</div>

Och dess CSS.

#container {
height:100px;
border:1px solid blue;
overflow:auto;
}
#a {
height:200px;
background-color:lightblue;
float:left;
width:60px;
}
#b {
position:relative;
height:200px;
background-color:pink;
width:60x;
}

Lägg märke till att CSS är angiven overflow:auto för #container, och positioneringen i #b är satt till position:relative. Här är en skärmdump för att visa:

Overflow och Relative
Bildkälla: https://snook.ca/files/overflowrelative.gif

För att lösa det så lade jag till position:relative på #containern. Denna lösning tycks fungera på både IE6 och IE7.

Åke Järvklo

Åke Järvlo Åke Järvklo heter jag – började programmera på skolans ABC80-maskiner under första året på gymnasiet (1979 – vart tar tiden vägen :) ) Webben sprang jag på kring 1997 och det mesta jag gjort sedan dess har haft webbfokus.

Idag är jag konsult på Webstep i Stockholm och arbetar med att utveckla webblösningar för kunds räkning med .Net i botten och på/för Azure. Just nu sitter jag i ett uppdrag för en kund som bl.a. sysslar med e-handel i stor skala och utvecklar API:er – men innan det har det oftast blivit utvecklingsuppdrag som har med utveckling av olika typer av webbplatser att göra.

Jag brukar säga att jag är generalist med frontend-twist och den twisten består ofta av att jag har ett långvarigt fokus på webbstandarder och webbtillgänglighet i botten sedan nånstans före IT-bubblan.

tycker du att alla buggproblem då har vidgat ditt kunnande idag för att snabbare upptäcka felaktigheter öht och om du därigenom blivit en bättre problemlösare?

Absolut. Ingen tvekan om det!
Genom att jag tidigt anammade stora delar av standard-”stacken” så har jag definitivt utvecklat en sorts förmåga att tänka i flera lager samtidigt – och kanske också fått i mig någon sorts instinkt som gör att jag kan känna när jag ibland behöver ”kliva lite utanför lådan” och angripa ett knepigt webbproblem från lite olika håll när jag kört fast.

Här hittar du Åke:

Webbsida:jarvklo.se

#Zoom

Att använda position:relative i en design var ett bra sätt att provocera IE6. Moderna webbläsare visade relativt positionerade och nästade element utan problem.

IE6 lyckades ofta att j*klas, även med okomplicerade layouter. Genom trigga hasLayout med hjälp av att lägga till zoom: 1; i varje relativt placerat element så löstes problemet.

.selector {
  position: relative;
}
* html .selector {
  zoom: 1;
}

Användes zoom: 1; till inline element behandlade IE6 dem som blockelement.

#Peek-a-bo Bug i IE6

Peek-a-boo bug IE Peek-a-Boo, eller titt ut, är precis vad det låter. Till en början blev jag ganska rädd, jag menar, här hade man lagt ned tid på att få en sida som fungerade i IE och så försvann bilderna.

Det var inte utan att pulsen steg och jag kände svetten i nacken.

Vid en snabbtitt i koderna, i stilmallen, i sidkällan, så såg jag att bilderna var där dem skulle vara.

Det kunde fladdra till på skärmen och sen var en bild borta för att sekunden efter när jag skrollade runt plötsligt finnas på plats.

Vad i hela helskotta hände?

Jo, om en div ges en bakgrundsfärg och innehåller flytande objekt (flytande med hjälp av CSS-float eller HTML-align på bilder) så händer det saker med Internet Explorer man inte vill.

Ibland döljer Internet Explorer 6 delar eller hela huvudinnehållet i en div (exempel 2 och 5 saknar titlar – se länken Peek-a-boo).

Utöver det, i Internet Explorer 5 och 6, om containern ges position: relative; så försvinner de flytande objekten (exempel 4 – se länken Peek-a-boo) inuti denna.

Peek-a-boo
Hur det är tänkt att se ut

Bildkällor: https://dracos.co.uk/code/ie6-css-bug/ie6.png och https://dracos.co.uk/code/ie6-css-bug/firebird061.png

Att skrolla ned sidan förbi det saknade avsnittet för att därefter skrolla tillbaka upp igen ”tog bort” problemet, men det är inte en bra lösning. Risken fanns ju att det blev en massa skrollande för att ”fånga upp” det dolda avsnittet.

Bugg-fixar för Peek-a-boo

En lösning att komma runt problemet var att ge container div en line-height på ungefär 1.1-1.2.

Det andra var det välkända Holly-hacket.

Holly Hack - lägg till följande kod i CSS-filen:
/ * hide from IE5-mac * /
* html div #content {height: 1%;}
/ * End hide from IE5-mac * / / * - Holly Hack for IE 6 Peekaboo bug - * /

Holly-hacket fungerade dock inte på element med position:absolute;

#IE8 noscript-ghost bugg

Elementet <noscript>

Innehållet i ett <noscript> -element bör endast visas när det inte finns någon skriptstöd eller om skriptkörningen är avstängd.

I Internet Explorer 8:s standardvy kunde <noscript> -elementet uppträda mycket underligt, speciellt om du stylade det med en bakgrundsfärg eller en border.

IE8 noscript ghost

Det blev då väldigt tydligt att det inte fanns något skriptstöd hos webbläsaren och nedanstående information var inte ovanlig.

PLEASE ENABLE JAVASCRIPT TO ACTIVATE THIS PAGE

Taggen <noscript> hade sitt ursprung på den tiden då vissa webbläsare inte hade stöd för JavaScript.

Numera har taggen tappat mycket av sitt värde eftersom alla webbläsare har skriptstöd och endast ett mycket begränsat antal användare stänger av JavaScript i daglig praxis.

Med Internet Explorer 8 som sade sig stödja standarderna, och med dess skriptmotor aktiverad, visades ändå en konstigt bugg av <noscript>-elementet. Buggens utseende varierade beroende på värdet av dess displayegenskap.

Ändå anses <noscript> -taggen inte obsolet (föråldrad) utan vara värdefull i vissa begränsade situationer.

IE8 Noscript Ghost gone

Buggen

Även om Microsoft hade gjort stora förbättringar för version IE 8 var det fortfarande lång väg kvar innan IE kom ifatt Firefox, Safari och Opera för att nämna några av de andra (och i mina ögon bättre) webbläsarna. Internet Explorer var också känd för sina buggar, och tro för all del inte att vi slapp dem i IE 8, <no script> ghost bug blev ett nytt problem.
The ghost can vary in appearance depending on its display property value. If it’s made “block” it will always show in, but if it’s “inline” then the ghost will disappear when “compatibility mode” is enabled, probably because of the way IE7 handled inline elements in general.

Webbutvecklare över hela världen var så glada att IE8 äntligen skulle befria dem från bördan med att "fixa webbplatsen för IE", men det visade sig att Internet Explorer fortsatte att orsaka extra arbete.

Work Design Graph

#Explorer Z-index bugg

IE 6-9 (hasLayout) hanterade inte z-index korrekt. Nya positionerade element skapade nya staplingskontexter som började vid noll, så du kunde stöta på kontraintuitivt beteende. Inte minst var menyer med z-index positioner problematiska.
<div id="positioned-div" style="position: relative;">
     <div id="inner-div" style='z-index: 1000'>
          Hello world
     </div>
</div>
<img src="i_am_still_higher.png" style="position: relative;"/>

Även om "inner-diven" hade ett högt z-index, eftersom det är inne i den positionerade diven och bilden fanns i ett annat sammanhang och "följde" den positionerade diven i flödet, så kommer bilden alltid att täcka "inner-diven" om de två överlappar varandra. Den inre divens z-index relaterar endast till sin egen förälder och ingen annan.

Fixen var att tilldela ett högre z-index till den positionerade diven än bilden.

In Internet Explorer positioned elements generate a new stacking context, starting with a z-index value of 0. Therefore z-index doesn't work correctly.

Lösningen var att ge föräldraelementet ett högre z-index. Z-index:2 kommer alltid att vara högre än ett z-index:1000. Men om en positionerad div gavs ett z-index:3 så kom det att vara högre, liksom "inner-div" som ett av dess barn.

<div id="positioned-div" style="z-index: 1; position: relative;">
     <div id="inner-div" style='z-index: 1000'>
          Hello world
     </div>
</div>
<img src="i_am_still_higher.png" style="position: relative; z-index: 2"/>

#IE/WIN Guillotine Bug

IE6:s giljotinbugg kapade bokstavligt talat nedre delen av ett element om det var angivet egenskapen float och med hover-länk.

IE Guillotine Bug
Bildkälla: https://web.archive.org/web/20170624195104/http://www.positioniseverything.net/explorer/images/screenshot4.gif

Men vi hade ju vid det här laget lärt oss av erfarenheten att det alltid var något vi kunde förvänta oss av IE. Således, i IE kom containern att sträcka sig ner för att innesluta det float-elementet som har överskridit höjden på icke-flytande innehåll.

En länk som använder sig av egenskapen :hover triggar alltså denna guillotin-bug. När en sådan länk blir hovrad hoppar containerns nedre kant upp för att endast innesluta det icke-flytande innehållet.

Vilket är rätt sätt att arrangera elementen.

Men när containern minskar hamnar den del av boxen som anges float under det icke-flytande innehållet och och blir dold. Endast den del som visas ovanför containerns nedre kant förblir synlig.

IE/WIN Guillotine bug and fix
Bildkälla: https://web.archive.org/web/20200311064743im_/http://www.positioniseverything.net/explorer/images/demo1.gif

Buggen påminner om IE/Win Unscrollable Content Bug

Så kom IE7 med sin version av denna "förmodade åtgärdade bugg"

Nu när vi har kikat på giljotin-buggen, låt oss då undersöka vad vi har till hands för att på bästa sätt skapa en. Hehehe...

Så här gör vi en giljotin-bugg

  1. Ett containerelement
  2. Ett flytande element inuti containern som inte anges clear
  3. Länkar inuti en container i icke-flytande innehåll efter float
  4. a:hover för de länkar som ändrar vissa stil-egenskaper
  5. Internet Exploder

Det icke-flytande innehållet kan eller kanske inte kan omslutas i ett blockelement, såsom p eller div.

Reglerna för hur a:hover i "giljotinlänkarna" ska stylas kan vara allt som förändras, bland annat dessa.

  1. Background
  2. Padding
  3. Text style
  4. Border
<!-- Example Layout for a Guillotine Invoking Situation -->

<div id="container">
   <div id="floated">
      This is the floated content.
      It is vulnerable to the Guillotine.
   </div>

   This is the non floated content inside the container.
   Guillotine invoking links should be in this content.
</div>
/* Example Style Rules for a Guillotine Invoking Link */

a:hover {

	background: none #FFFFCC scroll repeat 0% 0%;

	/* and/or */

	padding: 5px;

	/* and/or */

	text-style: italic;

	/* and/or */

	border-bottom: #0000FF 1px solid;

}

Ett undantag är att ändra textfärgen, den triggar inte buggen.

Som du kan se är det ganska lätt att hamna i giljotin-fällan. Fast beväpnad med ovanstående kunskaper tar vi klivet till Guillotine bug in action.

Den ökänt berömda giljotinbuggen

Om en container hade en specificerad storlek kom IE automatiskt att omsluta alla flytande element inuti containern. Detta stred dock mot specifikationerna.

IE Giljontin Bugg

Hur det kunde se ut innan giljotinbuggen triggades.

IE Giljontin Bugg

Sedan hur det blev när buggen triggades av en hovrande länk.

IE Giljontin Bugg

Det kan tyckas som så att ifall vi inte specificerar storleken på containern då skulle det förhindra buggen eftersom float i första hand inte kommer att stängas automatiskt.

Men IE är IE, även när float inte är automatiskt innesluten så kommer länken att hugga av den nedre delen av float under vissa förhållanden.

För att buggen ska triggas igång i detta sammanhang bör float inte anges clear i något element på sidan. I denna variation av buggen kapas inte float av containern, utan av sig själv.

Lösningen då?

Tja, det som vi först lärde oss, inte den allra vackraste lösningen men som hjälpte flera liknande problem, var att "resetta" allt med clear:both fast i en ny tom div.

<div style="clear:both"></div>

Denna skulle läggas till utanför och under containern för att det skulle fungera.

<!-- Example Layout to Fix the Guillotine with Markup -->
<div id="container">
   <div id="floated">
      This is the floated content.
      It is vulnerable to the Guillotine.
   </div>

   This is the non floated content inside the container.
   Guillotine invoking links should be in this content.
</div>
<div style="clear: both"></div>

En bättre metod att "cleara" var via mark-up som gjordes genom att applicera clearing-diven inuti containern. Den skulle då läggas precis ovanför containerns avslutande tagg.

<!-- Example Layout to Fix the Guillotine with Markup -->

<div id="container">
   <div id="floated">
      This is the floated content.
      It is vulnerable to the Guillotine.
   </div>

   This is the non floated content inside the container.
   Guillotine invoking links should be in this content.
   <div style="clear: both"></div>
</div>

Men att använda strukturell mark-up utan semantik är inte särskilt tilltalande; det är trots allt anledningen till att denna clearingmetod introducerades.

Den förlitade sig på :after pseudo-class för standardkompatibla webbläsare (Mozilla & Co), och specificerade en höjd till containern för den ökända webbläsaren IE som inte stödde :after.

Okej, fast en container med en specifik storlek är ju exakt det som behövs för att trigga IE Guillotine, så denna "clearing-element-metod" kan inte ensamt lösa buggen.

Så kom Holly

Först, vi bör behålla det icke-flytande innehållet i ett blocknivåelement som ett p eller en div om det inte redan är det. Inslutning av text på det här sättet är ju semantiskt korrekt.

Sedan anger vi en höjd till detta blockelement med hjälp av Holly-hacket så att endast IE ser den angivna storleken.

Se och häpna, buggen försvann!

<!-- Example Layout with the Holly Hack applied -->

<div id="container">
   <div id="floated">
      This is the floated content.
      It is vulnerable to the Guillotine.
   </div>

   <p class="hollyhacked">
   This is the non floated content inside
    the container. Guillotine invoking links
    should be in this content.</p>
</div>
/* Example style rules for the above fix  */

#container {

    /* Set margins, padding, borders, colours etc. */

}


/* Contain the floats using the :after method */
#container:after {
	content: ".";
	display: block;
	height: 0;
	clear: both;
	visibility:hidden;
}

/*  \*/
* html #container {
	height: 1%;
}
/*  */

/* End float containing rules */


#floated {

    /* Set margins, padding, borders, colours etc. */

	float: left;   /* float the block */

}


/* Apply Holly Hack to the non-floated content */

/*  \*/
* html .hollyhacked {
	height: 1%;
}
/*  */

Det fanns ingen perfekt fix för Guillotine-buggen.

Genom att använda Holly-hacket för att ange en storlek till det icke-flytande innehållsblocket, samtidigt som man blir av med giljotinen, utlöses IE:s felaktiga float-modell plus webbläsarens egen uppsättning komplikationer.

Effekten av Guillotine märks dock bara när float är högre än det icke-flytande innehållet som följer den. Därför kommer det icke-flytande innehållet sällan att fortsätta under float i en sådan situation.

Det här gav oss en chans att säkert använda Holly-hacket utan att layouten blev förstörd.

Åke berättar...

Åke Järvlo Haha - ja det blev väl så att jag och IE blev lite ovänner när Microsoft kom på att de skulle börja använda hårdvaran i ens grafikkort/PC (på Windows) för att få bättre prestanda…

Det här hände mig:

Vi hade en kund som just uppgraderat stora delar av sin organisations PC-datorer… Jag skulle utveckla deras publika webbplats, och det var ganska hårda krav på det grafiska… När vi levererade webbplatsen upptäckte kunden att det var problem med webbsidan. Vid lite undersökning visade det sig snart att det var på *några* av de nya PC-burkarna som en viss funktion på en viss sida helt enkelt inte fungerade (men inte på alla). Vi kunde naturligtvis inte återskapa felet i våra utvecklarmaskiner (klassiker) - så vad göra.

Jo - jag fick tillåtelse att åka över till kunden och ställa upp två maskiner bredvid varandra för att se om jag eventuellt skulle kunna utlösa felet och då kanske se vad som gått snett… Sagt och gjort.

Samma versioner på allt (Windows, IE, etc. etc. etc) - Bägge burkarna var nya och upphandlade till samma specifikation… Men mycket riktigt. Det fungerade i den ena, men inte i den andra… Tiden gick. Kunden blev mer och mer otålig (såklart)…

Men…

Till slut kollade vi hårdvaran en extra gång också - och då slog det mig. Maskinerna hade olika grafikkort och det var det som var problemet (för en webbsida! - WTF???). Det jag hade råkat snubbla över var helt enkelt (0_o) en bugg i en windowsdrivrutin för det ena fabrikatet av grafikkort som användes, och det felet gjorde att MSIE inte kunde rendera just den CSS-sekvensen jag hade använt för att "pixeltweaka" designen…

Hur det gick? - tja, Microsoft hade en speciell metatagg på den här tiden som jag kunde lägga till för att instruera MSIE att "emulera" vissa funktioner i sin egen mjukvara istället för att använda grafikkortets (förmodligen snabbare) motsvarighet.

En <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> senare så var det problemet ur värden. Några svordomar, suckar och ett allmänt behov av att unna sig lite avkoppling följde såklart (det var ju inte bättre förr, bara annorlunda så sån't gjorde vi redan då) - men det var såhär i efterhand otroligt lärorikt att dra nytta av att man nånstans hade ett intresse av att verkligen försöka ha lite *koll* på hur en webbläsare fungerar internt för att kunna skriva bra webbkod som "funkar i allt". (ja - den metataggen blev en grundbult i allt jag gjorde efter det - till Microsoft tog bort den -men det är en annan historia :) )

Slutord

Tänk så skönt det hade varit om vi slapp alla former av buggar. Nu är det tyvärr inte så utan nya upptäcks även idag som kräver sina hacks. Jag läste ett inlägg på Stack Overflow för ett bra tag sedan om hasLayout problem på IE9 och IE10. IE10 och IE11 har dessutom problem med flex-box och bakåtkompatibilitet. Tänka sig. *ironisk*

If you are using the X-UA-Compatible META tag you want to place it as close to the top of the page's HEAD as possible. Internet Explorer begins interpreting markup using the latest version. When Internet Explorer encounters the X-UA-Compatible META tag it starts over using the designated version's engine. This is a performance hit because the browser must stop and restart analyzing the content.

How to enable compatibility view in Internet Explorer 11 (IE11)

Backwards Compatibility of Flexbox

Okej, vi som designade då?
Vi front-endare tvingades välja det alternativ som var den bästa för varje design och sedan jobba skägget av oss. Det kunde vara svårt att få klienten att förstå att det fanns vissa begränsningar mellan önskemålen och vad som de facto kunde implementeras. I synnerhet om kunden bara tyckte att det räckte med att deras webbläsare kunde rendera sidan. I många fall fick vi kompromissa ganska hårt.

Det var svårt och svettigt, men vad sjutton var inte svårt med IE?

Mitt speciella tack till...

Robert Nyman - en gammal vän sen många år tillbaka.
Åke Järvklo - en ännu äldre vän, förmodligen från stenåldern ;-)
Daniel Hanson - en ny bekantskap.
Joel Arvidsson - ytterligare en ny bekantskap.

...för att ni hade lust att ställa upp och dela era minnen i denna artikel. Jag vet att det kan ha givit er ruggiga mardrömmar ;-)

Och Du som nu har orkat läsa ända hit, vad roligt att Du gjorde det! Tusen Tack! Jag hoppas att du fick en stunds trevlig läsning som kanske gav dig minnen men också ett litet fniss här och var av igenkännande.

Kommentera gärna, kanske du hade en bugg som var din partner in crime? Eller inte? Låt oss dela våra erfarenheter för det fanns så många fler buggar än de jag tar upp i artikeln.


Dåtidens populära bloggrulle

Det fanns personer som stack ut lite mer, både vad det gäller den semantiska webben och web standards, som annan programmering. Jag namnlistar några av dem härunder och hur deras sajter såg ut då, tänker att det kan vara kul att se. De laddas in via web.archive.org.

Stjärnlänken * visar däremot att bloggen fortfarande finns online och leder till hur den ser ut i dag.

Källor till artikeln och mer att läsa


Layout Trigger Comparison
IE6 Ghost Text Bug
IE CSS bugs when using floats and background-color
https://i.kym-cdn.com/photos/images/original/000/346/560/157.jpg
CSS tests and experiments
How To Attack An IE/Win Bug
Fixing IE's Peekaboo Bug
bye-bye holly hack...
Explorer Exposed!
The IE8 noscript-ghost bug
Explorer z-index bug
9 Most Common IE Bugs and How to Fix Them
IE z-index bug and how to squash it …
IE Guillotine Bug
https://web.archive.org/web/20200311064743im_/http://www.positioniseverything.net/explorer/images/demo1.gif
position:relative and overflow in Internet Explorer
A brief history of the original browsers and the First Browser War
Double Margin Bug
10 Awful IE Bugs and Fixes

Dåtidens CSS BUGGAR FIXAR & AVANCERADE TUTAR

Dessa kommer att laddas in via Way Back Machine - Internet Archives så ha lite tålamod.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *

Denna webbplats använder Akismet för att minska skräppost. Lär dig hur din kommentardata bearbetas.