The W3C's vague specifications are open to interpretation

A common notation concerning CSS background shorthand or background-position order more specifically is often found in quick discussions. This is due to a simple factor; W3C's recommendations, standards and specifications is independent from user-agents interpretation. How W3C defines is not necessarily how they are applied in the real world (in the case of cross-browser rendering).

For instance, the background-position property specifies the following type:

Value: [ [<percentage> | <length> ]{1,2} | [ [top | center | bottom] || [left | center | right] ] ] | inherit

The Value type may contain either units or keywords or inherit as a valid value for the property.

In the case of units, percentage or length values can be used (in any combination), where one is the lower limit and two is the upper limit for the number of allowed values. In the case of percentages and length values, and where both axes are provided, the x-axis is defined first and then the y-axis (assuming the specification is consistent within itself)

In the case of keywords, top or center or bottom, and/or left or center or right values may be used in any order.

Neither the Colors and Backgrounds CSS2 specification nor the CSS property definitions make it clear, concerning both the CSS background-position order and background shorthand order. What we are left with is to read between the lines.

Similar cases can be found at W3C specifications, and the information presented requires heavily on our interpretation. Having said that, even though the browser makers pseudo-work closely with the W3C team, there is no wonder why some of the ambiguous specifications (ex. Identical tabindex values and group iterations) are implemented either incorrectly or there is a noticeable difference in behaviour cross-browsers. The irony is; after the specifications come out of working drafts into full recommendations, and where the browsers eventually adopt them, it takes quite a long time for the community to find these inconsistencies. Of course, this only results in the development community blaming either on the open or commercial browser makers, or the W3C directly - then we get cases like HTML 5 trying to get into the picture by claiming to get it right this time.