- From: Bert Bos <bert@w3.org>
- Date: Tue, 6 Oct 2009 19:49:00 +0200
- To: www-style@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%.
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.
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
size.
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%;
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.
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’
property.")
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'>
Bert
--
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