The Web Standards Project » Bugs

Acid3 receptions and misconceptions and do we have a winner?

lgunther — Fri, 03 Oct 2008 03:37:42 +0000

Acid3 is probably the most visible thing that WaSP has done the last year. When Google Chrome was launched almost every review included our little test as an indicator of standards support. It is often mentioned in blogs and articles. Now the Surfin Safari blog has announced that the team behind Webkit considers that they have passed the test in every aspect. And no doubt this is a great achievement. Congratulations to the Webkit team, but even more we would like to congratulate the average web user – who in a few years thanks to our test we hope will get a better experience!

What exactly does it mean to pass the Acid3 test?

There has been some confusion about the test and its importance. Some people have been saying things like ”my browser does not pass the test and I have no problems using it”. Quite a few other people seem to think that Webkit and Gogi (Opera’s internal build) passed the test already in March – despite the fact that neither team has made this claim.

To answer these misconceptions we need to address the issue of what exactly is being tested and how. The main part of test is automated through JavaScript, a sort of test harness that runs 100 subtests. Getting a score of 100 is not the same as passing Acid3 – a common misconception, or perhaps an oversimplification.

Many subtests are high on a developer’s wish list: Full CSS 3 selectors support, media queries, SVG fonts. Admittedly a few others test edge cases and more esoteric features – but the test was supposed to be a significant challenge!

The second part is a rendering test. Some of the scripted subtests produce results that affect the rendering, but there are also rendering issues that come in addition to these. Some of them are high on many designers’ wish list: Text shadow, downloadable fonts, and display: inline-block.

The third test is the so called “smoothness” criterion. It is basically a speed test. No subtest may take too long – and especially subtest 26 is challenging. Compared to Slickspeed, Sun Spider, the V8 test suite or Dromaeo Acid3 is not so thorough. It will give some indication of a browsers speed, though.

This is exactly as planned. Acid3 was not meant to be the one and only indication of a browser’s performance. In fact many other test suites are far more important. (We provide links to some of them below.)

Testing is really important. Without tests that check how well a certain browser follows standards, i.e. applies mark up and displays the result correctly, we can never guarantee an open, fully interoperable web.

A highly visible test like Acid 3 hopefully helps to promote such interoperability. One can also hope that all the other tests will receive the attention they deserve. Writing them is not a glamorous task, but highly essential.

Apart from improving its support for CSS in its browser, Microsoft has contributed 2524 test cases to the CSS 2.1 test suite. For that they deserve credit!

We all know that Internet Explorer currently lag a bit behind the other browsers in standards compliance. Indeed they are last of the big ones to pass Acid2 and they fail Acid3 more than any other browser. But can we declare Webkit as the best rendering engine now that they pass it?

Of course not. Since Acid3 is only one indicator of many. Webkit’s achievement is great – and there are many other really exciting things they are pioneering, like CSS transitions and transformations. And with Squirrelfish Extreme JavaScript performance looks really exciting as well.

In other regards Opera is a clear leader. It is the only browser that supports more than 90 % of the SVG test suite. It is the only browser that implements Web Forms 2.0, currently being merged into HTML 5. They supported media queries and SMIL long before Acid3 came out.

Gecko (with Spidermonkey) is no longer an underdog. Besides the fun of meeting the technical challenge it is not hard to guess that the Webkit team rushed to pass Acid3 also for marketing reasons – that they perhaps need a bit more than Mozilla. Mozilla concentrated on releasing Firefox 3 before Acid 3 received any real attention. Now that they are working on it they are impressive in another way, compared to Webkit. Looking at the discussions for bug 410460 and its related bugs, it is clear that any improvement must be rock solid. Work often continues even when a particular feature is good enough for Acid3.

In fact, there is actually one open issue still in Acid 3 that might temporarily cause Webkit to become incompliant again. http://lists.w3.org/Archives/Public/www-style/2008Sep/0218.html. I rest assured that a fix probably already is being made, though.

Perhaps one can compare this to a race where you are supposed to run a distance, with a bucket of water. One competitor crosses the finishing line first, the other, on the other hand, has not lost a single drop from his bucket. Both have done great. (By the way, internal builds of Firefox get a score of 97 now, and downloadable fonts work on Windows and Mac.)

In the end the winner is neither Webkit, Opera, Mozilla nor Microsoft, but developers who get more powerful features to work with and more consistency between browsers. And that means that in the long run they are able to focus on user experience, not browser shortcomings. This means that the true winner of Acid3 is anybody who surfs the web.

Some other test suites for your review:

Acid 2 Test Back to Normal

feather — Fri, 25 Jul 2008 02:11:37 +0000

For a while now we’ve had a problem with the Acid 2 Test on the WaSP site. If you’re unfamiliar with the Acid 2 Test, it is essentially a test for browser vendors to use as a means to gauge their standards compliance. If your browser renders the Acid 2 Test page the same as the Acid 2 reference rendering, then you know you’re hitting the mark.

I’ll be honest: over the last 10 days, I’ve learned more about the Acid 2 Test than I ever wanted to know. If you want to do the same, you might start with Acid 2: The Guided Tour.

The short version is that part of Acid 2 is a test for the way a browser handles an element when the data attribute references a URL that returns an HTTP status code of 404. A number of caching rules, mod_rewrite rules and redirects all collided to create a problem with our 404. The cached version of our 404 page was returning an HTTP status of 200. As you might expect, this basically makes the test useless.

Acid 2 was broken. Now it is not. Carry on.

Safari 3 Public Beta for Mac and Windows

Kimberly Blessing — Tue, 12 Jun 2007 06:07:10 +0000

As the Apple Worldwide Developers Conference kicked off today, Steve Jobs announced the availability of the Safari 3 Public Beta — for both Mac and Windows. Download it here.

I’ve only just installed it on Windows XP, but it has frozen once and crashed once already. There are complaints of blurry fonts and security bugs. It’s not rendering the Acid2 test correctly. (In fact, it’s not rendering the WaSP site correctly either. I assume the same is true on the Mac, but can someone verify?)

Don’t forget to send in your bug reports via the WebKit bug reporting form or the browser itself (Help > Report Bugs to Apple).

You can improve IE.next

agustafson — Sat, 04 Nov 2006 17:49:32 +0000

The Microsoft Task Force, DOM Scripting Task Force, and the JS Ninjas have been approached to help give the IE team some direction for improvements needed in IE.next, focusing mainly on JavaScript and the DOM. Together, we’ve begun assembling a list of things we think need addressing (bugs & implementation issues, enhancements in language support, etc.). We’ve tried to keep it balanced, with some things for the seasoned JavaScript developer and some for the folks who are just starting out in the world of DOM Scripting, but we need your help to make sure we aren’t missing anything.

In the interest of time and keeping the process streamlined and organized, we’ve opted to make the wiki invitation-only, but we do need your input. Please have a look at what we’ve put together so far and leave your thoughts/ideas/recommendations in the comments below. We don’t know how soon we’ll need to get this list over to the IE team, so please don’t wait to long.

We will work to incorporate any relevant ideas into the final list, prioritize it, and pass it along to the IE team. Once the list is out the door, we will need to develop test cases for each item on it (some of which we’ve already begun), so if you are interested, please let us know that as well.

Note: We’re not guaranteed to get everything we ask for, but they are listening.

Flash, JavaScript, UX, standards, apologia, apologies, and one man’s opinions

bhenick — Fri, 18 Aug 2006 23:33:21 +0000

My last two posts here have engendered a lot of anger from some Flash developers, and even led to direct questioning of my professional skill. Put bluntly, I believe the attacks say at least as much about the professionalism of their authors as they do about my own.

An apology

Regardless of that criticism, I offer an unqualified apology to Geoff Stearns for denigrating his work on SWFObject. It’s one thing for me to say that I don’t like it from a standards support perspective, but I framed my dislike in a tone that could counterproductively poison the attitudes of potential users of his work.

I took far too long to concede that my detractors were pushing back for very good reasons, and I’ve remained a moving target. They talk about user experience, I change the subject to Flash abuse. They talk about progressive enhancement, I change the subject to markup. They talk about the grating attitude of web standards advocates, and I (uncharacteristically) change the subject again.

If for no other reason that I was brought up to better rhetorical skills than I’ve displayed lately, I’m writing here in an effort to set things straight.

Web browsers have unforgivably broken and poorly documented plug-in implementations

There seems to be an agreement in principle amongst the participants in this discussion that W3C was a bad actor on this, because they insisted on sanctioning an element for plug-in inclusion that ran counter to the most common contemporary implementation. What we’re looking at, then, is an artifact of the Browser Wars.

To make the mess worse, no single software vendor has stepped up and implemented in a manner worthy of emulation. To hazard a guess I pose that this is because browser vendors don’t really care for Flash, and each browser vendor wants to undercut the others’ related media player titles.

If my guess is anywhere near the truth, then the obvious result is that the expressed attitudes of the responsible companies are unconscionable, and need to change without delay.

There is a time and place for any given tool

If we can agree that content can be anything that will travel across the network, then the nearer layers of the web technology stack have their own particular uses, as well: markup for structure, styling for presentation, scripting for behavior (on the client side) and logic (on the server side). Likewise, there is no good reason I can think of to publish content in Flash or PDF when XHTML+CSS will do just as well. I also see no reason to avoid using Flash when presented with any of the objectives it can accomplish with low overhead.

Tool abuse is unprofessional and inexcusable, particularly when it leads to the implementation of sites in ways that the web was never meant to handle

The web was and still is intended as a means to obtain and create content that poses minimal requirements for accessibility and usability. Yet over here we see Microsoft pushing its own unique implementation for web applications, and over there you see Adobe marketing its own substitutes for just about everything the W3C can sanction. Developers then buy in and insist on using the tools they’ve paid for to create everything they can think up, without regard for suitability to project requirements or the strengths of the web. The resulting fragmentation makes everyone a loser:

Developers are forced to specialize in order to maintain salable skillsets, which makes them vulnerable to shifts in market demand.
Users are forced into a wilderness of software in order to use the web effectively, which is confusing, time consuming, and expensive.
Project sponsors are forced to spend more money on software licenses and the professional services needed to stitch together all of their preferred technologies.
Software vendors are forced into onerous release schedules, which reduces the reliability of their products and consequently their customers’ trust.
Network infrastructure is forced to account for more volume and protocol support than would otherwise be the case. This raises everyone’s overhead.

One of the most important definitions of a web standard is that rights to its use are completely and permanently unencumbered

This single fact accounts for most of my personal hostility toward the SWF format. The ubiquity of Flash creates the potential for future rights abuse such as that committed by Unisys in the case of the Graphics Interchange Format, and Eolas over its submarine multimedia patents. How many times do we have to go through experiences such as those before we learn to rely on the tools that are protected from such outcomes?

The desktop publishing metaphor does not and never will apply to the web, and developers need to do everything they can to get that point across to project sponsors

The insistence on pixel-perfect layout that results from reliance on the desktop publishing metaphor eats up time and money to an extent that places effective sites beyond the reach of many potential customers for web development services. It also constrains meaningful use of the web to the personal computer platform, and sometimes printed documents. While there are those who say that mobile platforms can also be used for visiting sites, there are so many caveats on that assertion as to make it empty. (Universal support for the handheld CSS media type would be nice to have any day now.)

Web standards support should be given priority over exacting user experience requirements, if a choice must be made between the two

This is probably the most controversial of my positions, but it’s owed to my belief in the web as a universal publishing platform. In the case of broken plug-in behavior, why not put plain links to bare media files inside their calling elements and let the visitor’s default media player take care of the rest? Creating a fallback that results in a positive user experience for that case isn’t impossible.

The balance of this attitude is engendered by the fact that given thoughtful implementation and valid markup, the resulting work product can be adapted to an extraordinarily broad range of contexts. This may not seem like much to the folks who are stuck on the desktop publishing metaphor, but information published for the express purpose of being viewed anywhere, anytime, on any capable and connected platform – which is what web standards are meant to provide – appears more valuable to me than something that looks and behaves exactly as specified when viewed by a remote user in Internet Explorer on a 1024×768 LCD or plasma display.

Using JavaScript to do an end run around the need for valid markup (and the content inside it) is at best a cop-out, and at worst an ingredient of future disaster

For starters, users who disable JavaScript will arguably never see the content you originally intended. Given the number of security issues for which disabling JavaScript is the recommended remedy, this use case cannot be ignored.

Another objection I have to this practice is that it increases the scope of production. Rather than just repairing one component of a site implementation when it’s time to redesign, you run the risk of needing to fiddle with other components as well (in this case, JavaScript in addtiion to markup).

Finally, you’re forcing another support assumption on the user. While sites designed around a desktop publishing metaphor and viewed on a personal computer may not suffer as a result, every other potential use case will.

Forward compatible implementation is more valuable than you think

So much of what I fight back against is inertia: people who use Internet Explorer because they’ve always used Internet Explorer, sponsors who insist that the work product have its layout nailed down to the pixel because that’s always the way it’s been done, producing far too many templates for lack of good wireframes because the graphic designers have never needed to work from wireframes, and so on.

However, the growth in popularity of Atom and bona fide microformats suggests the web’s not going to be monopolized by static HTML forever. When the evolution to XML gathers momentum, properly implemented XHTML+CSS infosystems will be the easiest and earliest such systems to utilize the full potential of XML. Do you really want your work to be left in the dust?

If not, then you need to learn how to do that kind of work, the sooner the better.

When standards advocates are unreasonable, it’s because they’re frustrated by the willful ignorance and sloth they see in the opposing camp

In practice, standards advocates demonstrate practices that require a different mindset than was typical for several years. In effect, we’re in the uncomfortable position of telling a lot of folks that everything they know is wrong. Here are some of the results:

Back when Zeldman instituted the Browser Upgrade campaign, its message was immediately co-opted by several high-volume sites designed by teams who were too damned lazy to institute progressive enhancement.
Rather than just admit that they are contstrained in their jobs by legacy content management systems that they cannot replace, some developers claim that they deserve the same credit given to colleagues who build fully standards compliant sites.
Every time accessibility flaws in all-Flash sites are publicly skylined, Flash developers howl in protest… but rarely endeavor to make their sites accessible.
Developers who have been in the business long enough to know better bitch and moan about the shift in perspective required to learn CSS, and refuse to learn it.
Other so-called professionals abuse their IDE’s and bill hours even though (as I once put it) “they wouldn’t know emphasis from italics if the difference bit them on the ass.”

All of these people continue to make noise and abuse the good will of their sponsors with a degree of persistence akin to that of Netscape 4’s erstwhile market share, and you bet we’re not happy about that… especially when they attack us ad hominem in the face of the fact that the truth hurts. That happens all the time.

A DOM Scripting Wishlist for Microsoft

adactio — Sun, 30 Apr 2006 20:25:04 +0000

The development team working on Internet Explorer 7 have been doing a great job. They have — quite correctly — focused on improving the browser’s CSS support and, as the beta preview shows, IE7 will be a huge improvement on IE6.

Internet Explorer’s JavaScript and DOM support is pretty darn good and IE7 introduces a few updates (like native support for XMLHttpRequest instead of using ActiveX). Still, there’s always room for improvement: that’s true of any browser. Here at the DOM Scripting Task Force, we’re hoping that some JavaScript nips and tucks might be on the cards for future versions of Internet Explorer.

We want to make the browser developers’ lives easier. To that end, Task Force member Peter-Paul Koch has kick-started a discussion called “IE 7 and JavaScript: what needs to be fixed?”

If you have some issues with IE’s JavaScript support that you’d like to see addressed, write up a description of the problem and post a link to it in a comment on PPK’s blog entry (links are easy to pass around).

As well as being a potentially useful resource for the browser makers, amassing a list of IE “gotchas” will be very beneficial for developers.

!important Fixed in Later IE7 Releases

mollyeh — Sat, 04 Feb 2006 01:58:39 +0000

It was brought to my attention today that the IE7 Beta 2 Preview wasn’t honoring the role of the !important declaration and as such was causing alternative box model hacks to fail.

!important is important for several important reasons. First is the very reason !important exists, which is to provide a balance between author and user styles. It has been part of CSS since CSS 1.0, although implemented differently back then.

The other important reason !important is so important in current practices is because it plays a role in 2 of the 3 Alternate Box Model Hacks outlined by Edwardson Tan.

The hacks in question work when the browser interprets CSS properly, and filters correct information to certain browsers that do not. Ingo Chao has documented why this now fails in the current IE7 Beta 2 Preview.

The good news today is that the IE team has in fact fixed the way IE handles !important in all future builds beyond the IE7 Beta 2 Preview.

So worry not, my important friends, we’ll soon have an IE that understands just how important !important is.

Note: I apologize if any “importants” were inadvertently left out of this message. I assure you that I didn’t mean to suggest they were not (!) important.

Star HTML and Microsoft IE7

mollyeh — Thu, 22 Dec 2005 20:19:32 +0000

Chris Wilson, Group Program Manager for IE Platform and Security at Microsoft, and Position is Everything‘s Big John Gallant have been having a conversation about * html in Microsoft’s upcoming Internet Explorer 7 for Windows (IE7). Wilson has been encouraging CSS designers and developers to repair any bug-specific hacks for several months now. Gallant remains unconvinced the solution is that easy and is afraid countless, unpaid hours of repair work will wind up on the shoulders of those designers and developers who have employed * html related hacks in their designs.

Universal woe

Hacks for browsers typically do one of two things. They exploit a bug (a flawed implementation) or they exploit the complete lack of an implementation. In the case of * html the hack is based on a bug. Child selector hacks, on the other hand, are based on the fact that IE versions up to 6.0 do not include any implementation for child selectors whatsoever.

The popular Holly Hack and related IE workarounds exploit a browser bug in which the universal selector, *, in CSS is misinterpreted. The bug is present in multiple versions of Internet Explorer. The hack is used primarily to correct a number of layout issues related to IE’s proprietary layout model.

With the bug repaired, Wilson says universal selector-related hacks will fail in IE7′s strict mode (compliance mode). The bug remains present when IE7 is running in quirks mode, and in that mode, the hacks will understandably work. Wilson began advocating that the Web design and development community prepare for change back in October. Gallant wants to know how the changes will affect you via a poll at p.i.e..

Is the entire kafuffle a non-issue until we actually have IE7 and see what we really get? Or maybe we can learn from Tantek Çelik (Technorati, WaSP) who advocates that bugs including * html be repaired; and that implementations such as child selectors (which are often used in tandem with the Holly Hack), could be held off until a later date if necessary.

Exploiting a software bug to create a hack becomes dangerous as software is updated and bugs are repaired. While somewhat less danger exists when implementation issues are addressed, what happens when the implementation is introduced and it, too, is flawed? This is why hacks are so problematic, but just how these particular hacks in IE7 will affect the community is still vague.

Me, Me, Select Me!

The faulty interpretation of the universal selector is currently present in the following versions of Internet Explorer:

Macintosh: 5.0, 5.15, 5.21
Windows: 5.0, 5.5, 6.0

The bug is present in both quirks and standards mode in these versions. Here’s a look at what happens in these IE versions when the universal selector is involved:

Microsoft IE Browser Misnterpretations: Universal Selector
Selector	IE Interpretation	W3C Interpretation
`* html`	`html`	Matches no element (the `html` element is root and therefore never has an ancestor)
`* * body`	`* body`	Matches no element (`body` is the first child of `html` only)
`* html body`	`html body`	Matches no element

Have layout?

IE layout, which is IE’s determination of how elements are drawn, bound, and behave, has been a bit of a mystery for some time. This is largely due to lack of documentation and discussion about the issue. Dean Edwards (WaSP, WHATWG), Gallant and others went in search of better documentation for hasLayout. Markus Mielke, a Microsoft program manager working with Wilson, joined in the conversations which bore fruit.

Two good references that emerged regarding IE layout are On Having Layout and HasLayout Overview in which Mielke writes:

There are several bugs in Internet Explorer that can be worked around by forcing a layout (an IE internal data structure) on an element (like, dimensional bug fixes and Holly hack). Most users are not aware of the implications of having a layout applied to an element. – HasLayout Overview, Markus Mielke, Microsoft

Mielke’s article, which cites the input of Edwards, Gallant, Wilson and WaSP among others, goes directly to the heart of the * html concern.

Road to repair

Gallant says that the * html hack in CSS is “the only hack that is going to cause serious pain” and believes that the hack “could probably be retained without getting in the way of any actual support enhancements” that Microsoft has planned for IE7.

Wilson points out that the goal is to fix IE, and getting there is a process. “I want to remove the * html hack to make it useful . . . because it will then only apply to obsolete browsers.” He also shares a dislike for any hacks at all. “All CSS hacks are too risky in the long run, unless they only apply in orphaned or obsolete browsers, period. Tantek Çelik said this; I agree with it very strongly.”

Gallant states that the “time to kill the * html hack is when Vista arrives, presumably without the layout problem.” Wilson feels that fixing the browser is most important. “The Holly hack, and I say this with the greatest of respect, is an elephant gun solution. Sometimes it’s an elephant you’re trying to fix. Sometimes it’s a mouse. Some elephants are fixed in IE7, some mice are. We will not fix every possible layout issue in IE in IE7, however, and it’s unrealistic to expect we can do so.”

This entry cross posted to take your comments and trackbacks.

Tool for tracking IE memory leaks

chrisk — Tue, 06 Dec 2005 16:07:56 +0000

Drip.

Pandora’s Box (Model) of CSS Hacks And Other Good Intentions

tantek — Sun, 27 Nov 2005 13:15:31 +0000

This Thanksgiving I’ve decided it’s about time that I provided some more background and analysis on one of the things I am certainly unintentionally (in)famous for. This entry was started at 7pm on Thanksgiving evening, but took me until now to complete.

Before CSS hacks

I don’t know who first came up with using the presence of a ‘media‘ attribute on or