Working together for standards The Web Standards Project

Acid2: The Guided Tour

Acid2 is a test page for web browsers published by The Web Standards Project (WaSP). It has been written to help browser vendors make sure their products correctly support features that web designers would like to use. These features are part of existing standards but haven’t been interoperably supported by major browsers. Acid2 tries to change this by challenging browsers to render Acid2 correctly before shipping.

Acid2 is a complex web page. It uses features that are not in common use yet, because of lack of support, and it crams many tests into one page. The aim has been to make it simple for developers and users to check if a browser passes the test. If it does, the smiley face on the left will appear. If something is wrong, the face will be distorted and/or shown partly in red.

The purpose of this document is to explain how Acid2 works. The markup behind Acid2 is peculiar in that it attempts, on one single page, to test many different features. We do not envision or recommend that normal Web pages should be written this way, but it is appropriate for a test page. At first sight, the source code is hard to understand, but the guided tour offered in this document will explain it in some detail. The guide assumes a technical understanding of HTML, CSS and PNG.

Note: Acid2 uses data URLs extensively. To allow vendors that not yet support data URLs to test with Acid2, a version without data URLs has been published.

Note: When taking the test, you should use the default settings of the browser you are testing. Changing the zoom level, minimum font size, applying a fit-to-width algorithm, or making other changes may alter the rendition of the Acid2 page without this constituting a failure in compliance. (Added 21 July 2006)

What are we testing?

Acid2 tests features that web designers have been requesting. Everything that Acid2 tests is specified in a Web standard, but not all Web standards are tested. Acid2 does not guarantee conformance with any specification. After careful consideration, we have selected and are testing the features we consider most important for the future of the web. Although Acid2 was inspired by Microsoft’s announcement of IE7, it is not targeted at a specific browser. We believe Acid2 will highlight problems in all current browsers.

Acid2 assumes basic support for HTML4, CSS1, PNG, and Data URLs. The first three items on the list are included for obvious reasons: they form the backbone of web content standards. Data URLs are described in HTML4 but is less used due to lack of support. We believe data URLs are convenient and useful for web designers, and easy to add in browsers. Further, Acid2 assumes that the browser uses a default style sheet with common values. For example, it is assumed that all ‘div’ elements have ‘display: block’. Finally, the test assumes a pixel density of 96 ppi, as per the CSS 2.1 Last Call Working Draft. For user agents that support font zooming, it also assumes a zoom factor of 100%. The list below gives an overview of the most important additional features that are tested:

• Transparent PNGs — The eyes are encoded as transparent PNGs.
• The object element — The eyes of the face are attached to an object element. Being able to use object (which can have alternative content) is one of the oldest requests from web designers.
• Absolute, relative and fixed positioning — Being able to position elements accurately is important for advanced page layouts.
• Box model — The original Acid test focused on the CSS box model. Acid2 continues in this fine tradition by testing ‘height’, ‘width’, ‘max-width’, ‘min-width’, ‘max-height’ and ‘min-height’.
• CSS tables — There is nothing wrong with table layouts. It is a powerful layout model which makes sense on bigger screens. However, the table markup is troublesome as it ties the content to these screens. Therefore, being able to specify table layouts in CSS is important.
• Margins — CSS defines accurate algorithms for how margins around elements should be calculated.
• Generated content — The ability to add decorations and annotations to Web pages without modifying the markup has long been requested by authors.
• CSS parsing — Acid2 includes a number of illegal CSS statements that should be ignored by a compliant browser.
• Paint order — We test that overlapping content is painted in the right order. This is not a feature in itself, but a requirement for other features to work correctly.
• Line heights — The Acid2 test checks a few key parts of the CSS inline box model, upon which any standards-compliant Web page depends.
• Hovering effects — One of the elements in the face changes color when you hover over it. Which one?

It should be noted that Acid2 is rendered in standards mode. That is, the test page includes a DOCTYPE which signals that the browser should treat the page according to standards. Vendors that are reluctant to make changes in how they render legacy documents can continue their current behavior in what is known as quirks mode.

What should appear

Acid2, when rendered correctly, consists of one line of text (Hello World) and a 14×14 grid of squares inside a containing block where a smiley face can be seen. Each square is 12px high and 12px wide. The face has a yellow background with a black facial outline around it. In this section, we will explain how all of this is created.

The text

The string “Hello World!” marks the start of Acid2. It tests basic CSS1 properties. In the source code, it is marked up as an h2 element:

  <h2 id="top">Hello World!</h2>

These CSS declarations apply to the top element:

These declarations are written in CSS1 and most browsers will have no problems rendering this code.

The containing block

The picture of a face appears inside a containing block. It tests a basic part of absolute positioning. In the markup, the containing block is started by this tag:

  <div class="picture">

And these declarations apply:

Row 1

This row is the scalp of the face and it tests fixed positioning, minimum and maximum heights, and minimum and maximum widths. In the markup, the row is represented by a p element which is fixed to the window rather than the scrollable canvas. If the Acid2 page is scrolled, the scalp will stay fixed in place, becoming unstuck from the rest of the face, which will scroll.

In order for row 1 to be positioned correctly, we assume that fragment identifiers cause scrolling to occur up to the top padding edge (or maybe top border edge, that isn’t tested) of the element, and not its top margin edge or top content edge. This is a common convention, but is not described in a specification.

The resulting face fragment can be seen on the left.

Row 2

This row tests attribute selectors, class selectors, absolute positioning, and floating elements. The second row of the face has two black boxes with a yellow box in between. The effect is created by a blockquote element that has an address element inside it:

  <blockquote class="first one">
    <address class="second two"></address>
  </blockquote>

Each of the two elements have class attributes with two values in them. The first element (blockquote) is matched by this selector:

  [class~=one].first.one

The selector has three parts: one attribute selector ([class~=one]) and two class selectors (.first and .one). All parts of the selector match and the following declarations therefore apply:

The width of the blockquote element is not set explicitly and is therefore ‘auto’. CSS 2.1 section 10.3.7 (rule 3) specifies that the width of the element should be determined by the shrink-to-fit algorithm. As a result, the width of the element is determined by its content: the address element.

The innermost element (address) is matched by this selector:

  [class~=one][class~=first] [class=second\ two][class="second two"]

This selectors has two main part with several sub-parts. The first main part ([class~=one][class~=first] matches the blockquote element, and the second main part (class=second\ two][class="second two"]) matches the address element. Therefore, these properties apply to the address element:

The resulting face fragment can be seen on the left.

Row 3

This row tests width, overflow, the universal selector, and data URLs. The row consists of two nested elements. The outer element generates the two black squares of the third line, and the inner element generates the yellow box between the two black squares. The elements are represented by this markup:

  <div class="forehead">
    <div>&nbsp;&nbsp;....</div>
  </div>

Note that the only content in the inner element is   entities (not all are reproduced above) and the content will therefore be displayed on a single line.

The outer div element has these declarations attached to it:

The inner div element is matched by this selector:

  .forehead *

The above selector would match any element within the outer div, but on this page there is only one element; namely, the inner div element which has these declarations attached to it:

The resulting face fragment can be seen on the left.

Row 4-5

These rows constitute one unit. They test paint order and fixed backgrounds. The rows depict a pair of eyes along with the familiar black outline of the yellow face.

In the markup, these rows are represented by a set of nested div and object elements. Here is an outline of the element structure:

  <div class="eyes">
    <div id="eyes-a">
      <object data="data:application/x-unknown,ERROR">
        <object data="http://www.webstandards.org/404/" type="text/html">
          <object type="image/png" data="data:image/png;...">ERROR</object>
        </object>
      </object>
    </div>
    <div id="eyes-b"></div>
    <div id="eyes-c"></div>
  </div>

The eyes appear in the inner object element. The two ancestor object elements should both display their fallback contents — which is the inner object element. The fallback content of the inner object element should not be displayed as the data attribute returns a valid PNG image (depicting the eyes).

The table below shows which declarations apply the elements in the structure:

The resulting face fragment can be seen on the left.

Row 6-9

These rows constitute the center part of the face, including the nose. They test generated content and child selectors.

The element structure is quite simple with three div elements inside each other:

  <div class="nose"><div><div></div></div></div>

These properties apply to the nose element:

The inner div element has generated content before and after it. The generated content constitutes the diamond-shaped nose of the face.

The generated content before the element constitutes the upper half of the nose. These declarations apply:

The declarations set on the :after pseudo-element are identical, except that the bottom border has been swapped with the top border.

The result of stacking two black triangles, one over the other, is that a diamond-shaped nose occurs in the face.

The resulting face fragment can be seen on the left.

Between row 9 and 10

Between row 9 and 10 are several elements with different vertical margins. When positioning the smile element of row 10, it is necessary to calculate how the margins collapse.

Vertical margin collapsing takes place between block-level elements in the normal flow. The table below lists the relevant elements along with their vertical margins.

The height of the empty element and it child is zero. Therefore, all values with a shaded background in the above table will collapse. The resulting margin between forehead to the top of the smile is 0.25em.

However, there is also a floating element between forehead to the top of the smile. Floats do not enter the collapsing margin calculations, but in this case it will effectively override the margins; The top border edge of the smile element is placed flush with the bottom margin edge of the floating nose element.

Row 10-11

These rows constitute the smile in the face and test collapsing margins. Also, the ‘inherit’ keyword and nested floating elements are tested. These rows are represented by this structure, along with a short textual description of each element:

  <div class="smile">    absolutely positions the two rows
    <div>                paints the black facial outline
      <div>              paints the yellow background
        <span>           paints, in part, the upper half of the smile itself
          <em>           paints, in part, the lower and upper half of the smile
            <strong>     gives the smile its width
            </strong>
          </em>
        </span>
      </div>
    </div>
  </div>

The table below details which CSS declarations apply to which elements:

The resulting face fragment can be seen on the left.

Row 12

This row tests the line-height property. In the markup, the row is represented by two nested div elements:

  <div class="chin">
    <div>&nbsp;</div>
  </div>

These declarations apply to the outer div element:

These declarations apply to the inner div element:

The resulting face fragment can be seen on the left.

Row 13

This row tests the parser, cascading mechanism and selectors. After removing some dubious comments, the remaining markup should be like:

  <div class="parser-container">
    <div class="parser"></div>
  </div>

The challenge for browsers is figuring out which declarations applies to the parser element. These declarations do:

This row also tests that the parser correctly ignores parts of the style sheet according to the specification. The table below describes what should be ignored and why:

The resulting face fragment can be seen on the left.

Row 14

This row tests CSS tables. The structure is a simple list:

  <ul>
    <li class="first-part"></li>
    <li class="second-part"></li>
    <li class="third-part"></li>
    <li class="fourth-part"></li>
  </ul>

The style sheet associated with these elements turns it into a table with one row and four cells. Each cell is equal to one square. Here are the elements shown alongside their respective declarations:

The resulting face fragment can be seen on the left.

After row 14

After row 14 comes some elements that should not cause anything visible to be generated. What is being tested here is that table cells honor the line-height property. Here are the elements:

  <div class="image-height-test">
    <table>
      <tr>
        <td>
          <img src="data:image/png;base64,..." alt="">
        </td>
      </tr>
    </table>
  </div>

The image referenced from the img element is a 64×64 red PNG image. It should never be visible due to these declarations:

As a result of honoring the big line-height value, the image is pushed far down. As only the top 10px of the element is visible, the image will be hidden.

Revision history

1. Version 1.1

   • Changed top margin and added relative position value for bottom: to .smile div to compensate for margin collapsing
   • Changed top margin on .chin to compensate for margin collapsing

2. Version 1.0

   • Original test

Contact

Every effort has been made to ensure that Acid2 is correct and that it tests the features in greatest demand. If you find errors in it, think it unfair for any reason, or have other comments, please let us know.

• Acid2 Browser Test
• Acid3 Browser Test
• Small Business Outreach
• Education Task Force
• International Liaison Group
• Previous Campaigns
• Report Browser Bugs
• WaSP Street Team