Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 149 reacties
Submitter: Maria_von_Trapp

Microsoft heeft met de ontwikkeling van Internet Explorer 8 een belangrijke mijlpaal bereikt. De nieuwe browser is geslaagd voor Acid2, een complexe rendertest die aantoont of een browser aan de exacte html- en css-specificaties voldoet.

Acid 2 IE8 Hoewel de Acid2-test geen erkende standaard is, heeft het zich de afgelopen jaren wel ontwikkeld tot een belangrijke benchmark op dit gebied. Eerder al slaagden onder andere Omniweb, Safari en Opera voor de test. Ook de laatste bèta's van Firefox 3.0 hebben de Acid2-test gehaald. Microsoft sluit nu vol trots aan in dit rijtje, zo heeft Dean Hachamovitch van het IE-team bekendgemaakt.

Volgens Hachamovitch hebben verbeterde ondersteuning voor webstandaarden en interoperabiliteit prioriteit bij de ontwikkeling van IE8. 'Het belangrijkste is interoperabiliteit', aldus Hachamovitch. 'Als ontwikkelaar wil ik liever niet elke website meerdere keren ontwikkelen voor meerdere browsers. Ons doel bij IE8 is de juiste set standaarden te ondersteunen zonder het huidige web tekort te doen.'

Eerder deze maand maakte Microsoft officieel bekend dat de opvolger van IE7 logischerwijs IE8 zal heten. De fabrikant werd hierbij echter bekritiseerd omdat er anders dan de officiële naam geen aanvullende informatie werd vrijgegeven. De softwaremaker lijkt van deze kritiek te hebben geleerd, en heeft een video-interview gepubliceerd waarin met diverse Microsoft-experts wordt gesproken over IE8, css, compatibiliteit en rendering. De eerste testversie van IE8 wordt in de eerste helft van 2008 vrijgegeven.

Moderatie-faq Wijzig weergave

Reacties (149)

Als ontwikkelaar wil ik liever niet elke website meerdere keer ontwikkelen voor meerdere browser. Ons doel bij IE8 is de juiste set standaarden te ondersteunen zonder het huidige web tekort te doen.'
Dat dat nodig is, is toch echt de schuld van Microsoft. Hun hebben nog nooit netjes de standaarden gebruikt, en hun hebben er voor gezorgd dat ontwikkelaars nu voor zowel Fx/Opera als voor IE6 en voor IE7 een aparte website moeten maken.

Ik ben er blij om dat ze bij Microsoft nu eindelijk het licht zien en toch netjes de standaarden gaan hanteren. Dat wordt voor webontwikkelaars beter, maar ook voor de gewone consument, aangezien deze dan zelf een browser kan kiezen voor alle websites, en niet gebonden zijn aan IE voor die éné website wat niet in Fx mooi uitziet.
Dat is niet helemaal waar. IE was er al VOORDAT W3C met een standaard kwam. W3C heeft toen een afwijkende set opgesteld als standaard.
Ok, maar netscape was er voor IE, en IE gebruikte al een afwijking van de standaard die min of meer door netscape gevestigd was. En zo kan je doorgaan.

Het W3C heeft een standaard genomen die een logisch compromis was tussen de gangbare dialecten, en alle browsers hebben er zich intussen naar geschikt, behalve IE.

Dat is te zeggen, natuurlijk hebben ze niet allemaal volledige ondersteuning, maar IE6 (nog steeds de meest gebruikte versie) is niets minder dan een ramp.
Jij bent één van die mensen die door Microsoft betaald wordt om overal te gaan lullen ? W3C bestaat al sinds 1994 !

Microsft kiest al zijn levenlang om eigen 'standaarden' te ontwikkelen in de hoop dat de wereld hen volgt. Internet explorer is het eerst uitgeleverd als uitbreiding op windows 95 ! (zat niet standaard bij eerste versie van windows 95 - microsoft zag het nut van 'het internet' niet echt in op die tijd)

Bovdendien is het W3C opgericht door Tim Berners-Lee, de uitvinder van het -www- (niet internet !) en de ontwerper van de eerste versie van HTML (1990)

Dus ik snap niet hoe jij er in de verste verte bijkomt dat de W3C nadat IE een dan nog afwijkende set als standaard heeft opgesteld ?
Dan nog had Microsoft IE zo kunnen aanpassen dat deze zich aan de standaarden hield, toen de standaarden daar waren. In jou reactie lijkt het alsof je roept dat het W3C standaarden heeft gemaakt om IE dwars te zitten, wat natuurlijk onzin is. Microsoft had jaren geleden al de IE browsers zo moeten aanpassen dat deze zich aan de standaarden hield, in plaats van brakke-html van heel erg slechte programmeurs te accepteren.
"... een complexe rendertest die aantoont of een browser aan de exacte html- en css-specificaties voldoet."

nee, de acid2-test is géén controle of een browsers daadwerkelijk aan standaards voldoet.
Enkel poogt het een aantal zeer tricky en weinig gebruikte properties, maar door de makers wél nuttig gevonden implementaties van specifiek de CSS 2.1 Recommendation (welke nog geen standaard is) uit te testen en kun je snel zien of deze ondersteund worden..

Overigens, de methode hiertoe is onder meer dat Acid2 totaal 'ilegale' CSS gebruikt, welke volgens de CSS-standaard gewoon netjes geignoreerd moeten worden (CSS is ook geen 'validerend' formaat ind e zin dat het verplicht is je CSS te valideren, een useragent moet echter gewoon niet herkende CSS ignoreren eigenlijk alhoewel het ook wel mogelijk is eigen 'proprietaire' properties te implemnteren zoals bv Mozilla doet met '-moz-'-prefix)
de CSS 2.1 Recommendation (welke nog geen standaard is)
Helaas, een "recommendation" is de laatste fase van een W3C document.
Zie ook: http://en.wikipedia.org/wiki/W3C_recommendation

Als het W3C iets een recommendation noemt is dat het equivalent voor een standaard.
Overigens, de methode hiertoe is onder meer dat Acid2 totaal 'ilegale' CSS gebruikt, welke volgens de CSS-standaard gewoon netjes geignoreerd moeten worden
idd.

als extra toelichting: de CSS standaard bevat ook regels hoe browsers moeten omgaan met ongeldige CSS code. De fallback-regels zijn nodig om in de toekomst nieuwe verbeteringen aan CSS toe te kunnen voegen.

Voor een css1 browser is " ul > li " bijvoorbeeld ongeldige syntax. Als daar geen fallback-regel voor is geeft zo'n css2 regel rare effecten in een css1 browser. Idem voor de overgang van css2 naar css3 natuurlijk.

Deze fallbacks test de acid2 test ook, en daarom valideert die pagina niet.

[Reactie gewijzigd door YaPP op 20 december 2007 09:46]

Ik was idd onvolledig, CSS2.11 is ook slechts 'Candidate Recommendation' (sinds 2004, laatste versie in juli 2007 uitgebracht) en nog geen officiele aanbeveling wat CSS2 wel is sinds 1998 al.

Wel is het zo dat W3C zelf nu eerder CSS 2.1 promoot dan 2, en de CSS2 Recommendation zelfs een beetje 'wegstopt'.
CSS2.1 is eigenlijk vooral een aanpassing op de bestaande fouten, onvolledigheden en zelfs problematische zaken in CSS2....

Het is dus ook goed om de specificatie en 'officiele standaard' niet als 'heilig' te zien,a angezien ook W3C zelf moet erkennen dat een voorlopig nog inofficiele 'candidate recommendation' CSS 2.1 eigelijk een hogere waarde heeft dat de 'officiele' recommendation CSS2.
CSS 2.1 is dan ook vooral een reactie op het feit dat bijna geen enkele browser de volledige CSS2 spec geimplementeerd heeft.

Feitelijk is CSS 2.1 een bugfix op de CSS2 standaard, waarbij men de niet geimplementeerde zaken gewoon verwijderd heeft.
Inderdaad, die hele ACID2-test kan me wat dat betreft gestolen worden. Geef me gewoon een browser die correcte CSS correct interpreteert, dan ben ik al heel blij.

Wat er met slechte CSS gebeurt interesseert me echt geen biet.
Was de Acid 2 test niet meer dan een test die bepaalde CSS elementen test en, misschien belangrijker, opzettelijk foutieve CSS code bevat om zo de correctie van een browser te testen?

Een betrouwbaardere test zou mijns insziens een zijn die alle mogelijke CSS en XHTML elementen en combinaties daarvan test - zou ik meer waarde aan hechten dan de nogal gespecialiseerde acid test.
De Acid2 test heeft uiteindelijk twee doelen, de eerste is om te kunnen testen of browsers in staat zijn om CSS2.1 te kunnen renderen - en dan als het even kan volledige. Verder worden er een aantal belangrijke HTML zaken getest (element-nesting e.d.)

Het tweede doel is om te testen of browsers verboden CSS constructies niet doorlaten, simpelweg omdat dit erg belangrijk is voor de verdere ontwikkeling van CSS. Als 1 browser alle verboden CSS doorlaat, kunnen we die ook niet meer gebruiken om nieuwe features in een volgende versie toe te voegen.

Verder is XHTML vooral een buzz-word, op dit moment is het best haalbare voor een breedt toe te passen website/webapp HTML. (Vanwege het feit dat MS in de afgelopen 7-10 jaar (!!!) nooit de moeite genomen heeft om fantsoenlijke ondersteuning voor XHTML in IE te bouwen). Alle andere fabrikanten van browsers hebben al minsten 5-7 jaar ondersteuning voor XML, maar goed als 80% van de gebruikers die programma's niet gebruiken...
XHTML is geen buzzword, het is gewoon niet ondersteund in zijn natuurlijke omgeving door MS IE. De reden hiervoor is behoorlijk achterlijk te noemen. De correcte mime-type en extensie zijn: application/xhtml+xml (application/xml of text/xml mag ook, maar liever niet) en .xhtml. MS IE snapt dit niet. Als je de text/html mime type gebruikt word XHTML (met de juiste doctype) wel in XHTML standards mode gerendered. Dus XHTML verpakt in een HTML jasje is "werkt".

En ik vind dat XHTML beter is dan HTML omdat het conform de XML standaard is die veel dingen makkelijker maakt (zoals eenvoudig vertalen naar een ander formaat dmv XSLT e.d.).
Als je de text/html mime type gebruikt word XHTML (met de juiste doctype) wel in XHTML standards mode gerendered. Dus XHTML verpakt in een HTML jasje is "werkt".
Nee, XHTML verstuurt als text/html wordt door elke browser gewoon als HTML behandeld. Er is no such thing als 'XHTML standards mode'; er zijn quirksmode, standards compliant mode en XML. De enige reden dat XHTML syntax 'werkt' in een HTML parser is het feit dat browsers HTML nooit als SGML applicatie hebben geimplementeerd, maar je moet niet denken dat syntax het enige verschil is tussen HTML en XHTML.

In feite biedt XHTML weinig tot geen voordelen voor gewone websites en is de draconische error-handling eerder een groot nadeel, dat is ook 1 van de redenen dat XHTML2 nauwelijks van de grond komt als opmaaktaal voor het web (dat, plus het feit dat het niet backwards compatible is), en dat er veel meer vertrouwen is in HTML5 (die overigens ook een XML-serialisatie zal kennen).
Ik heb helemaal niks gezegd over XHTML standards mode. Feit: veel browsers werken in standard mode (e.g. niet quirks) als de doctype gespecificeerd is. XHTML heeft een andere doctype HTML. De meeste browsers leggen meer vertrouwen in de doctype dan de mime-type wat betrefd standard compliant rendering. dus text/html + XHTML doctype word gewoon gerendered als XHTML, text/html zonder doctype is quirks. Idem voor application/xhtml+xml, maar vaak willen browsers nog wel eens controleren om XML correctheid, dit laaste word niet gedaan bij text/html.
Dus XHTML verpakt in text/html + xhtml doctype is standard compliant XHTML rendering zonder XML validation.

En dan XHTML weinig tot geen voordeel geeft voor gewone websites is jou mening en niet een feit.
De meeste browsers leggen meer vertrouwen in de doctype dan de mime-type wat betrefd standard compliant rendering.
XHTML als application/xml+xhtm behoeft niet eens een doctype aangezien 'quirksmode' alleen bestaat voor HTML ;) a/x+x wordt altijd gerendered in XML-mode (vermits de browser dat ondersteund).
dus text/html + XHTML doctype word gewoon gerendered als XHTML
Nee, het wordt behandeld als HTML in standards compliant rendering mode.
text/html zonder doctype is quirks. Idem voor application/xhtml+xml
Niet dus, XML rendermode kent geen quirks
maar vaak willen browsers nog wel eens controleren om XML correctheid
Dat is een vereiste voor een XML-application, maar je ziet veel UA's daar (tegen specificaties in) vanaf wijken (RSS parsers bijvoorbeeld) - blijkbaar is XML toch te lastig voor veel authors :P
Dus XHTML verpakt in text/html + xhtml doctype is standard compliant XHTML rendering zonder XML validation.
Nee dus, XHTML als text/html wordt behandeld als HTML door UA's, doctype is irrelevant hier (behalve dat een incomplete of incorrecte XHTML DTD ook quirksmode zal triggeren).
En dan XHTML weinig tot geen voordeel geeft voor gewone websites is jou mening en niet een feit.
Hier dan een paar feiten:

- het overgrote meerendeel van sites met een XHTML doctype wordt geserveerd als text/html (en heeft dus al geen voordeel van het 'XHTML-zijn', noch hebben ze het blijkbaar nodig)
- een groot deel van deze sites valideert niet
- een groot deel van deze sites is zelfs niet wellformed (en zou dus een parse error opleveren indien geserveerd als a/x+x)
- van de rest zal een deel van deze sites ook niet correct werken wanneer deze met een a/x+x mimetype geserveerd zou worden

Ergo: XML op het web is gewoon een fiasco. Het was een hype en heeft ook wel z'n nut in bepaalde situaties maar als simpele en mens-vriendelijke opmaaktaal is het gewoon niet geschikt...
Natuurlijk heeft XHTML ook zo zijn voordelen, maar voor het gebruik in de browser is HTML voorlopig voldoende. Dat betekend inderdaad wel dat je geen gebruik kan maken van het voordeel van XML (mixen van XML-talen). Maar op de client (browser) moet je eigenlijk toch geen XSLT gebruiken - je weet niet zeker of dit door de client ondersteund wordt en een browser moet wel (X)HTML ondersteunen...

Nu kun je op de server op basis van input XML (welke taal dan ook) toch wel XSLT gebruiken met als target HTML, dus een groot probleem is dit niet.

N.B. Pas als IE XHTML als XML ondersteund (de mimetype truc is niet zo verstandig namelijk, omdat XHTML dan als HTML (tagsoup) geparsed wordt) hoeven ze van mij het application/xhtml+xml mimetype te ondersteunen...
Accept-header base mimetype switching is vaak ook een wassen neus. In de eerste plaats ga je er dan eigenlijk abusievelijk van uit dat het verschil niets meer is dan de syntax (en als je site gewoon goed werkt onder text/html why bother?), maar er zijn ook een aantal pitfalls waar bijna nooit aan gedacht wordt, bijvoorbeeld het respecteren van q-values en het sturen van Vary headers (ivm cacheing proxies).
Voor mij gaat het niet om de technische kant;
De eisen van Europa om applicaties als de mediaplayer en de browser buiten het OS te houden werpt vruchten af.
De concurrentie met krachtige slanke operating systems passend bij snelle VM apps is de richting die MS op gaat.
In mijn ogen gaat het niet eens meer om passend bij Vista, maar als opzet voor verderweg
'Het belangrijkste is interoperabiliteit', aldus Hachamovitch. 'Als ontwikkelaar wil ik liever niet elke website meerdere keer ontwikkelen voor meerdere browser. Ons doel bij IE8 is de juiste set standaarden te ondersteunen zonder het huidige web tekort te doen.'
Bah, dit vind ik een smerige uitspraak. Microsoft heeft intentioneel al een hele tijd gehoopt dat zij de touwtjes in handen zouden krijgen door de pet naar W3C te gooien, en html en css stukje bij beetje naar eigen hand te draaien.
Maar nu bijna de halve wereld bezig is met een echte browser (nl. FireFox, Safari en Opera) zeggen ze opeens dat het altijd hun doelstelling is geweest.

Ik maak al jaren websites en zodra ik CSS wil gebruiken mag ik meestal een aparte stylesheet aanmaken voor MsIE... eentje die niet voor een andere browser werkt.

###Edit: Trouwens er zit een typo in de quoted tekst; "browser" moet volgens mij "browsers" worden.

[Reactie gewijzigd door simen op 20 december 2007 09:29]

Hoezo smerig.... Ik kan me niet voorstellen dat dit door dezelfde persoon binnen Microsoft gezegt en gedaan is. Vergeet niet hoe veel mensen er werken bij Microsoft. Strategische beslissingen worden ergens anders gedaan dan technische beslissingen. Ook zit er een flink aantal jaar tussen, grote kans dat het team uit compleet andere mensen bestaat. Daarnaast is Microsoft niet de enige die proprietaire functies in hun browser heeft geplaatst.
Maar nu bijna de halve wereld bezig is met een echte browser (nl. FireFox, Safari en Opera) zeggen ze opeens dat het altijd hun doelstelling is geweest.
Waarschijnlijk klopt dat ook wel, alleen hebben ze er een relatief lage prioriteit aan gegeven. Een opmerking als deze is zo gemaakt, aangezien de doelstellingen, eisen en wensen voor een browser redelijk snel af zijn in vergelijking met de daadwerkelijke uitvoering daarvan.
Is goed nieuws voor de webdesigners die klagen over het niet compatible zijn van IE. Zal het bouwen van een site een hoop irritatie en tijd schelen. :)
Ik begrijp echt niet waarom iedereen zo loopt te klagen over incompatibiliteit van IE7. Zolang je erg kritsch bent in je manier van werken (zorgvuldig) hoef je je nergens zorgen om te maken. Uiteraard heb je altijd iets verloop, maar buiten dat kan je heel goed ontwerpen zonder dat er al teveel verschil in je werk optreedt.

Mag ik het verwend gedrag noemen om maar lukraak code in je css te gooien, zonder echt moeite te doen om deze netjes en geordend te houden of rekening te houden met de verschillen in de browsers?
of rekening te houden met de verschillen in de browsers?
Deze laatste zinsnede nekt helaas je hele betoog. Uiteraard is netjes werken erg belangrijk. Maar als de ontwikkelaars van de grootste browser ter wereld (qua gebruikersaantallen en ik gok ook qua codebase :P) het belangrijk genoeg hadden gevonden om zich aan de standaarden te houden, dan zouden honderdduizenden web-ontwikkelaars ter wereld veel minder rekening hoeven te houden met de verschillden tussen IE en de rest van browserland.

MS stelt echter andere prioriteiten die in het verleden vaak juist lijnrecht tegenover compatibiliteit stonden. Compatibiliteit geeft mensen keuzes, iets wat niet in het belang van een (semi) monopolist is. De inhaalslag van IE8 komt erg laat en onder grote druk van buitenaf.
Ik mag denk ik best vinden dat IE7 een voortborduursel is op een serie van ondermaats presterende producten. En als ik voor mijn werk gewoon tijd kwijt ben om iets in Internet Explorer 7 werkend te krijgen omdat ze bepaalde standaarden slecht hebben geimplementeerd of geïnterpreteerd (wat eigenlijk een groter probleem is), vind ik dat ik ook terecht mag klagen. De klant betaalt uiteindelijk meer voor dezelfde website.

Microsoft heeft veel goede dingen gedaan, maar door niet voldoende te ontwikkelen aan Internet Explorer 6 en 7 is de hele vooruitgang voor client-side developers bijna tot een stilstand gekomen.

Er is een hoop te voorkomen door handig te zijn in het schrijven van HTML/CSS, maar dan zul je nog steeds voor Internet Explorer de rommel op moeten ruimen. En dat is jammer.

Alle zaken die nu worden ontwikkeld, worden pas vanaf 2010 écht bruikbaar, en blijven tot pakweg 2013 aanwezig genoeg om rekening mee te houden. Dan heb ik dus liever dat ze nu een halfjaartje uittrekken om IE8 écht goed te krijgen.
Hoe verklaar je bij een klant dat jij de site die je hebt gemaakt zonder extra werk (en kosten) niet goed functioneert op een browser die bij 80/95% van de gebruikers op de pc staat? Een normaal mens (dus geen IT-er) zal zeggen bouw die site maar voor IE en dan kijken we wel of aanpassingen voor de mensen die geen IE hebben het geld waard zijn. En als je je daar te goed voor voelt zijn er tig anderen die het wel doen.
Wij krijgen gewoon een aanvraag voor een website. Standaard ondersteunen we Firefox 2.x en Internet Explorer 6.x en hoger. Daarbij is in de prijs inbegrepen dat er speciaal voor Internet Explorer aanpassingen moeten worden gedaan. Ontwikkelen in Firefox gaat namelijk veel sneller en beter doordat je goede extensies kunt gebruiken die je erbij helpen, zoals Firebug en de Developer Toolbar.
Maar uiteindelijk betaalt de klant wel meer dan nodig zou moeten zijn. Dat gaan we er natuurlijk niet bij vermelden, want dat betaalt de klant overal.

Ik zeg niet dat ik te goed ben om voor Internet Explorer fixes te gaan doen. Het is wel jammer dat het nodig is. En dat haast iedereen in dit vak dat moet doen. En dat we daarbij maar elke keer mogen uitleggen hoe het nou zit met browsers enzo. Internet Explorer kost het bedrijfsleven veel geld, als je alles even bij elkaar optelt.
Helemaal mee eens. Ik heb meegeklust aan een aantal behoorlijk grote sites en IE kost steeds extra tijd. Je hebt in FF en Opera voor elkaar wat je wilt, zoals je had gedacht dat het zou moeten, in bijv één uur en dan moet je daarna nog anderhalf uur klooien om het ook goed te krijgen in IE. Zonde geld!
As wu d markt is vorstlln als mnsn die sow typuh as ik nu doe aan duh ene knt en mensen die normaal typen aan de andere kant. As juh nr de jeugt van techenwrdig kijkt sie ju gouw dah ze veul sow typhu en das ni eg komptbl me de nl taal sowals ie algemn bknd ge8 wordt. Juh ken di gwn axeptere want ht is tu leze tog!?!???!???!?????!/1/? Maar je moet er geen sollicitatiebrief mee schrijven. K find ut eiguluk nie gek da die andere brwsrs di ni knne of gwn weigere tu leze. Net als in de Nederlandse taal zijn de regels niet voor niets vastgelegd, zodat de 'compatibiliteit' tussen mensen gegarandeerd blijft. Ik snap niet waarom dat bij browsers anders zou moeten zijn, zeker omdat de regels er liggen.
Ik weet niet of jij ooit gedesignd hebt, maar je 'kritisch zijn in je manier van werken' werkt alleen bij simpele sites met 2 kleurtjes en wat tekst zonder opmaak. Als je wat complexere dingen wilt gaan bouwen kom je gewoon keihard in de problemen. Om je standpunt verder onderuit te halen (of te verdedigen, het is aan jou) daag ik je uit de Tweakers.net frontpage om te schrijven in een pagina zonder hacks, die op 'alle' browsers goed werkt (IE6, IE7, Firefox, Opera en Safari).
Ik begrijp echt niet waarom iedereen zo loopt te klagen over incompatibiliteit van IE7. Zolang je erg kritsch bent in je manier van werken (zorgvuldig) hoef je je nergens zorgen om te maken. Uiteraard heb je altijd iets verloop, maar buiten dat kan je heel goed ontwerpen zonder dat er al teveel verschil in je werk optreedt.
En als je nou dusdanig kritisch bent op je eigen werk dat een klein verschil je ook ontevreden laat over het werk? Verschillen die ontstaan door het niet juist interpreteren van css?
Natuurlijk niet, je zal gedurende X jaar nog altijd de oudere versie moeten onderstuenen. NIet iedereen gaat immers direct over (neem alleen bedrijven maar) want ook nu zijn er enorm veel XP machines die nog gewoon IE6 draaien.
En komt IE8 wel voor XP uit? Misschien is het Vista exclusief...
Goed punt. Maar het lijkt me logisch van wel. Er zijn simpelweg teveel XP machines om te negeren en MS is nu eenmaal in een flinke browseroorlog met Firefox verwikkeld.
Zo dom is zelfs Steve Ballmer niet.
Ahnee? Hoe verklaar je dan dat ze bijvoorbeeld DirectX 10 enkel voor Vista uitbrachten? Waarschijnlijk zullen ze wachten op een of andere opvolger van Vista om het te releasen en dan gewoon een "security update" uitbrengen voor Vista: IE8.

Nu, ik blijf waar ik al meer dan een jaar gelukkig vertoef: Ubuntu ;)
voor dx10 zijn logische beperkingen, het driver model van xp ondersteund het gewoon niet.
IE is echter toch iets simpeler, en wat MS ook zegt, staat het vrij los van windows.
@Countess: onzin. Onder wine op linux kan ik ook een heleboel DX spellen draaien tegenwoordig (al dan niet met bugs), maar het drivermodel is toch fundamenteel anders dan die van windows. DX is gewoon een API, en hoe het systeem die API-calls afhandelt maakt voor de applicatie die het gebruikt niks uit. Ze hadden makkelijk DX10 voor XP uit kunnen brengen, maar omdat toch iedereen windows draait voor de games, en ze Vista willen pushen, pakken ze gewoon die games als speerpunt om mensen naar vista te forceren.
Jups, zoals bij mij. Ik kan niet meer naar linux booten en in windows heb ik gewoon FF. :D Te lui om alle updates uit te voeren. (Nu kwam dat afgelopen dagen goed uit omdat ik een flash klus had maargoed).

En vet stoer natuurlijk dat IE8 daar doorheen komt. :S Moeten we IE8 nu allemaal stoer gaan vinden? Laat eerst maar eens die testversie komen. Van IE7 werd IK persoonlijk ook niet gelukkig van. :-) Heb het wel geprobeerd ja.
Heeft niks met stoer doen te maken maar ik denk dat het toch wel nieuwswaardig dat de meestgebruikte browser zich nu aan de standaarden gaat houden terwijl MS er juist bekend om staat dit niet te doen.
Duh!! Je meent het? Natuurlijk gaat niet iedereen direct over naar IE8. Maar is het daardoor geen goed nieuws voor webdesigners? Ik en mijn collega's zijn in iedergeval heel blij met deze stap.

De sites die nu draaien zijn over een paar jaar toch verouderd. Dus voor iedereen die volgend jaar een site maakt kan al gaan kijken of hij de IE hacks kan weglaten. Daarnaast kun je als designer ook de gebruiker een beetje opvoeden door bepaalde sites niet of minder compatible met IE<8 te houden en ze het advies te geven met IE8 aan de slag te gaan. Zolang de klantjes niet wegblijven natuurlijk.
Probleem is dat in het begin weinig mensen nog IE8 zullen gebruiken.
Veel mensen met weinig computer kennis hebben nog pc's met WinXP en IE6, waardoor sommige sites slecht afgebeeld worden.
Website bouwers zullen nog een lange tijd hacks moeten maken voor die oudere versies.
Of gewoon lui zijn en aangeven dat als de site er niet juist uitziet ze IE8 of een alternatief moeten downloaden.
Als amateur-website-maker vind ik het woord 'lui' in deze toch wel slecht gekozen. Als je een website vandaag de dag maakt die toch een beetje de mogelijkheden van de hedendaagse recommendations gebruikt en tegelijkertijd deze website zo moet bouwen dat een oudere browser (IE6 en misschien zelfs IE 5.5) de website tenminste basic weergeeft, dan ben je eigenlijk beter af dat je twee verschillende pagina's maakt met een JS-check op elke pagina. Ofwel maak je je website volledig in Flash natuurlijk (NOT!)

Persoonlijk vind ik het dan netter om de bezoeker er attent op te maken dat hij of zij met verouderde software werkt en links te voorzien naar de downloadpagina's van firefox, opera en windowsupdate. Zo doe je de bezoeker een plezier en tegelijkertijd ook vele mede-website-makers.
Idd, op sites van klanten doe ik dit niet.... Maar op mijn eigen sites wel, gewoon de melding: Uw browser is niet meer up to date als er weer een IE6er langs komt. Hoe eerder mensen overstappen op IE7 of Firefox hoe beter. Mijn eigen sites zijn dan ook niet langer IE6 compatible, ik heb al geen zin om veel tijd te besteden aan mijn eigen portfolio en om dan ook nog eens te gaan kloten met IE6 hacks is zonde van mijn tijd. De gebruiker stapt maar over. Het leuke is, volgens mijn statistiek download 1/2 van de IE6 gebruikers IE7 of Firefox, dus het werkt wel.

Wat het probleem is.... Mensen weten soms niet eens dat er voor Internet Explorer updates zijn of alternatieven, ze denken dat het een onderdeel van windows is.
Nou dat werd ook eens tijd. :)

Goddank maakt MS eindelijk een browser die aan de standaarden voldoet, dan hoeven we eindelijk geen hacks meer te gebruiken om alles werkend te krijgen in alle browsers (wat trouwens al redelijk verbeterd was in IE7).
Idd, dit werk tijd. Dit gaat idd veel tijd besparen bij het maken van een website. Geen vieze css hacks meer om uw site te doen werken in ie!
Nu moet alleen de acid2 test nog volledig door de w3c standaard komen ;)

1 Warning... "No Character Encoding Found!"

http://validator.w3.org/c...29&doctype=Inline&group=0

MS is goed op weg zo!

[Reactie gewijzigd door airell op 20 december 2007 09:45]

De Acid2 test is met opzet niet conform de standaard. Dit komt omdat er ook getest word op de fout afhandeling zoals die in de CSS2 standaard gedefineerd is. HTML heeft geen stricte fout afhandeling definitie, XHTML weer wel (side-effect van XML) maar die is dan weer niet "vriendelijk".
'Als ontwikkelaar wil ik liever niet elke website meerdere keer ontwikkelen voor meerdere browser. Ons doel bij IE8 is de juiste set standaarden te ondersteunen zonder het huidige web tekort te doen.'
De juiste set????

vind dit toch wel een bedenkelijke uitspraak, ik wist niet dat er discussie over was. Of beter gezegd, wat is er moeilijk aan het bepalen van de juiste set, W3C standaarden lijken me gewoon bekend.
The important thing about the Acid2 test is that it reflects what one particular group of smart people “consider most important for the future of the web.”
one particular group of smart people.... Ik heb een heel sterk idee waar dit heen gaat (nog steeds websites bouwen voor FF dus en blijven hacken voor IE.

[Reactie gewijzigd door thekip op 20 december 2007 09:41]

Klopt wel, als je nagaat dat de tegenstanders van IE in 99% van de gevallen verwijzen naar de Acid 2 test als ze het hebben over ondersteuning van webstandaarden in vergelijkingen tussen de verschillende browsers. Die mensen kunnen ze hiermee stil krijgen. De Acid 2 test mag dan niet eens zo bepalend zijn voor de uiteindelijke kwaliteit van een browser, maar het is zeker wel een psychologische mijlpaal.
En die standaarden zijn een set standaarden.

XHTML 1.0, 1.1, CSS1, 2, 2.1, etc. :) dat samen is toch echt een set.
x-html is ook niet echt een goed standaard voor webpagina.
Gebruikt van XML impliceert dat een compleet document moet worden afgekeurd als er 1 element niet correct volgens het XML schema is

(ongeacht hoe belangrijk dat xml element is voor het tonen van de inhoud van het document).

Volledige x-html ondersteuning zou een enorme extra belasting betekenen voor webbouwers en website testers.
Inderdaad, alles moet valideren. Een CMS met input van de gebruiker moet een validerende pagina opleveren. Alle user input moet je dus parsen, nakijken op fouten en corrigeren waar nodig. Parsen, valideren en corrigeren en ervoor zorgen dat wat de gebruiker wil ook weer wordt uitgespuugd naar de browser. Ik blijf bij html, kan hetzelfde en meer door niet YSOD te geven.
Goh, de meeste reacties hier zijn weer voorspelbaar vandaag :O , nu ineens is Acid2 weer onzinnig/niet representatief of heeft Microsoft een truc uitgehaald |:(

Het is inderdaad wel een ander verhaal natuurlijk gezien de geschiedenis van IE, maar dan nog.. wees blij of gebruik gewoon wat anders 8)7
Voor zover ik weet loopt de discussie over de zinnigheid van die acid2 test bij ieder nieuwsitem waar die test in wordt genoemd. Het staat dus altijd ter discussie ongeacht over welke browser het eigenlijke bericht gaat. Zoals je hier boven al kunt zien aan de diverse mensen die het proberen uit te leggen ook geen overbodige luxe aangezien er maar weinig mensen zijn die begrijpen wat de acid2 test is en waarom het er is.
wees blij of gebruik gewoon wat anders 8)7
Als developer heb je niet de keuze welke browser je gebruikers gebruiken. Feit is wel dat je je werk bijna dubbel moet doen omdat IE niet hetzelfde rendert als bijv. FF.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True