Norske websites vil aflive IE6 med stor kampagne
Dårlig sikkerhed og manglende understøttelse af teknologier, der er standard ved udvikling af websider i dag. To faktorer, der har gjort Microsofts gamle browser Internet Explorer 6 upopulær blandt dem, der har forstand på det.
Men stadig sker omkring hver sjette besøg på websider via den gamle browser, som i 2006 blev afløst af version 7 af Microsofts browser. Webudviklerne er dermed stadig tvunget til at bruge work-arounds og cowboytricks for at få deres kode og design til at fungere ordentligt i IE6.
Det er norske medier blevet så trætte af, at de nu sammen lancerer en kampagne, der skal få de besøgende til at vågne op og skifte til en nyere browser. Ved besøg på en række af Norges mest populære websider får IE6-brugere præsenteret et banner, der forklarer, at præsentationen af websiden bliver meget bedre ved at opgradere til for eksempel IE7, skriver digi.no.
Tiltaget blev startet af den driftsansvarlige hos handelssitet Finn.no, som hurtigt fik andre medier og websteder med på ideen. Blandt de it-interesserede læsere lyder det eneste kritikpunkt, at banneret med opfordringen til at skifte browser ikke nævner Firefox og andre alternativer.
En fjerdedel af tiden går med IE6-problemer
Den driftsansvarlige hos Finn.no forklarer til digi.no, at en frontend-udvikler kan bruge måske en fjerdedel af sin udviklingstid på at få en webside til at fungere med IE6, fordi browseren har dårlig understøttelse af en række webstandarder. Senest måtte webportalen bruge flere uger på at løse et problem, hvor en annonce ikke blev vist korrekt i IE6.
Derudover sætter IE6 som laveste fællesnævner en stopper for nogle af de mere avancerede muligheder, lyder forklaringen på frustrationerne.
Internet Explorer 6 blev lanceret tilbage i 2001, og da afløseren kom i 2006, blev Windows-brugere tilbudt en automatisk opdatering. Men der var ingen tvang, så mange har holdt fast i den browser, de kendte. Derudover er IE6 standardbrowser i Windows XP, som stadig bliver installeret i stor stil, i stedet for det nyere Windows Vista.
Virksomheder, der holder fast i IE6 på grund af integration med andre applikationer, er en anden faktor, der kan holde browserens andel oppe, uanset kampagner og trusler om begrænset funktionalitet på netaviser. Netstatistikken fra Finn.no understøtter, at virksomhederne er flittige brugere af den bedagede browser. Således er IE6-andelen dobbelt så høj i arbejdstiden.
Blandt Version2's læsere bruger 16 procent stadig Internet Explorer 6, hvilket svarer til det generelle niveau i Danmark.
Kommentarer (32)
Nej, det kan jeg ikke, fordi jeg stadig kører Windows 2000.
Jeg ser ingen grund til at købe ny Windows version, og dermed ny PC, blot for at kunne skifte til IE7.
Man glemmer lidt, at Microsoft ikke har evnet(=villet) lave en ny browser til tidligere versioner af Windows.
Heldigvis kan Firefox(Mozilla) og mange andre finde ud af at lave kompatible programmer.
Men at stille krav om IE specifikke ting, og samtidig kræve IE7(+) er kun med til at generere (unødige) opdateringskrav.
-
0 -
0
Men at stille krav om IE specifikke ting, og samtidig kræve IE7(+) er kun med til at generere (unødige) opdateringskrav.
Du misforstår, for det drejer sig ikke om at man nødvendigvis skal opgradere til at bruge IE7, men man bare skal væk fra den der rædselsfulde IE6 - og det kan gøres f.eks. med Firefox (eller Opera) som snildt kører på en W2K.
/Christian
-
0
-
0
Jeg er enig i det er et problem, Stig, men det er på tide, der bliver gjort noget ved det, for det sinker altså udviklingen helt enormt.
Om det så er Microsoft, som skal tvinges til at lave en "gratis" opdatering til V7/8, det kunne være en løsning.
Må jeg spørge, om du bruger IE6-kritiske funktioner, eller om du har mulighed for at installere en anden browser, f.eks. Firefox?
Nu er det jo ikke alene for webdesignerens skyld. Det er også for brugerens. Som der står i artiklen, man risikerer, at IE6 bliver en stopklods - men på et eller andet tidspunkt, så gider man altså ikke det mere, stopklods eller ej, og så begynder man at bruge de nye ting, som IE6 ikke kan. Hvilket vil sige, du vil ikke kunne få fuldt udbytte af siden.
På den anden side, hvis man vælger at fastholde en IE6, og ved, hvad konsekvenserne er, samt at der er alternative browsere, så er det også fair nok, og så er ovenstående nok heller ikke minded lige på dig, da du så tager et bevidst valg. Der skal selvfølgelig være fall-back på en hjemmeside, så indholdet kan læses, forstås og navigeres, den del er der ikke lavet om på, og det vil komme naturligt, hvis man udvikler i den rigtige rækkefølge.
Men efterhånden vil det komme til at minde ret meget om ren tekst-version i forhold til, simpelthen fordi der er nogle grænser for IE6s formåen, og fordi udviklingen vil fortsætte selv om IE6 står stille. Det vil være eller blive en konsekvens af, at webdesignere ikke længere tager specielt hensyn til IE6. Dette vil man selvfølgelig så skulle finde sig i, men kan man det er det også fint, sålænge valget er bevidst.
I så fald er ovenstående nok mere minded på dem, som stadig bruger IE6, fordi de tror, det er "Internettet", og er uvidende om, der findes andre alternativer.
-
0
-
0
Der skal selvfølgelig være fall-back på en hjemmeside, så indholdet kan læses, forstås og navigeres, den del er der ikke lavet om på, og det vil komme naturligt, hvis man udvikler i den rigtige rækkefølge.
Så simpelt kan du ikke stille det op, for der er så mange graverende fejl i IE6 at det lige præcis ikke kan lade sig gøre at lave din fall-back uden at skulle lave en masse hokus pokus.
Og det er ikke bare et spørgsmål om faciliteter, fsva. HTML, da der på den front egentlig ikke er kommet noget nyt, men om at IE6 bare er kummerlig dårlig til at overholde dem.
/Christian
-
0
-
0
Hm.
Hvis du starter med rent content
derefter HTML (som er validt)
derefter CSS (som er validt)
og derefter lægger funktioner på, f.eks. JS, så vil du altid kunne få en fallabck.
At det så formentlig ser utroligt grimt ud, og at designet med ret stor sandsynlighed vil skride, er en anden sag, men man vil kunne læse det, navigere det (da fall-back er ren HTML) og dermed også forstå det som bruger.
det er i hvert fald hvad jeg har arbejdet efter i lang tid.
Har du eksempler på det modsatte?
I så fald kunne man jo simpelthen bare servere den rene HTML og ikke andet. Altså skippe al JS og CSS for IE6-brugere. Det vil i hvert fald få resultatet til at ligne noget fra før sidste istid, eller sort/hvid i forhold til HD-farveTV
...så ka folk lære det;)
-
0
-
0
Har du eksempler på det modsatte?
Mit yndlingseksempel er Button.
Prøv at lave en side med mere end en knap, som skal trække hver sin action.
Teoretisk kan man lave det i ren HTML, men da Button fortolkes forkert i IE6, sker der det at et klik på lige gyldig hvilken af knapperne fortolkes som submit.
Eneste udvej er at lave et hidden input field, og lade et javascript trække den rigtige action den vej.
Mao, man er nødt til at lave fiks fakserier for at få navigationen til at virke i IE6, og det var ligesom det man gerne ville undgå at skulle spilde tid på.
/Christian
-
0
-
0
"...så ka folk lære det;)"
Har naturligvis ikke noget at gøre med, jeg mener at IE6-brugere skal trynes. Men det har noget at gøre med prioritering af midler og prioritering af tid.
Slipper man for at skulle bruge tid på en oldnordisk browser, vil den tid kunne bruges på resten af sidens indhold, design og funktion. Det vil give flere muligheder, fordi man så yderligere vil kunne følge udviklingen via rene standarder, og ikke mindst det vil helt klart gøre en side billigere i udvikling.
De ting har alt andet lige mere at sige, end maks-krav til design og funktion fra 16% IE6-brugere, fordi de gavner flertallet.
-
0
-
0
@Christian
Har jeg så ikke haft brug for at gøre selv, så jeg er måske ikke helt med.
Mener du f.eks. to forskellige forme med en submit i hver?
Eller en button ved siden af en submit?
Eftersom det ikke kan reddes af "normal" vej, dvs. ved f.eks. at flytte rundt på tags eller andet, som følgeligt ikke involverer hverken CC eller JS, så tvivler jeg på, jeg allerede i dag ville bruge de "fiks-fakserier". Så min side ville altså ikke virke, hvis den havde de funktioner (må jeg vel se i øjnene?)
Jeg har aldrig brudt mig om JS-redninger af IE6-fejl, ejheller brug af Conditional Comments, som er Microsofts måde at lade webdesignere betale for deres (Microsofts) fejl. Ingen af delene bruges til min side, her er jeg ret konsekvent.
-
0
-
0
Rune,
Må jeg spørge, om du bruger IE6-kritiske funktioner, eller om du har mulighed for at installere en anden browser, f.eks. Firefox?
Jeg nævnte Firefox for at antyde, at jeg kan, og bruger, Firefox på Windows 2000.
Peronligt kigger jeg efter indhold når jeg browser på nettet.
Alle de der
nogle af de mere avancerede muligheder
opfatter jeg mest som unødigt støj.
Når det er sagt, så er jeg enig i, at man skal designe til nutidens browsere, og ikke spilde tid på IE6 - så længe indholdet er i ordeqn, kan man nok leve med en anelse forskelligt layout.
At virksomheder 'holder fast' ved IE6 tror jeg lige så meget hænger sammen med fastholdelse af eks. Windows 2000.
Bruger man ActiveX på sit intranet, betyder det, at man reelt ikke har noget alternativ.
Jo opgradere - men en af mine kunder har f.eks. 25.000 PC'ere, så det er ikke 'bare lige', hverken omkostningsmæssigt eller logistikmæssigt.
-
0
-
0
Christian,
Prøv at lave en side med mere end en knap, som skal trække hver sin action. Teoretisk kan man lave det i ren HTML, men da Button fortolkes forkert i IE6, sker der det at et klik på lige gyldig hvilken af knapperne fortolkes som submit.
Jeg har faktisk aldrig oplevet det problem du beskriver. Kan du give et live eksempel på det?
Er det sådan noget som:
[code=html]
<form action="mypage.shtml" method="post">
<input type="button" id="btn1"/>
</form>
<form action="yourpage.shtml" method="post">
<input type="button" id="btn2"/>
</form>
[/code]
-
0
-
0
Stig,
At virksomheder 'holder fast' ved IE6 tror jeg lige så meget hænger sammen med fastholdelse af eks. Windows 2000. Bruger man ActiveX på sit intranet, betyder det, at man reelt ikke har noget alternativ.
Ja - eller fx SharePoint i version 2003 eller OWA. Hvis man anvender SharePoint 2003 og bruger af den indbyggede funktionalitet (hvis man kodede det selv, kunne man jo lige så godt undvære SharePoint), så er det meget svært at komme udenom Microsoft Office og IE.
-
0
-
0
Jeg tror der menes i SAMME form, ikke i to forskellige forms.
PS: hvornår fikser nogen V2's totalt ikke-virkende Re-ting? på ing.dk kan der snildt stå re: re: re: automatisk, men ikke her..
-
0
-
0
Jeg tror der menes i SAMME form, ikke i to forskellige forms.
PS: hvornår fikser nogen V2's totalt ikke-virkende Re-ting? på ing.dk kan der snildt stå re: re: re: automatisk, men ikke her..
-
0
-
0
Adam,
Jeg tror der menes i SAMME form, ikke i to forskellige forms
Ja, det troede jeg også, men Christian skrev jo
[b]Christian Nobel:[/b] Prøv at lave en side med mere end en knap, som skal trække hver sin action.
Mig bekendt kan en FORM kun have én action-attribut, så jeg forstår ikke helt, hvad Christian skulle mene med "trække hver sin action". Selvom man skulle putte flere <input type="submit"/> i sin form, så er action-atributten på form-elementet jo den samme for alle disse knapper.
Jeg har da også nogle eksempler på mystisk opførsel af forms fra Mirosoft-verdenen, men disse fejl er relaterede til autogenereret javascript-kode fra ASP.Net (Visual Studio) og ikke som sådan relaterede til IE selv.
Hvad er problemet med "Re:" på V2?
-
0
-
0
Adam,
PS: hvornår fikser nogen V2's totalt ikke-virkende Re-ting? på ing.dk kan der snildt stå re: re: re: automatisk, men ikke her..
Er det dette du mener: http://www.version2.dk/grupper/Version2gruppen/forum/7301
-
0
-
0
Jeg har set det i følgende situation:
Havde en applikation hvor vi anvendte <button type="submit" ... til nogle knapper this vi ikke kan style <input type="submit" i Safari.
Applikationen reagerer på de unikke navne som er knyttet til hver deres knap.
Hvis man i en IE version trykkede på en <button type="submit" så sendte den faktisk hvad der svarede til at man havde trykket på ALLE <button type="submit" på samme tid.
Det tog sin tid før vi løste det problem.
-
0
-
0
De er ikke alene om det: http://www.techcrunch.com/2008/03/25/save-the-developers-stop-using-inte...
-
0
-
0
Problemet er, at nogen overhovedet finder på at bruge button til en submit.
Den korrekte måde er naturligvis
<input type="submit" name="action1" value="OK"/>
<input type="submit" name="action2" value="Fisk"/>
Det virker fint, også i IE.
At man ikke kan style en submit i Safari, kan vel ikke være IE6's problem?
-
0
-
0
Når muligheden for at lave en submit med en button (den ligger da så vidt jeg ved i standarden), hvorfor implementere den på en så tåbelig måde.
-
0
-
0
Lars, Jørgen,
Når muligheden for at lave en submit med en button (den ligger da så vidt jeg ved i standarden), hvorfor implementere den på en så tåbelig måde.
BUTTON er en ganske valid del af HTML 4.01, hvilket kan ses på http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON
Der står bla:
"Buttons created with the BUTTON element function just like buttons created with the INPUT element (...)"
Yderligere information kan fås via http://www.w3.org/TR/html401/interact/forms.html#successful-controls, hvor der står:
"A successful control is "valid" for submission. Every successful control has its control name paired with its current value as part of the submitted form data set. A successful control must be defined within a FORM element and must have a control name."
"If a form contains more than one submit button, only the activated submit button is successful."
Med andre ord, hvis der på en side er to "BUTTON"-controls, som
[code=html]
<form action="cgi/handler.shtml" method="get">
<button type="submit" name="btn1" value="OK"/>
<button type="submit" name="btn2" value="FAIL"/>
</form>
[/code]
Så vil dette med IE6 resultere i et GET-request som
/cgi/handler.shtml/?btn1=OK&btn2=FAIL
ved klik på btn2 og ikke som det korrekt bør være:
/cgi/handler.shtml/?btn2=FAIL
?
-
0
-
0
... og jeg kan afsløre, at min antagelse ovenfor er korrekt.
Denne HTML
[code=html]
<html>
<head>
<title>IE6 submit test></title>
</head>
<body>
<form action="test.html" method="get">
<button type="submit" name="btn1" value="OK">OK</button>
<button type="submit" name="btn2" value="FAIL">FAIL</button>
</form>
</body>
</html>
[/code]
Resulterer i dette request med IE6:
GET /test.html?btn1=OK&btn2=FAIL
Firefox giver
GET /test.html?btn1=OK
eller
GET /test.html?btn2=FAIL
-
0
-
0
Jesper, som du selv har doseret dig frem til, ja så drejer det sig ganske rigtig om to (eller flere) knapper i samme form.
Jeg bruger det til et menusystem, hvor tryk på knap A fyrer cgi script A af, mens tryk på knap B fyrer script B af osv.
Det er helt legitimt i forhold til standarden, som kom i draft svjh i 97 og blev ratificeret i 99, altså samtidig med MS havde IE version 5.
Der skulle så lige komme IE 5.1, 5.5, 6.0 før at det endelig virkede korrekt i IE7 efter 10 år!
Måden jeg så kommer uden om den er ved at have to hidden input fields hvori jeg fylder hhv scriptnavn og value i, og lader onclick scriptet trække værdien herfra.
Man kunne også godt bruge input i stedet for button, men så kan man ikke style, plus man kan ikke skelne mellem knappens navn og dens værdi hvilket er noget hø hvis man f.eks. gerne vil have knapteksten til at hedde noget pænt som "Accepter valg", men værdien til bare at hedde "accept".
/Christian
-
0
-
0
øh, det sidste forstår jeg ikke helt, det er da det man anvender name og value attributterne til, og man skal jo lige netop ikke kigge på værdien af submitknapper, men variabelnavnet, det har i hvert fald fungeret fint for mig.
-
0
-
0
øh, det sidste forstår jeg ikke helt, det er da det man anvender name og value attributterne til, og man skal jo lige netop ikke kigge på værdien af submitknapper, men variabelnavnet, det har i hvert fald fungeret fint for mig.
Ja, men som jeg skrev, man kunne også bruge input (i stedet for button), men så er det man får problemet med at man ikke kan skelne.
/Christian
-
0
-
0
det forstår jeg stadigvæk ikke, jeg kan da sagtens skelne mellem
<input type="submit" name="hest" value="Gem" />
og
<input type="submit" name="nisse" value="Slet" />
hele pointen er jo ikke at kigge på værdien, den kan brugerne lave om til at muligt.
-
0
-
0
Nej, for hvis jeg bruger input som button, så vil det der står på dine knapper hedde hhv "Gem" og "Slet", altså det samme som din value.
Men jeg vil have value til at hedde hhv. "gem" og "slet", men knapteksten skal f.eks. hedde "Gem ny datapost" og "Slet post".
Og det kan man ikke.
Og så kan input heller ikke styles som knap.
/Christian
-
0
-
0
Du kan da skrive hvad du vil, input viser value som knap tekst, og du ignorerer værdien i din bagend fordi du netop kigger på variablenavnet i stedet for værdien.
Sådan har jeg da hele tiden bygget mine applikations, og undret mig meget når jeg har skulle slille webablikationer ad som slet ikke anvendte name taget til noget.
Vi bygger sikkert applikationer på hver sin måde, normalt har alle mine submit tags deres helt eget variablenavn under name som backenden reagerer på. Hvis man har to inputs med samme name men som skal gøre noget forskelligt alt efter værdien så kan jeg godt se problemet.
-
0
-
0
Hvis man har to inputs med samme name men som skal gøre noget forskelligt alt efter værdien så kan jeg godt se problemet.
Præcis.
Jeg bruger det f.eks. til en knapbaseret navigator i en database, altså post frem, post tilbage osv.
Submitten trækker samme cgi program, lad os kalde det showbase.
Mit input kunne så være:
<input type="submit" name="selection" value="next" />
<input type="submit" name="selection" value="prev" />
Hvilket vil resultere i følgende:
showbase?selection=next
og
showbase?selection=prev
(det står der nu ikke i URL, for jeg bruger post, men det er en anden historie)
Men jeg vil altså ikke have der står prev og next på knapperne, men noget brugervenligt som "Forrige" og "Næste"
Og det kan man altså kun gøre med button.
/Christian
-
0
-
0
klart nok
Det kommer jo an på metoden den somlaver applikationen bedst kan lide at arbejde med.
-
0
-
0
Bruger man ActiveX på sit intranet, betyder det, at man reelt ikke har noget alternativ. Jo opgradere - men en af mine kunder har f.eks. 25.000 PC'ere, så det er ikke 'bare lige', hverken omkostningsmæssigt eller logistikmæssigt.
Netop derfor tror jeg heller ikke på total udryddelse. Men hvor ville det dog være helt enormt dejligt bare at få den ned omkring de dér 4-5%
;)
-
0
-
0
