wiki and ACID3

来源：互联网发布：c socket网络编程编辑：程序博客网时间：2024/06/07 03:02

http://www.acidtests.org/

Acid3

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Acid3

The reference image for Acid3. URL http://acid3.acidtests.org Type of site Web standards test Available language(s) English language Owner The Web Standards Project Created by Ian Hickson Launched March 3, 2008

Acid3 is a test page from the Web Standards Project that checks how well a web browser follows certain web standards, especially relating to the DOM and JavaScript.

It was in development from April 2007,^[1] and released on 3 March 2008.^[2] The main developer was Ian Hickson, who also wrote the Acid2 test. Acid2 focused primarily on Cascading Style Sheets, but this third Acid test focuses also on technologies used on modern, highly interactive websites characteristic of Web 2.0, such as ECMAScript and DOM Level 2. A few tests also concern Scalable Vector Graphics (SVG), XML and data: URIs. Only elements from specifications as of 2004 are included.^[3]

When successful, the Acid3 test displays a gradually increasing percentage counter with colored rectangles in the background. The percentage displayed is based on the number of sub-tests passed. In addition to these the browser also has to render the page exactly like the reference page as rendered in the same browser. Unlike the Acid2 test, the reference rendering is not a bitmap, to allow for certain differences in font rendering.

[hide]

1 The test
2 Development and impact
3 Layout engines
- 3.1 Non-compliant layout engines
4 Mobile web browsers
5 References
6 External links

[edit] The test

The main part of Acid3 is written in ECMAScript (JavaScript), and consist of 100 subtests, in six groups, called "buckets", plus four special tests (0, 97, 98, and 99).^[4]

Bucket 1: DOM Traversal, DOM Range, HTTP
Bucket 2: DOM2 Core and DOM2 Events
Bucket 3: DOM2 Views, DOM2 Style, CSS 3 selectors and Media Queries
Bucket 4: Behavior of HTML tables and forms when manipulated by script and DOM2 HTML
Bucket 5: Tests from the Acid3 Competition (SVG,^[5] HTML, SMIL, Unicode, …)
Bucket 6: ECMAScript

The compliance criteria requires that the test is run with a browser's default settings. The final rendering must have a 100/100 score and must not only be pixel-identical with the reference rendering but the animation has to be smooth (taking no more than 33 ms for each subtest on the top-of-the-line Apple laptop^[6]) as well.

Acid3 rendered by the latest Firefox 3.1 development build. Bucket 2 passes all 16 subtests, buckets 3, 4, and 6 pass more than 10 subtests while buckets 1 and 5 pass more than 5 of these.

As the test is run, rectangles are added to the rendered image; the color of the rectangles is decided by the number of sub-tests passed in the bucket. If all subtests fail in a particular bucket, its associated rendered rectangle will be invisible. If some subtests are cleared the color will change in four steps:

1-5 subtests passed: Black rectangle.
6-10 subtests passed: Grey rectangle.
11-15 subtests passed: Silver rectangle.
All 16 subtests passed: Colored rectangle (red, orange, yellow, lime, blue, purple - for each of the six rectangles, in order).

After the Acid3 test page is completely rendered, the capital A in the word Acid3 can be clicked to see an alert (or Shift-Click for a new window) explaining exactly which subtests have failed, and what the error message was.

In order to render the test correctly, user agents need to implement the CSS 3 Text Shadows and the CSS 2.x Downloadable Fonts specifications, which are currently under consideration by W3C to be standardized. This is required as the test uses a custom TrueType font, called "AcidAhemTest" to cover up an "X" on fuchsia colored background. The glyph, when rendered by the downloaded font, is just a square, made white with CSS, and thus invisible.^{[citation needed]}

In addition, the test also uses Base64 encoded images, some more advanced selectors, CSS 3 color values (HSLA) as well as bogus selectors and values that should be ignored.

[edit] Development and impact

As stated above, Ian Hickson started working on the test in April 2007, but it progressed slowly. In December 2007 the work restarted and it received public attention on 10 January 2008, when it was mentioned in blogs by Anne van Kesteren^[7] and Dustin Brewer.^[8] At the time it resided at a URL clearly showing its experimental nature: "http://www.hixie.ch/tests/evil/acid/003/NOT_READY_PLEASE_DO_NOT_USE.html" That did not stop the test from receiving widespread attention within the web development community. At this time only 84 subtests were done, and on 14 January Ian Hickson announced a competition to develop the missing 16.^[9]

The following developers contributed to the final test through this competition:

Sylvain Pasche. Test 66–67 (DOM).
David Chan. Test 68 (UTF-16/UCS-2).
Simon Pieters and Anne van Kesteren. Test 71: HTML parsing.
Jonas Sicking and Garret Smith. Test 72: dynamic modification of style blocks' text nodes.
Jonas Sicking. Test 73: Nested events.
Erik Dahlström. Test 74–78: SVG and SMIL.
Cameron McCormack. Test 79: SVG fonts.

The impact of the test on browser development was dramatic, already before its official release. WebKit in particular made progress; in less than a month their score rose from 60 to 87.^[10]

The test was officially released on March 3, 2008.^[2] A guide and commentary is expected within a few months.^[10] The announcement that the test is complete means only that it is to be considered "stable enough" for actual use; if problems and bugs are found, it will still be modified to fix it. The test has already been modified to fix several issues including issues regarding to sub-pixel positioning, SVG surrogate pairs and performance.^[11] On March 26, 2008—the day both Opera and WebKit teams announced a 100/100 score—developers of WebKit contacted main Acid3 developer Ian Hickson about a critical bug in the Acid3 that presumably may have forced a violation of the SVG 1.1 standard to pass; thus Hickson proceeded to fix it with the help of Cameron McCormack, member of W3C's SVG Working Group.^[12]^[13]

By the end of March 2008, early development versions of the Presto and WebKit layout engines scored 100/100 on the test and rendered the test page correctly.^[14]^[13]^[15] Presto still has performance issues in producing a smooth animation in the test, thus it has not passed the Acid3 test yet. As of build r34278, WebKit produces a smooth animation, and thus passes the Acid3 test^[16]. Firefox developers are preparing for the imminent release of Firefox 3, as a result they are focusing on stability rather than passing the Acid3 test.^[17] Microsoft, developers of the Internet Explorer browser, said that Acid3 does not map to the goal of Internet Explorer 8 and that IE8 will improve only some of the standards being tested by Acid3.^[18]

On April 22, 2008, Hickson again fixed a bug in the Acid3 test discovered by a Mozilla developer. This change possibly invalidates the previously reported scores of 100/100 for development versions of Presto and WebKit.^[19]

[edit] Layout engines

Acid3 was deliberately written in such a way that every web browser failed upon the test's release. Many of the browser teams are actively working to improve test results.

[edit] Non-compliant layout engines

Layout engine progress for the Acid3 test Layout Engine Main Browser Stable Build Screenshot Development Build Screenshot Notes Trident Internet Explorer

IE 7.0

IE 8.0 beta1 Microsoft has stated that Internet Explorer 8 will improve only some of the standards being tested by Acid3.^[18] KHTML Konqueror

Konqueror 4.0.4

The tracking bug for Konqueror was filed on 30 January 2008.^[20] Gecko Firefox

Firefox 3.0

Firefox 3.1.preAlpha Mozilla developers have a tracking bug^[21] and a public spreadsheet^[22] for the status of their work regarding this test. Presto Opera

Opera 9.5

WinGogi Acid3 build The latest post-9.5 build scores 100/100 and renders the test correctly, but still fails the smoothness criterion.^[15] WebKit Safari

Safari 3.1

Safari 4 Developer Preview The team that develops WebKit has a tracking bug.^[23] The latest WebKit development build scores 100/100, renders the test correctly, and passes the smoothness criterion^[16].