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

Re: [css3-background] Preparing for Last Call

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 06 Oct 2009 12:54:50 -0700
Message-ID: <4ACBA08A.5050700@inkedblade.net>
To: Bert Bos <bert@w3.org>
CC: www-style@w3.org
Bert Bos wrote:
> 
> 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.

Ok, I've tweaked the text there. Let me know what you think.

> 3.9 The ‘background-size’ property
> 
> ...
> reasonable way to use it that is different from the way we intended, I 
> think the text is good enough.

Agreed that it's good enough.

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

The draft explicitly defines round() in this formula to return the nearest
*natural* number rather than the nearest whole number, so it will never
evaluate to zero.

> 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%;
> or
>     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 
> ambiguities.

Good catch! Removed the 'not'. :)

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

Changed "reduced" to "resized". These should certainly be kept consistent.

> 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-source'>
>     || <'border-image-slice'>
>        [ / <'border-image-width'>?
>          [ / <'border-image-outset'> ]? ]?
>     || <'border-image-repeat'>

Yeah, I saw that change. Much, much better.

Thanks for the comprehensive review, Bert!!

~fantasai
Received on Tuesday, 6 October 2009 19:55:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:21 GMT