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 , , 86 reacties

Microsoft heeft de eerste bètaversie van Internet Explorer 8 aan een beperkte groep testers verstrekt. De eerste bèta zou op een later tijdstip voor het grote publiek beschikbaar worden gemaakt.

Internet Explorer 7 logo (90 pix)De 'Technical Beta' van Internet Explorer 8 kan alleen op uitnodiging van Microsoft getest worden. Het bedrijf richt zich met de test op een geselecteerde groep developers, die de eerste bugs uit IE8 zouden moeten halen. Volgens Microsoft wordt de bèta op een later tijdstip ook voor het grote publiek uitgebracht, maar het is niet bekend wanneer dat zou gebeuren.

IE8 zou zich volgens de ontwikkelaars beter dan zijn voorganger aan de webstandaarden houden. Eind vorig jaar slaagde een interne versie van IE8 bijvoorbeeld voor de Acid2-rendertest, waarmee wordt gecontroleerd of een browser zich aan de html- en css-standaarden houdt. Zdnet verwacht dat Microsoft tijdens de Mix-conferentie, dat van 5 tot en met 7 maart in Las Vegas gehouden wordt, meer informatie over IE8 bekend zal maken.

Moderatie-faq Wijzig weergave

Reacties (86)

Vooralsnog zie ik geen aanwijzigingen dat IE8 echt voor de ACID2 test zal slagen. De voorwaarde is namelijk dat de ACID2 test wordt aangepast zodat IE8 slaagt.

Aangezien dat het hele doel van de test teniet doet (browsers dienen zich aan te passen aan standaarden/tests en niet andersom) lijkt het me stug dat IE8 ooit zal slagen voor ACID2 zolang MS weigert een browser te maken die voor de test slaagt.
ongelofelijk, Safari voor Windows slaagt compleet voor de ACID2, Opera haalt hem ook.
Firefox faalt wat dat betreft best wel, de ogen zitten niet eens op hun plaats.
Flock faalt eveneens, nog erger dan Firefox (tja, wat wil je met een FF kernel:P)
En IE7 verkloot hem gigantisch zodat zelfs het bolletje niet meer te zien is.
Firefox 3 slaagt ook voor Acid2. Het probleem dat Firefox had is dat Acid2 uitkwam op zo ongeveer het slechtst mogelijke moment, midden in de betafase van Firefox 2 zodat er niet meer genoeg gesleuteld kon worden om hem nog te laten passeren. De development versions van Firefox 3 slagen inmiddels al iets van een jaar voor Acid2 en haalt op dit moment 67% van de Acid3
...haalt op dit moment 67% van de Acid3
Dat verschilt dan ook per installatie. Ik krijg Acid 3 niet verder dan 59%.
browsers dienen zich aan te passen aan standaarden/tests en niet andersom
Dat is niet zoals het in het verleden ging, toen maakten Microsoft en Netscape hun eigen standaarden en jaren later werd er iets een "offciele" standaard. Het probleem met standaard organisaties en zeker die zich met het web bezig houden is dat ze vaak achter de feiten aan hollen.

Een browser moet gewoon zoveel mogelijk sites goed renderen, de standaard is daarbij niet meer dan een richtlijn.
Dat is niet zoals het in het verleden ging, toen maakten Microsoft en Netscape hun eigen standaarden en jaren later werd er iets een "offciele" standaard.
Ze hadden inderdaad hun eigen 'standaarden', het W3C is toen opgericht omdat dit een chaos werd. Ook MS is al jarenlang lid van het W3C...
Het probleem met standaard organisaties en zeker die zich met het web bezig houden is dat ze vaak achter de feiten aan hollen.
De CSS2 specificatie stamt uit 1998 en is dus al 10 jaar (!) oud. HTML 4.01 is van 1999... Momenteel is men bezig met CSS3 en HTML5, ook daar valt voor MS nog genoeg te implementeren. Dan hebben we het nog niet eens over SVG, MathML, XHTML, JS2 en DOM, ook daar loopt IE nou niet bepaald voorop. De enige die zich moet schamen voor 'achter de feiten aan hollen' is MS met het stilleggen van de IE-ontwikkeling (en daarbij die van het internet) van 2001-2006.

[Reactie gewijzigd door JanDM op 27 februari 2008 14:36]

Standaard fout... De CSS2 is 10 jaar geleden gelanceerd, maar dat was alleen maar een suggestie voor een nieuwe standaard, waar iedereen op kon reageren. Pas vanaf februari 2004 is het een candidate recommendation, hetgeen dus de status van een release candidate bij software heeft. Nog steeds niet echt definitief dus.

Om even CCS2.1 te quoten:
This is a W3C Candidate Recommendation, which means the specification has been widely reviewed and W3C recommends that it be implemented. It will remain Candidate Recommendation at least until 20 December 2007.
Je moet W3 recommendations niet verwarren met bijvoorbeeld ISO standaarden. Wanneer een W3 recommendation voor het eerst op het web verschijnt, dan is dat gewoon een working draft. Dat wordt dan bijgewerkt, en steeds stabieler. Het duurt gigantische lang voordat het definitief is.
CSS2 is wel degelijk een recommendation vanaf 1998, maar implementatieproblemen en errata in deze specificatie hebben geleid tot een vernieuwde revisie, CSS2.1, welke inderdaad nog CR status heeft.
Sterker nog, het wordt pas definitief als er 2 volledige implementaties in browsers zijn. Als men dus blijft wachten tot het een recommendation wordt, dan zal het dat nooit worden.
Kan je een link geven waar we dit kunnen nalezen?
http://blogs.msdn.com/ie/...ompatibility-and-ie8.aspx

Standaard rendered IE8 net zo als IE7, alleen als je een speciale tag toevoegt gaat ie naar een soort 'super standards mode'. Dit is uiteraard een heel slecht idee en MS heeft ook de nodige kritiek hier op gehad (niet dat ze wat met die kritiek doen ofzo).
Ze hebber er ook ondersteuning voor gekregen.
Zo zijn bijvoorbeeld verschillende leden van het web standards project (degenen die de ACID test maken) behoorlijk positief over deze methode.
De maker van de Acid tests, Ian Hickson, zegt er het volgende over:
If Web authors actually use this feature, and if IE doesn't keep losing market share, then eventually this will cause serious problems for IE's competitors — instead of just having to contend with reverse-engineering IE's quirks mode and making the specs compatible with IE's standards mode, the other browser vendors are going to have to reverse engineer every major IE browser version, and end up implementing these same bug modes themselves. It might actually be quite an effective way of dramatically increasing the costs of entering or competing in the browser market. (This is what we call "anti-competitive", or "evil".)

http://ln.hixie.ch/?start=1201080691&count=1
Weinig ondersteuning in te lezen...

[Reactie gewijzigd door Maurits van Baerle op 27 februari 2008 18:21]

'behoorlijk positief' zou ik niet willen zeggen, hooguit dat sommigen het als een noodzaak zien (hetgeen ik niet van mening ben). De verdeeldheid binnen WaSP omtrent de versioning switch is net zo groot als binnen de gehele webdevelopment community...
Ik hoop dat ze nu eindelijk het content type "application/xhtml+xml" gaan ondersteunen. Ik vind het echt belachelijk dat ik voor Internet Explorer alleen een uitzondering moet maken wat dit betreft.
Zoals het er nu uitziet zal ook IE8 geen ondersteuning hebben voor XHTML. Hetgeen inderdaad jammer is, omdat je dan niet een combinatie kunt maken van bijvoorbeeld XHTML en SVG.

Nu ondersteund IE8 vziw ook geen SVG of MathML en zolang men die toch niet ondersteund is XHTML ondersteuning ook niet direct een issue.

Ik hoop overigens wel dat men bij MS ook aan ondersteuning voor XVG en MathML gaat werken, want dit wordt toch steeds belangrijker voor het hedendaagse web.

En kom nu niet aan met silver/moonlicht, want dat is geen open standaard die je vrij kunt implementeren - en dat heb je dus wel met SVG en MathML...
Een belangrijke wijziging in deze versie is het version-targeting-systeem. Er kan in de (x)html-code aangegeven worden voor welke browser de code gemaakt is. Dit heft voor- en nadelen, maar in theorie zou IE40 een pagina nog steeds goed weer moeten geven als dat IE8 of 7 doet, als je hem voor IE7 gebouwd hebt en getarget hebt.

[Reactie gewijzigd door Rixard op 27 februari 2008 13:37]

Persoonlijk vind ik het belachelijk. Hier heeft W3C toch de DOCTYPE voor uitgevonden? Waarom een Microsoft-only element ernaast?
Het doctype type zegt iets alleen iets over het document.
De useragent tag zegt iets over de browser versie waarmee de sitebouwer weet dat de site correct werkt.

Erg handig voor sitebouwers.
Je test een site voortaan nog maar in 1 IE versie en zet die in je useragent tag.
Alle latere IE versies zullen de site zo blijven renderen als jij hem origineel getest hebt. Precies wat je als webontwikkelaar wil. Dat de site er zo uitziet als jij wilt.
De useragent tag zegt iets over de browser versie waarmee de sitebouwer weet dat de site correct werkt.
De UserAgent is een HTTP Header en geen tag, maar dat ter zijde.

Persoonlijk vind ik de useragent echter niet zo heel erg belangrijk. Als webdesigner zou je mijns inziens primair de officiele standaard moeten volgen, voldoet deze niet dan hoor je -nog steeds naar mijn mening- een (non-standaard) oplossing te kiezen, waar de browserfabrikanten het onderling wel over eens zijn (geworden) - bijvoorbeeld XMLHttpRequest, dat door Microsoft uitgevonden is. Als laatste kun je dan een browser-specifieke oplossing kiezen.

Verder horen browsers eigenlijk altijd de officiele standaard te volgen, zodra deze er is. Als de browser-release trend zich blijft ontwikkelen zoals dat nu gebeurt, heb je als gebruiker en webontwikkelaar dus altijd binnen 2 jaar de mogelijkheid om op die standaard over te gaan.
Je test een site voortaan nog maar in 1 IE versie en zet die in je useragent tag.
Wat jij hier dus consequent 'useragent tag' noemt, dat is de 'X-UA-Compatible' HTTP-Header die je kunt gebruiken (eventueel via het meta-element).

Dat lijkt een mooie uitvinding, maar ik heb liever dat men als bedrijf de standaard gelijk goed implementeerd. En als men al de noodzaak voor zo'n switch ziet dit op client nivo regelt (of centraal via Active Directory oid bij bedrijven). De enige reden voor zo'n switch zijn namelijk de oude intranet sites...

Verder hoort men als default de standaard te volgen en zo'n switch te gebruiken om naar een oude (vaak buggy of non-standaard oplossing) over te gaan - wat men nu doet is m.i. net de verkeerde kant op denken...

Het idee dat deze switch voorkomt dat bestaande sites netjes blijven werken (met de render bugs dus) is verder slecht ten dele waar. Men heeft de compatibiliteit namelijk reeds 'gebroken' met IE7 - als een site niet meer onderhouden wordt en zich helemaal naar IE6 aangepast heeft zal deze toch nooit meer correct renderen...
Beetje kortzichtig, want je argument geldt alleen voor Microsoft browsers. Voor andere browser bouwers blijft het gissen naar hoe verschillende IE versies pagina's renderen. Firefox en Opera kunnen bijvoorbeeld nooit een rendermethode voor IE6 inbouwen, omdat dit een closed source product is. Omgekeerd kan Microsoft wel de rendermethode van Firefox 2.0 inbouwen in IE8.

Als alle browser bouwers zich gewoon fatsoenlijk aan hun eigen standaarden zouden houden (Microsoft is ook lid van W3C!) dan zou zo'n nieuwe tag helemaal niet nodig zijn. De enige reden dat die tag is ingevoerd is dat Microsoft niet de bouwers die hun site net voor IE7 hebben geoptimaliseerd nog eens voor het hoofd wil stoten. IE8 rendert sites daarom ook standaard volgens IE7, tenzij je die extra tag neerzet om aan te geven dat de IE8 renderengine gebruikt moet worden.
Je kijkt verkeerd om.
De useragent tag is voor de sitebouwer.

Als een sitebouwer wil dat zijn site er in alle versies van Mozilla goed uitziet dan moet hij alle versies testen omdat Mozilla in FF deze useragent tag (nog) niet ondersteunt. (De useragent tag kan ook info over andere browsers bevatten)

Voor IE hoeft hij dat straks dus niet meer te doen.

Verder bestaat er geen situatie dat alle browsers aan dezelfde standaarden voldoen. En ook FF, Safari en Opera zijn bepaald niet 100% standaard complient (al zijn ze mogelijk veel beter dan IE). Dus nieuwere versies van deze browsers zullen de huidige standaarden vermoedelijk beter implementeren en ook nieuwe standaarden (CSS3, MathML3, HTML5) langzamerhand gaan implementeren. Er is dus elke keer verschil in versies ook bij FF en Opera en dan is het als sitebouwer dus handig als je toch precies weet hoe een browsers je site zullen renderen ook als er een nieuwe versie uitkomt.

[Reactie gewijzigd door 80466 op 27 februari 2008 14:10]

(zoals ik al aangegeven heb zie ik niets in de UA-Compatible HTTP Header, zie mijn andere reactie hierover :) )
Als een sitebouwer wil dat zijn site er in alle versies van Mozilla goed uitziet dan moet hij alle versies testen
Je gaat er dan wel vanuit dat er grote vershillen zijn bij de diverse versies van Firefox. Dat is echter niet het geval. Zo zijn bijvoorbeeld de render-engine (Gecko 1.8) van Fx 1.5 en 2.0 dezelfde, en zijn de verschillen tussen Gecko 1.7, 1.8 en zelfs 1.9 qua HTML/CSS2 ondersteuning helemaal niet zo groot als de verschillen tussen bijvoorbeeld IE6,7 en 8.

Voor Fx is er dus, op dit moment, helemaal geen noodzaak voor een switch die aangeeft welke render-engine bedoelt is - verder heb ik niets aan de switch als de engine zelf niet aanwezig is. (Bijvoorbeeld: Ik target IE6, maar er is geen IE6 render-engine aanwezig - en dan?)
Voor IE hoeft hij dat straks dus niet meer te doen.
Dat is dus slechts ten dele waar, tenzij alle render-engines die er zijn van IE met de volgende IE versie meegelevert zal gaan worden...
Dus nieuwere versies van deze browsers zullen de huidige standaarden vermoedelijk beter implementeren en ook nieuwe standaarden (CSS3, MathML3, HTML5) langzamerhand gaan implementeren. Er is dus elke keer verschil in versies ook bij FF en Opera en dan is het als sitebouwer dus handig als je toch precies weet hoe een browsers je site zullen renderen ook als er een nieuwe versie uitkomt.
Op dit moment is de ondersteuning voor de diverse W3C/ECMA standaarden in Safari, Opera en Fx voor meer dan 95-99% correct, de kans dat er dus op dat niveau iets omvalt is zo klein dat daar (mijns inziens) geen switch voor nodig is.

Nieuwe standaarden, zoals CSS3, MathML3 en HTML5 hebben vziw geen impact op oude - deze hebben dan ook geen invloed op de rendering van een bestaande website.

Als ik dus een HTML4/CSS2/JS1.5 website maak dan zal deze er in Fx 4.0 hetzelfde uitzien als in Fx1.5 - omdat HTML5, CSS3 en JS2.0 compatible zijn met hun voorgangers...

Als ik expliciet een HTML5 site bouw dan kan een oude browser deze toch niet correct renderen - wat heb ik dan aan een versie-switch die aangeeft dat ik IE9 nodig heb terwijl op mijn computer ie8 staat?
Op dit moment is de ondersteuning voor de diverse W3C/ECMA standaarden in Safari, Opera en Fx voor meer dan 95-99% correct, de kans dat er dus op dat niveau iets omvalt is zo klein dat daar (mijns inziens) geen switch voor nodig is.
De exacte mate van ondersteuning is moeilijk te meten.
De ondersteuning voor HTML/XHTML, DOM levels en CSS2.1 in FF en Opera ligt zo tussen de 80% en 95% als je kijkt naar de ondersteuning gvan de individuele spec elementen. Zeker niet in de buurt van de 99%.

Zo ligt de ondersteuning voor HTML 4.01 elementen bij
IE6 op 80% IE7 op 81% , FF2 op92% en opera op 86%
(met name de CSS ondersteuning ligt bij IE lager dan bij de anderen)
Die cijfers zeggen niet alles want als je hele obscure elementen niet ondersteunt dan heeft dat minder effect dan dat je populaire elementen niet ondersteunt.

Veel mensen hebben geen idee wat voor effect het zou hebben als alle browser echt 100% compliant zouden worden. Een voorbeeld:

Stel dat bijvoorbeeld IE, FF en opera bij het veelgebruikte "target" element voortaan unreserved words beginnend met een underscore gaan ignoren (dat zou moeten als de standaard correct werd gehanteerd) dan kunnen heel wat navigatie elementen op sites gaan breken.

Dat is dus betere standaards ondersteuning maar stapels sites gaan er kapot aan en daarom worden dit niet door IE maar ook niet door FF en Opera ingevoerd.
Je kunt dat echter voortaan wel doen met deze methode omdat de sitebouwer er dan expliciet voor gekozen heeft.

[Reactie gewijzigd door 80466 op 27 februari 2008 17:39]

Veel mensen hebben geen idee wat voor effect het zou hebben als alle browser echt 100% compliant zouden worden.
100% compliant met wat? HTML4.01 bijvoorbeeld? Dan krijg je leuke bijverschijnselen bij XHTML geserveerd als text/html :P

Feit is dat HTML4 natuurlijk verouderd is en HTML5 zo opgezet wordt dat het ook meer matched met real-world usecases. Je voorbeeld mbt target-names is in HTML5 dan ook aangepast: non-reserved names beginnend met een underscore zijn daar nog steeds non-conformant, maar useragents moeten ze wel kunnen verwerken. (note overigens dat in HTML4.01 mbt het negeren een SHOULD-directive wordt gebruikt en geen MUST).

Kortom: standaarden (of specificaties of aanbevelingen of whatever) zijn geen wetten in steen. Als er goede redenen zijn om iets op een ander manier te implementeren dan kan dat ook een goede reden zijn om op dat punt de standaard aan te passen. Als iedereen daarin samenwerkt is een 100% compliance ineens een stuk haalbaarder. Punt is echter dat MS telkens de kont tegen de krib gooit en dingen toch weer op een eigen manier doet om redenen die enkel voor hun relevant zijn maar nadelig zijn voor de webstandaarden en de adoptie daarvan in het algemeen. Daarbij zijn ze ook zo koppig om niet in samenwerking met anderen te kijken naar betere oplossingen...
@hAl:
Wat gaat er nu gebeuren als een pagina alleen IE7 ondersteunt met de render-tag? Hoe moet Firefox dat gaan renderen? Hoe moet Firefox überhaubt z'n render-engine bouwen als er over 5 jaar pagina's kunnen zijn die strikt IE7 of IE8 of IE9 of IE10 verwachten? En moet Microsoft deze render-engines allemaal blijven ondersteunen?

En wat gaat er nu gebeuren als over 5 jaar IE10 uit is, waarin de IE7 render-tag niet meer ondersteund wordt? Dan heb je opeens een hele pagina die er vanuit gaat dat-ie als IE7 wordt gerenderd terwijl dat niet meer gebeurt.

Nee, de enige juiste oplossing is om zoveel mogelijk standards-compliant te werken, en alleen voor render-bugs een conditional comment gebruiken die speciaal voor 1 browser is. Men zal er nooit vanuit gaan dat die conditional comment door andere browser(versie)'s dan die ene specifieke versie gelezen moet worden, waardoor je het effect beperkt tot die ene browser(versie).

Als bedrijven heel erg zeker willen weten dat een site blijft werken, dan zullen ze dezelfde browser moeten blijven gebruiken, en pas na testen overgaan op een nieuwe (versie). Eventueel kan Microsoft daar nog een upgrade-pad voor verzinnen door de oude render-engine in de nieuwe versie mee te leveren, en die verkiesbaar te maken door een HTTP header (zoals het nu is dus, maar dan default de nieuwste versie). Dan moeten beheerders in hun webservers een simpel headertje meesturen, als ze een slechte website hebben.

De enige "tag" die ik in Firefox wil zien, is de conditional comment "tag". Daarmee kan je een hack schrijven voor een render-bug in Firefox, waar een volgende versie geen rekening mee hoeft te houden. Dat stukje code wordt immers door die versie niet gelezen.

[Reactie gewijzigd door DOT op 27 februari 2008 15:08]

Eventueel kan Microsoft daar nog een upgrade-pad voor verzinnen door de oude render-engine in de nieuwe versie mee te leveren, en die verkiesbaar te maken door een HTTP header (zoals het nu is dus, maar dan default de nieuwste versie).
Hiermee sla je de spijker op zijn kop vind ik. Typisch dat MS er nu voor kiest om by default het oude rendergedrag te gebruiken. In feite moet je dus als je IE hetzelfde wilt laten renderen als andere browsers een user agent tag opnemen waarin je aangeeft dat je standards-compliant document ook zo gerendered moet worden. Waarom oh waarom blijft MS toch dwingen om IE specifiek te benoemen in de HTML? Als je bovenaan als doctype XHTML opgeef dan kan IE 8 je toch gewoon geloven? De oude sites die IE niet om wil gooien hebben waarschijnlijk niet eens een doctype. En als ze dat wel hebben dan staan de IE hacks toch netjes in een IE6/7 conditional comment?
Maar stel: ik maak en site voor IE8 en ik voeg die tag toe

Mensen met IE 7 en lager renderen dan toch heel anders? Die tag is dan dus alleen nuttig voor 'oude sites' die geladen worden in IE8.
Maar stel: ik maak en site voor IE8 en ik voeg die tag toe

Mensen met IE 7 en lager renderen dan toch heel anders? Die tag is dan dus alleen nuttig voor 'oude sites' die geladen worden in IE8.
Dit is juist een feature voor nieuwe sites en voor de toekomst.
Oude site hebben de tag niet en worden dus geconfronteerd met IE7 rendering en blijven er dus uitzien zoals nu.
MS kan bovendien door deze methode heel snel de nu al dominante IE7 installaties updaten omdat de rendering hetzelfde blijft.
Ook voor bedrijven belangrijk.
Als je op IE 7 zit kun je makkelijk op IE 8 overstappen want de rendering blijft hetzelfde behalve voor sites waarvan de siteeigenaar vind dat die beter in IE8 rendert.
@hAl:

Tot nu toe ben jij degene die alles voortdurend verkeerd om ziet.

MS wordt gedwongen een tag te verzinnen die hun puinhoop opruimt omdat het ze na ruim tien jaar nog steeds niet is gelukt om een beetje normale browser te programmeren. Nu verzint MS een tag zodat alle webdesigners en web browser developers zich mogen aanpassen aan de fouten van MS. En dan nog het lef hebben om te zeggen dat 'Mozilla een tag nog niet ondersteunt'.

Voorlopig ondersteunt IE nog steeds HTML maar beperkt (om van standaarden van na 1998 nog maar te zwijgen) en is het dus aan hén om eindelijk eens aan de slag te gaan, niet de rest van de wereld.
Voor sitebouwers is dit juist heel goed.
En ook voor bedrijven is dit handig. Het wordt voor bedrijven bijvoorbeeld veel makklijker om vanuit IE 7 te upgraden naar IE 8.
Bedrijven lopen niet zoals bij de upgrade van IE6 naar IE7 risico's dat hun sites niet meer werken.
De versie-switch kan voordelen hebben maar alleen voor bijvoorbeeld IE-only applicaties. Op het WWW dien je je sowieso aan de standaarden te houden omdat er meer browsers zijn dan alleen IE. Het feit dat Microsoft deze switch echter niet enkel puur richt op bijvoorbeeld intranet applicaties of lokaal instelbaar maakt maar laat triggeren op een specifieke HTTP header of META-tag maken dat dit hele versioning-verhaal al een slecht idee is.

Door vervolgens ook nog te defaulten naar IE7 rendermode krijg je zelfs een bijzonder onwenselijke situatie die nadelen heeft voor de standaarden zelf, andere browser-bouwers en standards-aware webdevelopers...

http://crisp.tweakblogs.n...and-the-opt-in-catch.html
http://crisp.tweakblogs.n...nightmare-comes-true.html
http://crisp.tweakblogs.n...default-is-incorrect.html
In theorie is die tag niet nodig. Die is er alleen maar gekomen omdat MS vroeger de standaarden niet gevolgd heeft, en daar betalen de devvers nu de prijs voor.
Er is geen enkele browser gelijk of volledig qua ondersteuning van standaarden.
Ook bij andere browsers zijn er nog talloze renderissues die nu en dan ook worden opgelost. Ook veranderen de standaard af en toe en blijft de support voor standaarden dus altijd in ontwikkeling.
Er valt gewoonweg niet te ontkennen dat IE de echte spelbreker is (geweest) op het gebied van standaarden. Als ontwikkelaar maak ik eerst een website voor FireFox (W3 valid) en deze ga ik later aanpassen met extra stylesheets voor IE.
Ben benieuwd, als webdevelopper hoop ik dat ze zich aan de regels houden, en niet dat je alsnog een aparte stylesheet voor browser nummer 8 hoeft te maken.

Maar als ze de acid2 test doorstaan zal dat wel goedkomen :)
Juist omdat ze zich aan de standaarden zullen gaan houden moet je voor Internet Explorer alsnog een x aantal css files opstellen (6,7 en 8 )
Ik maak/hack helemaal niets meer voor ie5/ie6 gebruikers. Laat de gebruiker maar is een keer zijn browser updaten. Nog beter zou zijn, dat MS eens een meldingsscherm geeft als je ie5/ie6/ (ie7 toekomst) opstart met "update beschikbaar naar versie 8. nu installeren?" net zoals bij firefox.

Ik hou geen rekening meer met pre ie7 gebruikers. Dit doe ik sinds ik op Veerles blog de volgende quote tegen kwam van David Cassidy
Programming for individual browsers (i.e. old Internet Explorer) is , in my opinion, counter productive in pushing browser manufacturers to adhere to standards set by the industry. A solution that is perfectly valid and clearly working in most of the standards compliant browsers, should not be “hacked” to provide support for one or a few of those browsers that fail to meet those standards.
Wil jij mij de uitleg geven die je aan een klant geeft? Ik zou dat namelijk wel eens willen proberen. Een van de sites die ik heb gebouwd krijgt nog 25% IE6 bezoeken, en een andere site die ik beheer is voor een bedrijf waar intern alles met Windows 2000 gedaan.
Ik snap best dat je voor je privé-site geen rekening houdt met IE6 en/of IE7 (ik heb in IE7 nog een lelijke bug zitten in mijn layout :X) maar welk bedrijf stuurt 25% van zijn klanten weg? Maak hem dan IE-only, het aandeel van Firefox is kleiner dan IE6.
Waarom zou je een website IE-only maken?
Dat het aandeel Firefox kleiner is dan IE6 zou best kunnen kloppen hoor, maar voorzover ik begrepen heb is het enige wat je nodig hebt om een website Firefox-proof te maken, is gewoon degelijke, universeel geaccepteerde code, het is niet alsof je je website in het Firefox-iaans moet schrijven ofzo.

Overigens heb ik in Firefox wel een handige extension geinstalleerd, IE-tab genaamd. Met 1 klik op de knop kun je de pagina in de tab die je open hebt staan over laten schakelen op de IE engine. Kun je dus toch pagina´s openen met Internet Explorer engine, maar dan zonder IE daadwerkelijk op te starten.
Ideaal!
Alhoewel ik het idee heb dat het wel steeds minder vaak nodig is. Internetbankieren van de ABN Amro werkt tegenwoordig ook gewoon onder Firefox. Door aanpassingen van de kant van ABN Amro welteverstaan!

[Reactie gewijzigd door RagingR2 op 28 februari 2008 15:05]

Ja, voor 6 en 7 mag je nog wel dingen apart houden, hoewel 7 zich in de meeste gevallen prima aan de regels houd. Maar dat je in ieder geval niet een aparte stylesheet hoeft te maken voor nummer 8.
IE8 doorstaat de Acid2 test niet.

Zonderde opt-in meta <meta http-equiv="X-UA-Compatible" content="IE=8"> imiteert IE8 het rendergedrag van IE7. De Acid2 test bevat dat meta element niet. De renderengine van IE7 slaagt nog niet voor de Acid2 test en IE8 daarom ook niet.
Klinkt goed, maar toch zal de acid2 test echt niet alles omvatten.

Het zou inderdaad mooi zijn als ze eindelijk alles doen zoals het hoort. Het is gewoon te zot voor woorden dat je voor de ene browser een prima design neer zet terwijl het in de andere browser er totaal niet uit ziet of maar half werkt...
Acid2 is natuurlijk niet allesomvattend. Daarom staat Acid3 alweer voor de deur om de standards-compliance lat weer hoger te leggen.

[Reactie gewijzigd door Maurits van Baerle op 27 februari 2008 13:43]

Vreemd, zowel Firefox als IE 7 vertonen enorme mankementen.
Het hele idee van de Acid tests is dat de lat hoger wordt gelegd. Zo worden browser ontwikkelaars igedwongen om naar standards compliance toe te werken.

Sterker nog, er was een periode dat iedereen zijn eigen voorstellen mocht indienen om toe te voegen aan de Acid3 test. Eén van de voorwaarden was dat de test moest falen in de meest recente versies van ieder geval twee van de drie uit het rijtje Presto (Opera), Webkit (Safari) en Gecko (Firefox).
Firefox, Safari, Netscape, IE6, IE7 en Opera vertonen mankementen in die test.
Misschien verstandig om eerst te upgraden naar da laatste versies van Safari en Opera? De laatste versies van Safari en Opera renderen de test namelijk wel correct.

Firefox 3.0 zal de Acid2 test ook goed gaan renderen en Netscape wordt inmiddels niet meer ondersteund...
Acid3 test gaat in Firefox 3 beta 3 slechts tot 59/100, dus nog nie volledig correct en IE7 doe het helemaal verkeerd
Bij Mozilla wordt er in elk geval goed aan gewerkt; de laatste FF3 bèta toont de pagina al een stuk beter.
Nou als je de acid2 test uitvoert op ff2/ff3 en ie7. Zie je duidelijk dat ie7 hem gigantisch verpest, ff2 doet het redelijk en ff3 doet hem toppie.
de acid 3test is nog leuker, ie7 verknald deze zo enorm dat je het niet eens kan venster kan zien hij geeft ook pas na enige tijd een score van 12/100, ff2 doet hem nog redelijk hij krijgt een score van 50/100 en ff3 doet hem nog beter die krijgt een score van 59/100, maar ziet het er bijna hetzelfde uit (alleen in zwartwit)
Ze hebben nog steed geen Gecko-stijl dus ik denk dat de oude boxmodel hack nog steeds nodig zal zijn voor 8... dat is een van de dingen waar ik me kapot aan erger bij IE. Het moedigt net beginnende webdevelopers en designers aan slecht om te gaan met HTML en als je je dat eenmaal aangeleerd hebt is het moeilijk om te schakelen voor zo iemand. Plus IE 7- berusten nog veel te veel op frames en iframes terwijl dat toch wel de slechtste implementatie van inline browsen ooit is. doe het dan liever met css, php, ajax, etc.

Het zou goed zijn als IE8 de opbouw van een website doet volgens het Gecko-principe... dat zou al enorme verbeteringen vereisen van sites die IE only zijn (dat is sowieso al iets afgrijselijks.. IE only-crap)
Gecko is toch gewoon de renderengine van de concurrentie? Waarom zouden ze die gaan gebruiken :?

Is een beetje als: "die nieuwe audi kan nog steeds niet hetzelfde als die bmw (en zal het nooit kunnen): de motor is immers niet deezelfde..."
Als ze compatibiliteit breken met de oude versies dan zal die tijdelijke extra stylesheet me een zorg zijn. Maar als het goed is kan je gewoon die voor Firefox en Opera gebruiken.

De eeuwige vraag blijft: zal deze gaan klagen over IE-hacks in je stylesheet? Eerlijk gezegd hoop ik het.
Gewoon negeren en geen aparte stylesheet e.d. maken voor IE. Als maar 20% van je bezoekers nog IE gebruiken (waarvan de meesten de recentste versie gebruiken), is dat negeren natuurlijk wel erg makkelijk B-)
20% is nog steeds veel, te veel om een browser te laten schieten vind ik. En helaas is de realiteit dat er wel meer dan 20% van de internetters IE gebruikt.
Je bent imo te optimistisch. De meeste gebruiken nog steeds IE6 :)

Vraag me af hoeveel functionaliteit ze nu weer uit de welbekende FF-Browser hebben gejat. En alle mensen die FF verafschuwen dan roepen hoe fijn die nieuwe functionaliteit dan wel niet is. Te bezopen voor woorden eigenlijk.

En ben zelf ook web-ontwikkelaar en ben bang dat we nog meer IE-hacks mogen gaan maken. Te gek voor woorden hoeveel moeite je vaak moet doen om alles cross-browsed te maken :/
De meeste? Ik krijg op een site die veel door digibeten wordt bezocht, ongeveer 2x zoveel hits van IE7 dan van IE6. Dus dat valt nog best mee :)
Het enige wat ik er van weet is dat IE 8 inderdaad qua rendering beter is, maar ook qua interface. Ik heb een screenshot gezien waarin iemand liet zien hoe de interne beta er op dat moment uitzag.

Het schijnt dus dat Microsoft de Officie 2007 look in IE8 wil proppen op een innovatieve manier, en op de screenshot die ik zag was de gelijkenis inderdaad erg groot. Het oude menu is daar al vervangen door de Office2007 UI...

Of dit in deze versie ook (nog) zo is, weet ik nu nog niet...
Dat was dus een hoax. En bovendien ook nog een slechte. Het photoshop werk was aandoenlijk.

[Reactie gewijzigd door Smithers.83 op 27 februari 2008 15:49]

haha nee het was geen hoax, de gene van www.winsupersite.com heeft die mockup zelf gemaakt nadat hij dus die presentatie heeft bijgewoond. Omdat hij geen screenshots wist te bemachtigen heeft hij dus zelf iets in elkaar geknutseld.
lekker k*t dan... de nieuwe office look leek me een hele opluchting, totdat ik er mee moest werken!! anyone tried powerpoint 2007?? vreselijk!
na goed, IE heeft veel minder opties dus dat kan wel eens ok werken..

[Reactie gewijzigd door dadj op 27 februari 2008 16:47]

ik ben nog steeds tevreden met opera en firefox

die opereren veel sneller alleen is het soms nog wel eens het probleem dat deze sommige sites niet helemaal ondersteunen daarom val ik af en toe nog wel eens terug op IE6 :D
Zelfde (maar dan i.p.v. Opera Maxathon), maar als IE8 minder zwaar is als IE7 en zich beter aan de standaarden houd dan zal ik niet aarzelen om IE6 + Maxathon in te ruilen.
Maar ik vertik het om dat trage en lompe ding genaamd IE7 (Ja FF2 is ook zwaar vergeleken FF1/IE6 maar hij is wel een stuk sneller en gemakkelijker in het gebruik als IE7) op mijn PC te zetten.
dat ligt dan puur aan jou, ik draai IE7 op diverse machines en nergens is hij heel extreem veel trager dan IE6
Dan moet je een lompe PC hebben en een compleet gestripte FF, want IE7 werkt op zowat alle PC's die ik onder handen heb gehad gewoon vlot.
een mac versie zou ook wel weer eens aardig zijn...
En wat denk je daarmee te winnen? Safari, Opera en Firefox steken met kop en schouders en romp en benen boven IE uit. En IE8 gaat daar echt weinig aan veranderen.

[Reactie gewijzigd door Fuzzillogic op 27 februari 2008 14:34]

Geloof me, dat wil je niet! De maker van IE for Mac is ontslagen nadat bleek dat de browser aan meer standaarden voldeed dan de IE for Windows toendertijd. Zelfs nu voldoet IE for Mac meer aan de stanaarden dan IE 7. Je kunt beter bij IE for mac blijven, die kan nog een hele tijd mee. De gast die eruit gegooid is toen bij IE is volgens mij OF bij een standaardenbureau gaan werken of is naar de tegenstander gegaan...

Als IE 8 for mac wordt gemaakt zal die waarschijnlijk de standaarden meer negeren dan de IE for mac die er nu al jaren op draait.
ik heb uitsluitend intel macs en Rosetta sucks.. voor het testen van websites zou het gewoon fijn zijn een recente versie van IE te hebben op os x. maar ja, dan moet hij wel identiek zijn aan de windows versie..
On a different note; Safari laat nog teveel steekjes liggen wat mij betreft.. en echt stabiel is hij ook niet de laatste tijd.. maar goed altijd nog beter dan opera.. firefox is wel prima eigenlijk maar voelt toch logger en trager aan..
Als je momenteel nog IE for Mac gebruikt, zou ik daar maar heel snel mee ophouden. Deze versie is verschrikkelijk slecht en er zijn zoveel betere alternatieven.

Je hebt gelijk dat IE for Mac (veel) beter aan de standaarden voldoet dan IE6 voor windows (in vergelijking met IE7 durf ik het niet te zeggen). Tenminste als je puur kijkt naar CSS implementatie.

Javascript is een heel ander verhaal. Bij het minste geringste crasht hij en vele features worden dusdanig raar en tegen de specificaties uitgevoerd, dat het in veel gevallen beter is om je scripts gewoon af te kappen in IE for Mac.
En dat is vele malen erger dan wat CSS elementen niet of slecht ondersteunen.
Hmm, hoop dat ze in deze versie ook wat soepeler omspringen met ssl certificaten.. hoevaak ik in outlook web access wel niet die waarschuwing krijgt is niet meer te tellen.
Na controle van het certificaat klopt het certificaat gewoon, heel bizar.
Ja, we werken hier met zelf vervaardigde certificaten (van novell) voor https, maar alle andere browsers kan je zeggen "permanent accepteren" bij IE helaas niet :(
Zelfs als de site bij trusted sites staat krijg je elke keer weer die pagina dat het heeel onverstandig is om door te gaan....
In dat geval moet je het root certificaat van je CA exporteren en in de vertrouwde basiscertificeringsinstanties importeren. Vanaf dat moment is je zelf uitgegeven certificaat voor jouw PC een vertrouwd certificaat.
CA toevoegen aan lijst met vertouwde CA's?

Verder nooit problemen met IE en officiele certificaten...
het is wat gemakkelijker als ze tijdens het vragen of ge dat wilt toestaan (ze moeten het toch vragen), u ook de optie geven om het permanent te maken...
idd, als ze nou eens iets aan die certificaten zouden doen. ik heb een e-mail adres waarbij ik in een online omgeving alles doe, en voordat ik iedere keer wil inloggen moet ik eerst het certificaat goedkeuren. zelfs het toevoegen van het certificaat heeft geen zin :|
Is dat niet opgelost als je een CA neerzet? "Zelfvervaardige certificaten" is jezelf foppen :+
Jezelf foppen? Nee hoor. Zelfvervaardige certificaten beveiligen je verbinding net zo goed. Je bent inderdaad de 'zekere' identificatie kwijt, maar de encryptie loopt net zo hard door. Dus als het is puur om 'afluisteren' tegen te gaan maakt het niet uit.
Is dat niet opgelost als je een CA neerzet? "Zelfvervaardige certificaten" is jezelf foppen :+
Of je vertrouwt mij, of je rot maar op van mijn server. Zo kan je het ook zien.

Natuurlijk is dit geen oplossing voor commerciële websites. Echter, al draai jij (binnen een eigen bedrijf) je eigen website met https voor het beheer, dan is het helemaal niet erg om jouw eigen CA (of die van je bedrijf) te vertrouwen in plaats van VeriSign of een andere bekende root CA. Sterker nog: ik zou nog eerder mijn eigen CA vertrouwen dan die van een ander.
Als je moet testen voor HTTPS verbindingen, dan is het geen foppen.
Immers, het maakt je niet uit. Echter om het programma goed te testen, moet je dat ook via HTTPS doen.
Dan is zo'n zelfgecertificeerde certificaat best wel handig.
En als je weet dat je zelf de 'certificerende partij' bent, ga je opeens jezelf niet meer vertrouwen :+
Ik denk dat MS zich nog wel in de voet schiet met zulke snelle opvolgingen.
Firefox gaat prachtig van 1 -> 1.5 -> 2.0. En de Usability is niet echt veranderd.

Als MS nu per jaar een nieuwe IE los laat. Met allemaal hippe dingen en het er anders uit ziet, Plus dat het toch niet het zelfde rendert. Krijg je een versplintering van IE's En sites die daar niet op werken. Ideale aanleiding om Firefox te kiezen Wat dat niet heeft.
IE 7 is ruim 1 jaar oud, en het duurt ook nog wel een tijd voordat IE8 komt. Volgens loopt het redelijk gelijk.
Wat ik niet snap is waarom iedereen meteen over die acid2 test begint en meteen IE8 begint af te fakkelen.
Het is nog maar een BETA mensen.
Daarbij is de acid2 test bedoeld als test, niet als een harde eis danwel voorwaarde waar verplicht aan voldaan moet worden.
maar die test geldt wel als test om te zien hoe goed hij aan bepaalde standaarden voldoet... nog altijd slecht blijkbaar.

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