Here are some notes on my tests.

1. table-values-000

   This test focuses on the support for table values. CSS 2.1 specifications state that

   "The :before and :after pseudo-elements inherit any inheritable properties from the element in the document tree to which they are attached" and "In a :before or :after pseudo-element declaration, non-inherited properties take their initial values".

2. table-values-001

   Same as table-values-000. In this test we use the 'inline-table' value.

   Note: 'inline-table' is a valid CSS 2.1 value.

3. pseudo-elements-000

   Here we test the interaction between the :before and :after pseudo-elements and the :first-line pseudo-element. This is an aspect of the specs that is not perfectly clear.

4. pseudo-elements-001

   Same as pseudo-elements-000.

5. replaced-elements-000

   This test focuses on the insertion of an image before the main content of an element (which is also an image). Both images are identical and should have the same dimensions and vertical alignment. The parent element has stated dimensions, which are equal to the height of a single image and to their total width (100px x 2).

6. content-url-000

   Here we test the 'content: url()' syntax, in order to check if a UA is able to recognize a file without an explicit extension, based only on its content.

7. content-char-000

   This test focuses on the positioning of generated content. The figures provided should be aligned on the same baseline.

8. content-computed-000

   This test focuses on the computed value of the 'content' property. The JavaScript used here is pretty simple:

      function showStyle() {
    var elem = document.getElementById("content");
    var computedStyle = window.getComputedStyle(elem, "");
    var content = computedStyle.getPropertyValue("content");
    var p = document.createElement("p");
    p.innerHTML = content;
    p.style.backgroundColor = "#0c0";
    p.style.color = "#fff";
    p.style.padding = "1em";
    p.style.font = "bold 1em sans-serif";
    elem.appendChild(p);
      }
      

9. counter-increment-computed-000

   Test on the computed value of the 'counter-increment' property. The JavaScript used here is pretty simple:

      function showStyle() {
    var elem = document.getElementById("content");
    var computedStyle = window.getComputedStyle(elem, "");
    var content = computedStyle.getPropertyValue("counter-increment");
    var p = document.createElement("p");
    p.innerHTML = content;
    p.style.backgroundColor = "#0c0";
    p.style.color = "#fff";
    p.style.padding = "1em";
    p.style.font = "bold 1em sans-serif";
    elem.appendChild(p);
      }
      

10. counter-reset-computed-000

    Test on the computed value of the 'counter-reset' property. The JavaScript used here is pretty simple:

       function showStyle() {
     var elem = document.getElementById("content");
     var computedStyle = window.getComputedStyle(elem, "");
     var content = computedStyle.getPropertyValue("counter-reset");
     var p = document.createElement("p");
     p.innerHTML = content;
     p.style.backgroundColor = "#0c0";
     p.style.color = "#fff";
     p.style.padding = "1em";
     p.style.font = "bold 1em sans-serif";
     elem.appendChild(p);
       }
      

11. content-char-001

    This test focuses on special characters inserted via the 'content' property. There should be two identical Greek fragments on the page.

    Note: The fragment is by Sappho. It means "The stars around the beatiful moon". The pronunciation is " 'asteres am'phi 'kallan se'lannan " and it should be similar to the Italian one.

12. counters-display-000

    Test on counters and the 'display' property set to 'none'. Such declaration should reset a counter on the specified element.

13. counters-visibility-000

    Test on counters and the 'visibility' property set to 'hidden'. Such declaration should not reset a counter on the specified element.

14. counters-pseudo-elements-000

    This test focuses on the interaction between pseudo-elements (:first-line) and counters. This is a not-well defined issue.

15. counters-dynamic-000

    Test on dynamic counters inserted via the DOM. The JavaScript code used here is pretty simple:

      function insertRules() {
     var styleRule1 = document.styleSheets[0].insertRule
     ("ul {counter-reset: item;}", document.styleSheets[0].cssRules.length);
     var styleRule2 = document.styleSheets[0].insertRule
     ("li {display: block;}", document.styleSheets[0].cssRules.length);
     var styleRule3 = document.styleSheets[0].insertRule
     ("li:before {counter-increment: item;}", document.styleSheets[0].cssRules.length);
     var styleRule4 = document.styleSheets[0].insertRule
     ("li:before {content: counter(item)'. ';}", document.styleSheets[0].cssRules.length);
       }
       

16. counters-display-001

    Test on counters and the 'display' property set to 'none'. Such declaration should reset a counter on the specified element. This time we test the interaction with the 'counters()' function.

17. counters-visibility-001

    Test on counters and the 'visibility' property set to 'hidden'. Such declaration should not reset a counter on the specified element. This time we test the interaction with the 'counters()' function.

18. counters-style-000

    Test on the style of counters. Although CSS 2.1 allow the values 'disc', 'circle' and 'square' for counters, the rendering is obviously undefined, since a counter should not have a graphic symbol but only a number. Numbers belong to well-known numeric systems, but other glyphs depend on the UA rendering conventions. Opera does not show the bullets, since this is perfectly meaningless in a numbering context.

19. counters-style-001

    Test on the style of counters. More precisely, this test focus on the values 'lower-alpha' and 'upper-alpha'. Note that CSS 2.1 encourage authors to use true numbers instead of alphabetical letters, since the rendering after the last letter of an alphabet is undefined.

20. counters-exac-000

    This is an advanced test on counters. The following CSS needs a further explanation.

      div[id="exac"] {
     counter-reset: bit0 -1 e2 total e10 -1;
      }
    
      span[class="bit0"]:before {
     counter-increment: bit0;
     content: counter(bit0);
      }
    
      span[class="bit1"]:before {
     counter-reset: bit1;
     counter-increment: bit1;
     content: counter(bit1);
      }
    
      sub[class="e2"]:before {
     counter-increment: e2 2;
     content: counter(e2);
      }
    
      span[class="total"]:before {
     counter-increment: total 15;
     content: counter(total);
      }
    
      sub[class="e10"]:before {
     counter-increment: e10 11;
     content: counter(e10);
      }
      

    The first group of declarations creates a general scope for all the counters used inside the #exac element. The counters named as 'bit0' and 'e10' have a negative value. When incremented, the first have the value 0, while the latter will be incremented by 11 and have the value 10 (11-1). The 'counter-increment' property set in the 4th and 5th blocks has a specific value (2 and 15, respectively), so all the instances of those elements get these values. The third block focus on a particular feature of the current implementations used by most UA. According to specs, an element can always reset and increment a counter on itself. Although this is perfectly correct, most UA will not increment the counter on all the instances of the element, so we get the same number for all elements (1 in this case).

21. content-attr-000

    This test focuses on the 'attr()' function of the 'content' property. The element targeted has a class with a special character (@). UA should insert this value.

Here are some FAQs about my tests.

1. What are "real tests"?

   The word "real" comes from www.hixie.ch/advocacy/testing-methodology where Ian Hickson explains in great details all possible combinations of tests. My tests focus on the "real world coverage", that is, some of the possible combinations of CSS features normally used for building a layout. Real tests fall usually in the category of "advanced tests" (W3C terminology). They are not minimal test cases, but they may be used to build these ones.

2. Is the CSS code used in your tests valid?

   Yes, except the "Feel Like Lynx" demo, where I use -moz-binding in order to stop the scrolling behaviour of the marquee element in Firefox. This is a good example of user stylesheet.

3. I've seen your tests with Mac and Linux. They are pretty different. Why?

   That's probably due to the different screen resolution. Consider the fact that in some tests I use the Ahem font (www.hixie.ch/resources/fonts), so for a correct view you should install this font first.

4. Why IE is not reviewed?

   Because IE (version 7 and lower) is affected by the hasLayout property. That means that IE has two different layout engines. hasLayout affects most of the CSS properties used in these tests (float, positioning, etc.). When IE drops its support to this property, it will be inserted in the browsers list.

5. But IE is the most used browser on the Web!

   I'm not interested in the campaigns pro/anti Microsoft's IE. What's more, I'm not interested in any kind of test that shows only the bugs of one browser.

6. You should not ignore the fact that IE has so many bugs...

   That's true. But if you take a closer look at the site of Gerard Talbot (http://www.gtalbot.org/) you'll probably notice that also other browsers have al least one or more bugs. Take for example this test: http://www.css-zibaldone.com/test/css21/floats/advanced-layout-10/ If you point IE7 to that URI, you'll see an horizontal scrollbar that should not be there. The interesting point is that also Netscape 7.0 had the same problem with this kind of layout. Time passes, browser change and their CSS support improves. It's only a matter of time.

7. Are you aware that doing so your tests are not so "real"?

   Maybe they are not "useful" from the "copy-and-paste" point of view, since they are all prototypes that should be adapted to your own needs. But, as I believe, you are an intelligent and skilled person who knows how to make them work also in other scenarios, so you won't have any kind of problem with these tests. For example, the first thing you could do is to remove the XML prologue in order to prevent IE6- from switching to quirks mode. Then you might always use the conditional comments for the debugging, giving IE its own code. Remember that almost all IE6-'s rendering bugs depend on having or not having layout. See http://www.satzansatz.de/cssd/onhavinglayout.html and http://www.positioniseverything.net/ for further details.

8. Maybe neither a browser developer would find your tests useful. Are you aware of that?

   Perfectly aware. I'm not so conceited ^_^. I know also all my limits, mainly those concerning the lack of precision in using a scientific method. Anyway, I like to share my little knowledge with other people. That's all.

9. Why do you use XHTML 1.1 and serve it as text/html?

   That's because IE7 (and lower) doesn't support any kind of XML-based MIME Type. I don't want to prevent IE's users from viewing my tests. It's a matter of accessibility.

10. Coming to accessibility, your tests don't look so accessible...

    Yes, but this is not intentional. I'm really concerned about accessibility problems. In fact, on my site I use only a color contrast approved by the Colour Contrast Analyzer of the W3C. As said before, my tests are only demos, and obviously I'll have to change my approach if I want to use them for some live projects. For example, in my image map I've used an ordered list to respect a progressive enumeration of the links. That's fine for screen readers and textual browsers. But using 'display: none' inside the list items is not so fine, so this is a thing that should be changed.

11. So what a browser should do to pass these tests?

    A browser should take the provided images as a reference. Obviously there could be some differences, mainly those concerning the user interface and the environment. For example, Safari has a different rendering of some form elements. That's not important. Anyway, a browser should *not* break the layout. That's important.

12. Where does your inspiration come from?

    Mainly from real features that I've seen on the Web. For example, the "CSS Button" demo comes from an image found on the W3C site. The "Foo Fighters" demo comes instead from an LP cover of my CDs collection. Building such layouts is a challenge to me.

13. When I change the screen resolution or change the font size, your demos are sometimes destroyed. Is this normal?

    Yes. My starting screen resolution is 1024x768, so it's absolutely normal that a browser has to change its rendering when this or other factors are modified by the user. It doesn't mean that the test fails under such conditions.

14. Is the XHTML code valid?

    I use a local validator to check if my pages are valid, since my site is static and I have to upload the new pages every time. However, there could be some discrepancies, especially between the declared encoding (UTF-8) and some characters used in the code. This is a trivial thing to fix. Simply, validate every page, note the errors occurred and fix them.