W3C home > Mailing lists > Public > www-style@w3.org > October 2009

Re: [css3-background] Preparing for Last Call

From: Bert Bos <bert@w3.org>
Date: Tue, 6 Oct 2009 19:49:00 +0200
To: www-style@w3.org
Message-Id: <200910061949.00530.bert@w3.org>
On Saturday 03 October 2009, fantasai wrote:
> I believe I have closed off all outstanding issues with the CSS3
> Backgrounds and Borders module, assuming Bert approves all my recent
> edits. ;)
> If I've missed any, let me know. I'm planning to request Last Call
> publication at the CSSWG telecon next week.
> Here's the editor's draft:
>    http://dev.w3.org/csswg/css3-background/
> Here's the log of changes, with comments, and links to diffs:
>    http://dev.w3.org/cvsweb/csswg/css3-background/Overview.src.html

I've read through the draft to see if we're ready for last call. Below 
are my comments. There is only one serious issue, I think, one that 
fantasai already mentioned elsewhere: what is the best way to scale 
images for the 'round' keyword?

3.5. The 'background-attachment' property

The information in the first three paragraphs is correct in itself, but 
seems to be in a somewhat illogical order. I don't have a suggestion 
for better text, though.

3.6 The ‘background-position’ property

Also not really wrong, but to reduce the amount of syntax people have to 
remember, I still prefer to remove the 3- and 4-valued expressions and 
wait for the generic calc() notation from Values And Units instead.

3.9 The ‘background-size’ property

The text for the 'contain' keyword explains what happens when a 
background image has an intrinsic aspect ratio, but what happens if it 
hasn't isn't too explicit. I think there is only one reasonable 
interpretation, so the text is probably fine. Ditto for 'cover'.

Similarly, the phrase "An ‘auto’ value for one dimension is resolved by 
using the image's intrinsic ratio" strictly speaking doesn't explain 
*how* the ratio is "used," but unless somebody can think of a 
reasonable way to use it that is different from the way we intended, I 
think the text is good enough.

Example XIII

The last example is currently wrong, but may become correct, depending 
on the next issue. If the scaling of the image uses round() instead of 
ceil(), the image will be scaled up to 33% instead of down to 25%. The 
formula gives: X' = 100% / round(100% / 30%) = 100% / 3 = 33%.


The latest editor's draft created one undefined case, viz., when the 
image is wider than 200% of the background positioning area. In that 
case, round(W/X) evaluates to 0 and the formula thus contains a 
division by zero.

A more general problem is that the latest text can cause images to be 
scaled up as well as down, and that may not be optimal for raster 
images. The worst case is an image whose width is just above 50% of the 
background positioning area. It will be scaled to almost twice its 

The worst case of the previous version is an image that is almost 100% 
wide: it will be reduced to almost half its size. However, it is likely 
that a (raster) image scaled down to half its size looks better than 
one scaled to double its size, at least assuming a scaling algorithm 
that interpolates pixels rather than drops them.

Example IV

Depending on the previous issue, the third, fourth and fifth examples 
may need to be reworded. They are currently not correct, but may become 
correct if the preceding formula is reverted to ceil().

3.10 The ‘background’ shorthand property

Re: "where ‘<bg-position>’ must not occur before ‘/ <bg-size>’ if both 
are present." Was that really what we intended? I seem to remember the 
goal was (1) to avoid a "/" at the start of the value and (2) avoid 
ambiguity when several length values follow each other. E.g., the 
current syntax allows

    background: / 100% 0% 0%

which can be read as either

    background-size: 100%;           /* = 100% auto */
    background-position: 0% 0%;
    background-size: 100% 0%;
    background-position: 0%;         /* = 0% 50% */

At least the "not" should be removed. That doesn't preclude a value that 
starts with a "/" (only makes it less likely), but it does avoid 

5.6 Border-image drawing process

The effect of 'round' on border images is to scale them down if 
necessary to make them fit. If the effect of 'round' on *background* 
images is to scale them either up or down (see 3.9 above), then maybe 
the algorithm for border images should do the same, just in case 
somebody tries to align a background to a border.

(If the algorithms are kept different, the current text is wrong, 
because it says "exactly as for ‘round’ in the ‘background-repeat’ 

5.7 The ‘border-image’ shorthand

The grammar seemed to say that border-image-slice could not occur on its 
own, but must always be followed by either border-image-width or 
border-image-outset. That seems wrong, and the example XXVI shows 
otherwise. I changed the grammar in the draft to the following. (If 
it's not correct, I'll change it back.)

    || <'border-image-slice'>
       [ / <'border-image-width'>?
         [ / <'border-image-outset'> ]? ]?
    || <'border-image-repeat'>

  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Tuesday, 6 October 2009 17:49:32 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:40 UTC