Anigozanthos

...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

• Zooming revealing parts of the checkerboard pattern around the eyes. Zooming may not be part of the test, but it seems to me that Opera is being internally inconsistent - using different zooming algorithms for different parts of the display. Maybe zooming algorithms could be made consistent?
  
• Page resizing. Not valid, explained elsewhere.
  
• Fit-to-width. Not valid, explained elsewhere.
  

selector {
  -vnd-property: value;
  -vnd_cmp_ver-property: value;
}

foo {
  display: inline;
  -khtml-display: inline-block;
}

1. The rules are designed to be ignored, i.e. every user agent apart from the one designed to recognize the specified vendor code will ignore it. The only user agent that can be negatively impacted by this is the one programmed to recognize the particular vendor code.
   
2. Self-documenting. One of the major problems with the existing use of CSS hacks is remembering which properties end up applying to which browser.
   
3. Easier maintenance. All vendor-specific declarations start with a hyphen. Pretty much every single CSS file I've seen is formatted with one declaration per line. To find one of these means simply looking for lines where the first non-whitespace character is a hyphen. The overriding rules are also capable of being left exactly where they're needed and don't need to be separate from the normal declarations.
   
4. Precision. Hacks are delivered to a specific property. Browser sniffing and conditional comments often result in a large set of rules being imported. Over time some of the issues in that set may be fixed, others not. Only parser-bug-reliant hacks can currently easily deliver this level of precision, but relying on parsers bugs just should not be acceptable.

1. The validator does not parse vendor-specific extensions correctly, resulting in stylesheets being considered invalid. IMO, they should be considered warnings.
   
2. Coordination of vendor IDs. Problems will exist if different vendors choose the same prefix. This is a general problem with vendor-specific prefixes, not my idea specifically.
   
3. Rules outliving their usefulness. All hacks will live longer than the problems they solve. One of the problems with browser sniffing is that "corrections" can end up being delivered to browsers that no longer need them, causing problems. My idea shares this problem with all other browser hacks, however, I believe the benefits of my idea outweigh the drawbacks of this problem. If a browser issue is resolved, an appropriate "_lt_ver" can be added to the rule.