Konqueror slaagt voor Acid2-test na injectie van Safari-code

Op 17 maart daagde het Web Standards Project Microsoft uit om ervoor te zorgen dat de Acid2-test goed gerenderd zou worden in versie 7 van Internet Explorer. Van Microsoft is hierover nog niets vernomen, maar andere browsermakers hebben al wel bekendgemaakt bezig te zijn om ervoor te zorgen dat hun browser de test goed rendert. Dit zorgde ervoor dat eind april gemeld kon worden dat Safari, de browser die in Mac OS X aanwezig is, de eerste browser was die Acid2 correct renderde. Enige weken later werd bekend dat het de ontwikkelaars van de Mac OS-browser iCab ook was gelukt om de Acid 2 correct te laten renderen. De derde browser die de Acid2-test nu op de juiste manier rendert, is Konqueror.

Konqueror maakt gebruik van KHTML als renderengine; op deze engine is ook WebCore gebaseerd, de renderengine van Apples Safari. Gehoopt werd dan ook dat het mogelijk zou zijn om de wijzigingen uit WebCore te kunnen kopiëren naar KHTML. Al snel bleek dat dit niet zo eenvoudig zou zijn, omdat WebCore gebruikmaakt van specifieke Mac OS X-functies die in KHTML dus niet aangeroepen kunnen worden. Daarnaast gaf Apple weinig code terug aan de KHTML-community en als dat al gebeurde waren dat vaak zulke grote patches dat het erg moeilijk was om er iets mee te kunnen doen zonder kennis te hebben van wat er allemaal gewijzigd was en waarom dat gebeurd was.

Dit alles heeft ervoor gezorgd dat de ontwikkelaars van KHTML erg ontevreden waren geworden over de samenwerking met Apple. De ontwikkelaars van Konqueror hebben zich hierdoor echter niet laten tegenhouden om de patches van Safari-ontwikkelaar David Hyatt toe te passen op KHTML. Ongeveer de helft van de patches kon zonder noemenswaardige problemen worden toegepast op de KHTML-codebase. Twee andere bugs konden worden opgelost door code te mergen vanuit Safari 1.3 en de overige bugs zijn opgelost door zelf code te schrijven. De fixes bevinden zich op dit moment in de KDE 3.5-branch, maar zullen worden geport naar KDE 4 en mogelijk naar KDE 3.4.2.

Reacties (48)

[Titusvh]

Wel leuk bedacht, een test die enkel een simpel lachebekje als resultaat heeft, terwijl het toch een goede test is. Ik had een veel ingewikkelder pagina verwacht.

Je wil dan ook niet weten wat firefox er van maakt. Een uit totaal elkaar gerukte lachebek.
Over MSIE6 maar niet te spreken, die is nog erger, daar is geen lachebekje in te herkennen.

Probeer het zelf: http://www.webstandards.org/act/acid2/test.html#top

[rtgo]

Ik snap best dat MS niet heeft gereageerd op de acid2 uitdaging omdat hun prioriteiten anders liggen. Maar ik hoop dat toch iemand bij MS de ballen heeft om de uitdaging aan te gaan.
Ik vind het trouwens best wel zwak dat mozilla, de meest serieus genomen concurrent van IE, het ook niet goed doet (wel veel beter). Vooral omdat men altijd zo lyrisch is over hoe FF omgaat met standaarden. Hopelijk betekent dit dat de andere 'alternatieve' browsers hierdoor meer voet aan de grond krijgen (ik betwijfel het). Meer concurrentie in de browserwereld zorgt voor meer druk op de implementatie van webstandaarden. En die druk is gezien de resultaten van deze test nog steeds hard nodig.

[Harm]

Ik vind het trouwens best wel zwak dat mozilla, de meest serieus genomen concurrent van IE, het ook niet goed doet (wel veel beter).

Just wondering, heb je enig idee van hoe ingewikkeld het is om een goede renderengine te schrijven? Volgens mij niet. Op het moment dat Acid 2 gelanceerd werd, waren de ontwikkelaars van de Mozilla Foundation bezig met het klaarmaken van alpha- en bètaversies van Gecko 1.8. De bedoeling van die versies is dat er grondig getest wordt om bugs te vinden en die op te lossen. Het is niet de bedoeling om op dat moment nog allerlei nieuwe features toe te voegenof enorme codewijzigingen door te voeren, omdat dat alleen maar instabiliteit, regressies en nieuwe bugs oproept. Het toevoegen van support voor Acid2 is niet iets triviaals.

Vanzelfsprekend is erover gesproken om Gecko 1.8 Acid2-compatible te maken, maar juist omdat die Gecko-versie al zo ver heen was in het releasestadium is besloten Acid2 op dit moment te laten voor wat het is en die dingen te doen waar iedere gebruiker wat aan heeft. Dat is namelijk niet het geval bij Acid2. Die test test namelijk veel obscure CSS-functies die vrijwel nooit in real life situations voorkomen. Nadat dit alles in overweging is genomen, is besloten Acid2-support in Gecko 1.9 te stoppen.

De Acid2-trackingbug is hier te vinden.

[RetepV]

Just wondering, heb je enig idee van hoe ingewikkeld het is om een goede renderengine te schrijven? Volgens mij niet.

Maakt dat ook maar IETS uit? Hoe ingewikkeld het ook is, het wordt gedaan om er geld mee te verdienen. En er wordt altijd meer geld mee verdiend dan het kost, anders deden mensen het niet.

En ZO ingewikkeld is het nou ook weer niet. Er zijn heel wat ingewikkelder stukken software out there, en die worden ook goed gemaakt.

[Unverter]

Ik vind het trouwens best wel zwak dat mozilla, de meest serieus genomen concurrent van IE, het ook niet goed doet (wel veel beter). Vooral omdat men altijd zo lyrisch is over hoe FF omgaat met standaarden.

Alle browsers hadden problemen met de test, omdat nog niet alles ondersteund werd en er nog wat bugs in bepaalde onderdelen zaten. Safari, Konqueror en iCab hebben die problemen snel opgelost en Opera is ook druk bezig.
Het probleem voor Mozilla is dat de renderingsengine al een tijdje in beta-stadium zit en er dus niet al te veel risicovolle wijzigingen aangenomen worden. Dat is wel nodig om te slagen voor deze test. Ik verwacht dus dat als de ontwikkeling van de volgende versie van de renderingsengine begint Firefox ook redelijk snel de test zal halen. Voor gebruikers is dat dan pas in Firefox 1.5 beschikbaar (ergens in 2006).

Hopelijk betekent dit dat de andere 'alternatieve' browsers hierdoor meer voet aan de grond krijgen (ik betwijfel het). Meer concurrentie in de browserwereld zorgt voor meer druk op de implementatie van webstandaarden. En die druk is gezien de resultaten van deze test nog steeds hard nodig.

Omdat het voor Firefox net vervelend uitkwam betekent niet dat ze de standaarden aan hun laars lappen. De Gecko engine blijft goed en gebruikers zullen niet alleen hierdoor overstappen. Het vervelende is dat mensen alleen niet dat mensen Firefox zullen bekritizeren omdat het waarschijnlijk de laatste engine (op IE na) zal zijn die de test zal ondersteunen.

[rtgo]

Populariteit en snelheid van introductie komt vaak met consessies voor de kwaliteit. Je kunt immers niet blijven wachten met het uitbrengen van je browser omdat er steeds nieuwe uitdagingen komen. Het probleem met Firefox is dat het vrij vroeg in het productieproces beschikbaar is (dat is een gevolg van open source en relatief vroege beta stadia).

Maar het valt mij steeds meer op dat de meest populaire browsers, IE en FF, het langzaamst ontwikkelen. Dat is natuurlijk logisch omdat je je richt op een groot publiek dat een goed werkend product wilt. Het is alleen zo jammer. Dit gelt trouwens vooral voor IE omdat MS dit probleem met geld zou kunnen oplossen. Iets dat bij mozilla toch een groter probleem is.

Ik concludeer dat producten voor een groot publiek relatief achter lopen en dat we dat bij Firefox steeds meer zullen gaan zien. Bij IE gebeurt al een hele tijd vrij weinig om dezelfde reden.

[Pietervs]

Ik snap best dat MS niet heeft gereageerd op de acid2 uitdaging omdat hun prioriteiten anders liggen.
aangezien MS toch bezig is met de ontwikkeling van IE7, zouden ze dit natuurlijk meteen mee kunnen nemen. Sterker nog: het zou een blunder zijn als ze het niet doen: het duurt nog wel even voordat IE7 daadwerkelijk op de markt komt, en het zou vrij knullig overkomen als ze kort na de release een update uit moeten geven om alsnog dit te kunnen ondersteunen...

[Verwijderd]

Waarom zouden ze dit moeten ondersteunen. Deze test maakt gebruik van obscure technieken die in praktijk niet relevant blijken. Het implementeren van deze standaard is dus het implementeren van oude en vrijwel ongebruikte technieken. MS kan zich beter richten op zaken op nieuwe technieken waar ontwikkelaars in potentie veel meer aan hebben in plaats van achteruit te kijken naar technieken die niet echt nuttig gebleken zijn.

[Verwijderd]

@Pietje Puk

Ze moeten natuurlijk niks, moeten ze lekker zelf weten... maar deze test maakt geen gebruik van "obscure technieken die in de praktijk niet relevant blijken", en al zeker geen "oude en vrijwel ongebruikte technieken"

als de technieken ongebruikt zijn, komt dat alleen maar omdat ze te nieuw zijn.

CSS is the future voor webdevelopers

[ymmv]

Misschien ben ik gek, maar bij mij gaat de Acid2-test vlekkeloos met IE6. Volledig identiek met het referentieplaatje. En dat terwijl meerdere mensen melden dat bij hun IE de smiley niet goed kan weegeven ???

(Firefox 1.04 bakte er trouwens niet zo veel van.)

[n4m3l355]

ligt het aan mij of klinkt het alsof ze een engine in elkaar gehacked hebben om een test te kunnen doorstaan? ik kan me niet goed voorstellen dat dit de snelheid, kwaliteit en veiligheid ten goede komt

[RetepV]

Dat is waar standaards voor zijn. Er wordt een standaard bedacht, en dan is het de bedoeling dat iedereen zijn engine zo bouwt dat ze aan die standaard voldoen. Als de engine daarvoor 'omgehacked' moet worden, dan betekent dat alleen maar dat je engine een stuk prutswerk is.

Ik verwacht niet dat een freeware/OS engine prutswerk is, want anders was dat al breeduit uitgemeten in de pers.

Of een closed-source browser als Internet Explorer prutswerk is, zullen we nooit weten. Het feit echter dat in Internet Explorer de breedte van tables en frames niet pixel-nauwkeurig opgegeven kunnen worden, en er zelfs interne afrondingsfouten gemaakt worden zegt wel iets over de kwaliteit van Microsoft's HTML renderer.

Ook het feit dat Microsoft nog niets van zich heeft laten horen, zegt al genoeg. Microsoft heeft voor IE 7 een blik programmeurs opengetrokken die er full-time mee bezig zijn. Toch is de open source gemeenschap eerder met ondersteuning van de nieuwe standaards. Terwijl de OS gemeenschap hun software schrijft in hun eigen vrije tijd. Dat betekent imo één van de volgende drie dingen: 1) Microsoft heeft prutsprogrammeurs 2) Microsoft interesseert die standaards helemaal niks 3) Microsoft saboteert de standaards expres om zich te onderscheiden van de concurrentie.

Sja, alle 3 de redenen zijn even vervelend voor de consument (waar het bedrijfsleven ook toe behoort). Maar ik kan me niet voorstellen dat ze prutsprogrammeurs hebben. Daarnaast roepen ze zelf regelmatig dat ze het belang van standaards inzien. Dus blijft imo sabotage over.

Microsoft saboteert de web standaards nu al behoorlijk lang, en blijkbaar zijn ze nog niet van plan daar iets aan te veranderen.

[Dreamvoid]

Tsja, volgens die redenering zouden Firefox en Opera dus ook doelbewust de zaak saboteren door Acid2 niet te ondersteunen Acid2 bevat heel raar (maar wel correct) gebruik van CSS/HTML, en daar heeft elke huidige browser moeite mee. De huidige situatie bij IE is gewoon dat MS jarenlang geen nieuwe features meer heeft toegevoegd, en geen/weinig aandacht besteedt aan bugs in exotische CSS functies als die in Acid2 (die "in het wild" nauwelijks voorkomen). MS zit nu overduidelijk meer aan het security fixen dan aan het perfectioneren van de render engine zelf. Uiteraard jammer, maar om daar nou direct een complot theorie aan te hangen...

Verder is het doorlopen van de Acid2 test nog maar de eerste stap. Een pagina correct renderen die je van te voren al door en door kan bekijken is iets heel anders dan het onder alle omstandigheden correct renderen van elke willekeurige functie die daarin zitten.

[Verwijderd]

De huidige situatie bij IE is gewoon dat MS jarenlang geen nieuwe features meer heeft toegevoegd, en geen/weinig aandacht besteedt aan bugs in exotische CSS functies als die in Acid2 (die "in het wild" nauwelijks voorkomen)

Dat is niet zo verwonderlijk. Mensen zullen niet gauw CSS functies gebruiken die niet door Internet Explorer ondersteund worden. ;-)

[NoepZor]

Ik heb het getest met Firefox, en daarmee kom ik ook niet tot het plaatje hierboven.. Dus zowel IE als Firefox hebben nog verbeteringen nodig in de renderer

[mosymuis]

Tsja, volgens die redenering zouden Firefox en Opera dus ook doelbewust de zaak saboteren door Acid2 niet te ondersteunen

Ik denk dat je de strekking van RetepV's post verkeerd hebt opgevat. Hij legt twee feiten naast elkaar; (1) Microsoft heeft nog enkele verklaring naar buiten gebracht over mogelijke Acid2 ondersteuning in IE7, en (2) de open source browsers iCab en Konqueror (/Safari) zijn hier zelfs al klaar voor. Samen met de gegeven beredenatie mag je daarom best tot de voorlopige conclusie komen dat Microsoft weinig belang ziet in het omarmen van deze test. Mozilla en Opera hebben het respectievelijk al aangekondigd of zeggen er zelfs al mee bezig te zijn; hen treft dus geen blaam.

[Verwijderd]

@ noepzor

doe het eerst eens met firefox en daarna met IE. bij FF zie je nog iets van een smiley (alleen heeft hij een zeer harde klap op zijn gezicht gehad), maar bij IE kan ik niet eens een smiley herkennen. het is gewoon een rooie balk onderaan. het lijkt er dus op dat FF minder zal hoeven aan te passen als MS (NOFI)

[Verwijderd]

Wat hier gebeurd is dat men een engine die op zich redelijk werk aflevert heeft mishandeld om één pagina goed te laten zien. Dat wil niets zeggen over de kwaliteit van de engine. Juist door zomaar code te copy/pasten zonder iets te begrijpen van wat die code zou moeten doen bestaat de kans dat er incompatibiliteiten met andere pagina's zijn ontstaan en dat er securitygaten bij zijn gekomen.

Op zich leuk dat deze pagina nu correct werkt, maar de gebruikte methode om tot dit resultaat te komen is nou niet echt fantastisch.

Microsoft saboteert trouwens geen standaarden. Zij creeren hun eigen webstandaard. Dat de andere browsers niet compatible zijn met IE is niet microsofts probleem. Zolang websites ermee weg kunnen komen dat hun site gebouwd is voor IE 5/6 is dát de daadwerkelijke standaard. De overige standaarden zijn goed voor het oud papier. Je ziet steeds meer dat bedrijven hun sites gaan testen voor andere browsers maar de eis dat het moet werken op IE blijft nog steeds de basis. Ondersteuning van de "officiele" standaard is bijzaak.

[bsander]

Wat hier gebeurd is dat men een engine die op zich redelijk werk aflevert heeft mishandeld om één pagina goed te laten zien.

Een van de oorzaken dat de KHTML developers de patches van Apple niet zo snel overnemen is dat apple vaak met een quick fix komt terwijl ze bij KHTML graag structurele oplossingen vinden. Wat hier dus is gebeurd is niet dat de KHTML engine mishandeld is, maar juis geperfectioneerd.

Microsoft saboteert trouwens geen standaarden. Zij creeren hun eigen webstandaard.

En op welke manier is dat dan niet het saboteren van reeds bestaande standaarden?

[kidde]

Toch, als je de wat over de acid2 test leest, gaat het om 'wat web-developers graag zouden willen gebruiken'.
Dus is het wel degelijk een probleem denk ik, als IE dit niet ondersteunt. Vooralsnog stopt dit inderdaad deze developers om te maken wat ze leuk vinden, maar stel nou dat Firefox het wel rendert, uit Europees onderzoek van Xitimonitor bleek dat momenteel al 13% van de Europeanen Firefox gebruikt, dus wie weet hoe het nog veranderd.
Het zou mij niet verbazen als IE7 deze test dus goed gaat renderen, want, zoals Steve Ballmer al stuiterend over het podium ooit aangaf: Developers, developers, developers ...... (In dit geval Web Developers). Die moet je acher je hebben, anders ben je genaaid.

[arjenhiemstra]

@bsander
Ik dacht dat de KHTML developers zelf aangegeven hadden dat de code in zulke grote brokken naar het KHTML team komt dat ze het overzicht kwijt zijn.
Dat heeft dus niets met een quick fix oid te maken...
Daarnaast zijn delen van de Safari code tegen het OS aan geprogrammeerd wat het extra lastig maakt zaken te porten...

[bsander]

arjenhiemstra:

Da's helemaal waar, maar dat is niet de enige reden. Het is een combinatie van de grote patches (soms diffs van enkele MBs groot), de onduidelijkheid over wat voor bugs er gefixt worden (referenties naar Apples interne bugtracker), inderdaad het gebruik van Apples APIs, maar dus ook soms de kwaliteit van de patches, zoals een KDE devoper hier zegt:

In open source, everything's supposed to be done the right way, but sometimes the less correct way is faster," Rusin said. "In fixing one problem, they were breaking a whole bunch of other things. Apple developers were focused on fixing bugs in such a way that we could not merge them back into KHTML. Those fixes were never an option for us."

[Verwijderd]

Ook het feit dat Microsoft nog niets van zich heeft laten horen, zegt al genoeg. Microsoft heeft voor IE 7 een blik programmeurs opengetrokken die er full-time mee bezig zijn. Toch is de open source gemeenschap eerder met ondersteuning van de nieuwe standaards.

Heb jij al een final versie van IE 7 gezien?? Lijkt me niet dat ze tot die tijd ook maar 1 test hoeven te doorstaan.

[Wildfire]

Lees http://www.webstandards.org/about/mission/nl/ maar eens.

Het gaat over compatibiliteit met webstandards.

[mOrPhie]

Safari is gebaseerd op KHtml. De engine die Konqueror gebruikt voor het renderen van websites. De engine is orgineel begonnen bij KDE en later ook gebruikt door Apple. Nu heeft apple aanpassingen gedaan in Safari, die nu dus zijn teruggemerged in KHtml. Dit komt dus juist de snelheid, stabiliteit en veiligheid ten goede, omdat hier ook veel bug en performanceissues in zijn opgelost.

[ventje853]

op de standaard versie van safari werkt het niet.

je hebt een speciale aangepaste versie nodig van safari om het goed te laten verschijnen. dat kreeg ik indertijd als antwoord op mijn vraag waarom het niet werkt op elke safari.

[TrailBlazer]

nou vraag ik me af hoe ze dit bij webstandards getest hebben. Het lijkt mij nog lastig om zoiets als puur code op te bouwen en vervolgens hopen dat er iets gemaakt wordt wat de code kan weergeven.
Alsof je een driver schrijft en vervolgens hopen dat iemand bv een geluidskaart maakt die er zinvol geluid uit krijgt

[Olaf van der Spek]

Alsof je een driver schrijft en vervolgens hopen dat iemand bv een geluidskaart maakt die er zinvol geluid uit krijgt

Je begint met een specificatie (HTML specs) en schrijft dan de driver (HTML pagina). Dan schrijf je de geluidskaart (HTML renderer).
Kan toch prima?

Maar bij hardware pas je vaak de driver aan als de hardware niet helemaal aan de specs voldoet. Bij HTML kan dat natuurlijk niet.

[TrailBlazer]

ja maar webstandaards zullen toch wel ff zelf gekeken hebben hoe de testpagina er uit zal gaan zien. Beetje lullig als ze er een testpagina eropzetten waar een foutje in zit

[Verwijderd]

Just for the record hier een linkje naar de eerste Acid testpagina, die alle browsers (jaja, ook IE) nu correct weergeven. Acid1-test vereiste CSS1 ondersteuning.

http://style.cleverchimp.com/boxacidtest/vd/

[Verwijderd]

iemand die dit uit kan leggen?
als je de broncode bekijkt zie je dit:

<p><table><tr><td></table><p class="bad"> <!-- <table> closes <p> per the HTML4 DTD -->

table tag sluit p tag af dat begrijp ik dan uit dat comment, maar die tr en td worden geopend zonder te sluiten? mag dat in html4?

edit: spelfout

[Jeldert]

Ja, dat mag volgens W3: Start tag: required, End tag: optional

[Fuzzillogic]

Ja dat mag. HTML4 is geen XML formaat.

[Verwijderd]

Volgens mij is het zo dat zodra je de table tag sluit, dat alle sub elementen ook automatisch gesloten worden. Dus zodra de table sluiten tag wordt gebruikt, einde verhaal alle tr en td tags.

-R-

[Verwijderd]

Nou wat is dat voor rare shit het werk niet in deze browsers:

-firefox
-ie
-opera
-netscape(ie / firefox render)

[_Thanatos_]

Dat maakt het nog geen rare shit. Die code in de test is zo modern en zo exotisch dat het *nog* niet werkt in moderne browsers. maar bedenk wel dat opera 8.01 het al een stuk beter doet dan z'n voorgangers. en firefox wordt er ook steeds beter in. IE zullen we het maar niet over hebben dus

[Verwijderd]

Vergelijk het maar met "Het groot dictee der Nederlandse taal". Dat staat bol van de woorden en zinsconstructies die geen zinnig mens ooit in het dagelijks leven zal gebruiken, maar het is wél correct Nederlands. Doordat het zoveel obscure constructies en woorden bevat is het wel optimaal geschikt als test: als je dat goed kunt, dan zul je ook wel geen moeite hebben met de dertien-in-een-dozijn d-tjes en t-jes.
Zo is het ook met deze test: expres zo obscuur opgezet dat geen enkele browser het direct goed doet; er komen constructies in voor waar geen enkele browser-ontwikkelaar ooit aan gedacht had. Maar, als hij het eenmaal correct rendert, dan zal hij ook wel geen moeite meer hebben met de dertien-in-een-dozijn <td>-tjes en <br>-etjes.

[_Thanatos_]

Nou, deels heb je wel gelijk, maar je moet je wel voorstellen dat browser-makers kunnen besluiten om te zolang te coden totdat deze test slaagt. Maar er zouden dan soortgelijke tests moeten zijn die hele andere obscure dingen doen. Maar ook tests die eenvoudigere dingen doen.

Want zo werkt programmeren nou eenmaal: je kunt het nog zo geavanceerd maken, maar iets eenvoudigs kun je makkelijker kapot maken, omdat je dat "wel gelooft" als tester/ontwikkelaar.

Er zou dus eigenlijk een zeer complete test voor browsers moeten bestaan. Een soort unit test (programmeurs zijn wel bekend met die term) dus eigenlijk.

[Marcel]

Hmm, mijn Safari (versie 2.0, build 412) bakt er anders niks van. Welke versie zou de test-pagina correct moeten renderen? Firefox (versie 1.0.4) maakt er trouwens ook een puinhoop van.

[Cybje]

Het zit nog niet in een voor gebruikers vrije versie. In het nieuwsbericht over Safari/Acid2 staat:

Wanneer deze wijzigingen voor gewone gebruikers beschikbaar komen, is nog niet bekend.

[akakiwi]

Hier rendered Opera 7.51 het niet goed en de laatste versie van IE (6.0.2900) bakt er nog minder van.
Spannende pagina dus om te renderen.

[stewie]

Apple is nog bezig met het uitvoerig testen van de browser die well de Acid2 test passed

deze zal in 10.4.2 gewoon werken

[GiLuX]

ik heb die test ook net even in mosaic 1.0 geprobeerd maar die doet het ook niet helemaal goed...

[Verwijderd]

Doet http://www.google.nl het ook goed?

[Guru Evi]

In ieder geval moet IE nog heel veel doen om correcte CSS te renderen. Zelfs gewone sites die heel erg correct zijn opgebouwd geven fouten in IE.
Check this: http://www.valerieandevi.be/subdom2subdir/
Daar zit ik dus met het probleem dat mijn CSS correct is (gechecked met de w3.org engine) en dat mijn HTML correct is (strict!) en in IE heb ik zo'n rare balk en in FF niet.

[FLYhard]

@ Guru Evi erg vreemd, ik zou idd ook zeggen dat het een probleem zou wezen met een open tag oid, en zeker omdat het in firefox wel goed werkt, en die borders van die w3c links blouw zijn in IE.

ik kan ook niks in je code vinden wat verkeerd staat, IE moet dus gewoon nog aan hun standaard werken.

dus moetten de mensen die jouw pagina bekijken maar gewoon firefox gebruiken

/edit
ik kijk net in je code, en ik zie dat je de <br> tag gewoon zo gebruikt ipv <br /> (nou heb ik nog nooit een page stict gemaakt, maar bij traditional is dit wel verplicht , mischien gebruik je de verkeerde validatie?