kaxigt.com

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

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

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.

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.

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.

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.

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?

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?

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

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

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.

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.

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.

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.

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)

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

Joel Arvidsson

#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:

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

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:

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

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

Eller med shorthand och marginalgenskaperna:

.container
{
	margin: 0 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

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; }

<style tyle="text/css">
<!--
h1 { voice-family: talare;}
p.part.romeo {voice-family: romeo, man;}
p.part.juliet { voice-family: julia, kvinna;}
-->
</style>

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;  
}

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

#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!!!

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

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

IE7 och hasLayout

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å.

• IE7-/Win: A box with position:absolute next to a float may disappear
• The hasLayout Property Triggers and Resets
• IE7-/Win: negative margins, position:relative, hasLayout
• IE7-/Win: Margin collapsing and hasLayout
• IE7-/Win problems with absolute positioning inside a relative element
• IE7-/Win: Double top padding on a clear with background and no hasLayout

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

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

#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

#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:

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

#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, 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>

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.

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.

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.

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.

#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.

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.

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.

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.

Hur det kunde se ut innan giljotinbuggen triggades.

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

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.

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*

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.

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.

• Tantek – Hacks och filter
• Simplebits – csstips
• Max Design
• Advanced css introduction
• P.I.E – position is everything
• Learn CSS Positioning in Ten Steps
• Ny ”clearing” metod för IE7
• How To Clear Floats Without Structural Markup
• ”Easy-hacks” för IE
• The Most Common CSS Markup Errors
• CSS Inheritance
• Alternative Style: Working With Alternate Style Sheets
• Alternate Style Sheets and Media Types
• CSS browser configuration
• Absolut och relativ
• Containing Floats
• Avoiding Hacks – Margin instead of padding
• max-width in Internet Explorer
• Internet Explorer 7 and starHTML
• Little boxes
• Grids, tables, CSS
• Columns & Grids
• CSS Grid Calculator
• Five simple steps to designing grid systems
• Thinking Outside the Grid
• Fixed or fluid width? Elastic!
• On Fixed vs. Liquid Design
• Alla CSS-ändringar för IE 7 – en väldigt intressant sida.
• The IE6 Three Pixel Text-Jog