Afgelopen MIX (Las Vegas) stond de tweede dag in het kader van alle ontwikkelingen omtrent Internet Explorer 9, die uitgebreid werden toegelicht in Internet Explorer 9: Microsoft’s stap voorwaarts. Toch werd er ook op de Nederlandse DevDays een sessie gewijd aan deze nieuwe browser, maar vooral aan de discussie over standaarden. Dat leverde boeiende inzichten op.
Giorgio Sardo (foto) verzorgde hierover een sessie waarin een aantal nieuwe functies van Internet Explorer werd getoond, functies die jammer genoeg niet afweken van wat er op de MIX al te zien was. Wat de sessie echter een stuk interessanter maakte was de discussie die werd gevoerd over webstandaarden. Want hoewel webstandaarden de heilige graag zijn als het gaat om hoe geaccepteerd een browser is, is er vaak veel ruimte voor interpretatie bij het implementeren van die standaarden.
Een goed voorbeeld hiervan is de ondersteuning van ronde hoekjes op elementen. Want hoewel een heel aantal verschillende browsers de standaarden hebben geïmplementeerd, en ondersteunen blijkt dat dit er in elke browser toch net anders uit ziet. Het blijkt dus nog niet mogelijk om een consistente gebruikerservaring te creëren, een ervaring die in elke browser het zelfde oogt.
Een overzicht van hoe afgeronde hoekjes er in van boven naar onder FireFox 3.6, IE 9 en Chrome uitzien
In het bovenstaande plaatje is een pagina met daarin de opmaak voor ronde hoekjes opgenomen en is te zien hoe deze hoekjes door de verschillende browsers worden weergegeven. Let wel dat alle drie de browsers dit item ondersteunen volgens de webstandaarden, maar dat ze alle drie een ander resultaat weergeven. De bovenste browser is FireFox 3.6, gevolgd door de demo die van IE9 beschikbaar is de onderste is weergegeven in Chrome.
De vraag die je vervolgens kunt stellen is waarom al die browsers het anders intrepeteren, en hoe het kan dat de webstandaarden zoveel ruimte overlaten voor intrepetatie. Voldoen de huidige standaarden wel aan de hedendaagse eisen, of is er juist meer input vanuit de community nodig om zulk soort zaken vroegtijdig af te vangen? En nog belangrijker: hoe kan je als ontwikkelaar of designer er voor zorgen dat wat je maakt er ook in elke browser zo uit ziet als jij had bedoeld?
Microsoft heeft in ieder geval het bovenstaande probleem bij de community neergelegd met de vraag wat wij als gebruikers verwachten, je input kun je kwijt onder deze blogpost.
Volg hier de hele serie DevDays artikelen.
Michel 
Mike van Hoenselaar 
Patty 
Samuel Driessen 
Els 
De vraag is in hoeverre Firefox’s manier van ondersteuning wenselijk is. de -moz css tag’s zijn natuurlijk vendor-specific. Persoonlijk vind ik de manier van IE en Chrome beter.
Het probleem is dat alle huidige mogelijke implementaties wel zullen worden opgepakt en dus zullen ze ook allemaal blijven bestaan. Dit is tot nu toe nog niet anders geweest, in ieder geval. Resultaat is dat ondanks dat tegenwoordig alle browsers de “standaard” ondersteunen het nog steeds haast onmogelijk zal blijven om dezelfde ervaring in alle browsers te krijgen.
@Pieter de -moz css tags zijn inderdaad vendor-specific, echter voegt Mozzila deze ‘zelf’ toe aan de opmaak. Er word dus gewoon gebruik gemaatk van de ‘border-radius’. Toch ben ik het wel met je eens dat IE en Chrome en en ander beter implementeren, omdat ze als browser niet jouw html manipuleren.
Wat betreft het probleem over implementaties ben ik het met je eens dat het haast onmogelijk blijft om in alle browsers dezelfde ervaring te krijgen, maar misschien dat we als ‘community’ wel in staat zijn mee te sturen aan het proces, en dus de implementatie van de regels.
Gefeliciteerd met je post Appie,
Wat betreft de vendor-specific prefixes, deze zijn naar mijn inzicht zeker nodig. Nu lijken alle grote spelers op de browsermarkt het eens te zijn over de syntax van border-radius en kan de vendor-specific -moz- er wel af. Maar dit geld zeker niet voor alles.
Ook Chrome(uiteraard gaat het over webkit) kent nog een stuk of 50 andere zoals “-webkit-backface-visibility: visible;”. Ik weet niet eens wat het doet.
Jij vind de manier van Chrome en IE beter. Er is geen wezenlijk verschil.
- Webkit gebruikt dus ook -webkit- en heeft pas recentelijk wat prefixes weggehaald.
- Trident kent ook -ms- maar dit lijkt zelden gebruikt te worden en IE loopt daardoor gewoon achter in het door gebruikers laten testen van nieuwerwetse CSS. http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor-extensions.aspx
Ik weet niet hoe het zit met de release cycle van Firefox maar het lijkt me niet onwaarschijnlijk dat Firefox eerder zonder prefix is dan IE.
Om maar even meer inhoudelijk op het artikel in te gaan. Het lijkt hier niet om border-radius te gaan maar om borders.
De radius is een dotje wiskunde waar naar mijn inzicht geen ruimte is voor eigen interpretatie.
Het is natuurlijk reuze interessant maar is het niet raar om bij een presentatie van IE9 te gaan praten over CSS1? Nog interessanter zou zijn om te kijken hoe border-image werkt in de verschillende browsers.
Ik vind -op zich- de oplossing van IE nu het mooiste(behalve dat de dash te klein is, hier hebben we dotted voor). De gehele border met alle kanten berekenen en dan alle lijntjes door laten lopen. Er is overigens wel over nagedacht. Zie de notes bij http://www.w3.org/TR/css3-background/#border-style
De waarschijnlijke reden dat dit niet bij alle browsers is zoals nu dus in IE9, het is meer/lastiger programmeerwerk.
Gelukkig is het niet iets waar ik ooit last van heb gehad.
Super dat het IE team zich duidelijk aan het verdiepen is in correcte implementatie van CSS1, CSS2 & CSS3. Daar ben ik sowieso blij mee. Maar het wordt dus nog afwachten. Dit is nog een pre-alpha.
Ook jammer dat in het plaatje boven niet op z’n minst beta’s van firefox en chrome zijn gebruikt.
Ik had ook graag gezien hoe IE6 zijn borders rendert. IE6 wordt nog ongeveer net zo veel gebruikt als Chrome…laat ik daar maar niet verder op ingaan… ik wens de IE9 developers het beste toe. Ik ga er maar vanuit dat het niet hun schuld is dat IE te lang een probleem is geweest voor web developers.
Ik denk dat MS wel iets belangrijkers heeft om zich druk over te maken dan hoe bordertjes exact gerendered gaan worden. Jarenlang hebben ze de frontend developers geirriteerd met hun lakse houding met betrekking tot het implementeren van nieuwe technologieen. En nu gaan ze er eindelijk eens mee aan de slag (en zijn ze arrogant genoeg om het een ‘stap voorwaarts’ te noemen, ‘stapje richting het heden’ zou beter zijn), en gaan ze over dit soort details neuzelen.
Alles wat ze nu met IE9 eindelijk eens gaan introduceren, had natuurlijk al lang in IE8 moeten zitten. Daarnaast overcompliceren ze veel zaken (das nu wel duidelijk) en ben ik benieuwd wat de gevolgen zijn van de compatibility-meta die in IE8 is geintroduceerd, zodra IE9 uitkomt.