Re: Minor error in CSS2, section 14.2; 'background'

On Sun, 5 Sep 1999 13:30:06 +0100 (BST), Ian Hickson
(py8ieh@bath.ac.uk) wrote:
> 
> The CSS2 spec says, in section 14.2:
> # For HTML documents, however, we recommend that authors specify the
> # background for the BODY element rather than the HTML element. User
> # agents should observe the following precedence rules to fill in the
> # background: if the value of the 'background' property for the HTML
> # element is different from 'transparent' then use it, else use the
> # value of the 'background' property for the BODY element. If the
> # resulting value is 'transparent', the rendering is undefined.
> 
> I believe there is a slight error in this paragraph, in that every
> occurance of 'background' should actually read 'background-color'. 
> 
> The 'background' property cannot have the value 'transparent', since
> it is a shorthand property.

It can have the value 'transparent', which is the same as 'transparent
none' and many other things ('fixed', 'repeat', '0% 0% none', etc.).
However, I think the paragraph meant to say that all the properties
represented by the background shorthand property be at their default
values (or perhaps just background-color and background-image).

Some discussion over DOM2 [1] tried to address the issue of what value
should be returned when querying the current value of a shorthand
property, but I realize now that the current solution (the shortest
form possible that is equivalent to the current state of the relevant
longhand properties) is inadequate for the background property when all
te longhand properties are their defaults.  Perhaps CSS needs a more
formal concept of shorthand-property equivalence so that we don't
continue to be confused over the meaning of "is" :-).

> Furthermore, if the BODY background value is used when the HTML
> element's 'background[-color]' value is transparent, then you get the
> peculiar result that the following:
> 
>    HTML { background: url(logo.png) no-repeat top right; }
>    BODY { background: white url(paper.png) repeat; }
> 
> ...would result in no logo.

...not if you don't replace 'background' with 'background-color'.

> I suggest that the errata include an item saying that fourth paragraph
> should be changed to read:
> # For HTML documents, however, we recommend that authors specify the
> # background for the BODY element rather than the HTML element. User
> # agents should observe the following precedence rules to fill in the
> # background: if the value of the 'background-color' property for the
> # HTML element is different from 'transparent' then use it, else use
> # the value of the 'background-color' property for the BODY element.
> # If the resulting value is 'transparent', the rendering is undefined.

I suggest, instead, that the paragraph be changed to read:

# For HTML documents, however, we recommend that authors specify the
# background for the BODY element rather than the HTML element. User
# agents should observe the following precedence rules to fill in the
# background: if the value of the 'background-color' property for the
# HTML element is 'transparent' and the 'background-image' property for
# the HTML element is 'none', then derive the actual value of each of
# the following properties on the HTML element from the computed value
# on the BODY element and derive the actual value on the BODY element
# from the computed value on the HTML element: 'background-color',
# 'background-image', 'background-repeat', 'background-attachment', and
# 'background-position' (where the actual values must be recomputed
# based on the size of the HTML element).  If, once this is done, the
# actual value of 'background-color' on the HTML element is
# 'transparent', then the rendering is undefined.

The reasons I chose the above rule are:

 * The values should be interchanged (rather than the HTML values being
   replaced) so that background-images tile correctly.

 * The rendering is undefined even if 'background-image' is not 'none'
   because the image can have transparency.

 * 'background-position' must be recomputed so it works correctly

 * The changes must be to actual values rather than computed values so
   forced inheritance (using 'inherit') behaves correctly.

I think, BTW, that a further addition to the errata for
background-position is needed so that it behaves correctly.
Percentages for 'background-position' on the root element should be
relative to the canvas, not the element's box, since the background
covers the entire canvas [2].  (I assume that the canvas is scrolled in
a typical browser, rather than containing scrollbars.)

David

[1] I began two threads on the topic:
  http://lists.w3.org/Archives/Public/www-dom/1999JanMar/0054.html
  http://lists.w3.org/Archives/Public/www-dom/1999JanMar/0099.html
[2] http://www.w3.org/TR/REC-CSS2/colors.html#q2

Received on Monday, 6 September 1999 22:16:33 UTC