- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 06 Oct 2009 12:54:50 -0700
- 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 UTC