ACID3 test released — OZONE Asylum, home of the Mad Scientists

OZONE

ACID3 test released

This page's ID: 30054

Edit Post

Who can edit a post?	The poster and administrators may edit a post. The poster can only edit it for a short while after the initial post.

Your User Name:
Your Password:
Login Options:	Remember Me On This Computer

Your Text: Insert Slimies » Insert UBB Code » Close Last Tag \| All Tags UBB Help	It's not really that hard to support web standards. WebKit proves that - with the smallest development team and the shortest time in development of the big four, they've gone from worst to best (hixie actually had trouble finding tests for ACID3 that would lower WebKit's score! That's not saying they have the best standards support, just that they have the least buggy one.) There's several aspects of standards support however. Let me take an example: There's a HTTP feature I read about in bugzilla months ago, I can't really recall which feature, but Mozilla has supported it for ages. Then Apache went and actually implemented it correctly per spec on the server. Suddenly, Apache hosted sites which upgraded to the newest version started breaking... because nobody had actually implemented the server part of the specification correctly before, and now they encountered clients with correct implementations, so nobody knew the whole feature was broken, but only if both client and server was compliant at the same time! Another example: If you implement ES3 per specification, there is no way to get from the Program production to the RegExpLiteral production. I guess they missed it :) Nobody noticed until the recent revival of the ES4 development, because nobody actually implemented the specification, everybody reverse engineered Netscapes JSRef and Microsofts JScript, including Netscape and Microsoft themselves. A third example: The DOM1 was largely informed by the browser implementations. However, neither DOM1, nor the more Java oriented DOM2 and DOM3, interoperate well with JavaScript. One particular issue is that the interface hierarchy does not work with the prototypal inheritance scheme of JavaScript. For the interface objects to be exposed and their prototypes to be dynamic, browsers MUST have multiple inheritance on the prototype delegation level. None of the browsers today do (though they have patch-ups for that in some places), and when you scratch at the surface, the only implementation that actually can retain coherency in the face of this is that of IE, because IE doesn't actually pretend that the DOM objects work through the JavaScript prototypal inheritance scheme in the first place. A fourth example: Internet Explorer implemented XML a bit too early. They implemented XML before the Namespaces spec, and Infoset, and Canonical XML. The result is that the XML engine that Trident is dependent upon is not capable of daeling with namespaces, and Microsoft didn't want to change to a later more compliant version of MSXML because XML was used loads of places in intranets, and several XML applications including their pseudo-XML Office-HTML would break if they changed to a Namespaces compatible implementation. There are in other words XML applications/markup languages that stop working in implementations that support Namespaces, simply because that's what Internet Explorer started out with! -- var Liorean = { abode: "[sigrotate][url]http://liorean.web-graphics.com/[/url]\|[url]http://codingforums.com/[/url]\|[url]http://web-graphics.com/[/url][/sigrotate]", profile: "[url]http://codingforums.com/member.php?u=5798[/url]"}; Loading...
Options:	Enable Slimies Enable Linkwords

« Backwards — Onwards »

Show Forum Drop Down Menu