Re: [css3-background] comments

All seems pretty sound Anne - as ever.

One small note regarding your comments on the 'background-size'
property. Although as you point out, it may not be desirable for
authors to stretch out bitmap images, would the propery not prove
useful when using a vector based image format, which would surely
scale smoothly by design?

Oh and my understanding of repeat-[up|down|left|right] is that you
could position the background to originate at (say) 50% on the x axis,
and repeat-left back to the origin (but not repeating onto the right
hand side of the element). Presumably an enhancement on blanket
horizonal or vertical repeating.

For the WG: If repeat-left|etc. were used, would they be usable in
combination? (So as to specify repeat-up and repeat-left, for
example).

On Apr 9, 2005 1:08 PM, Anne van Kesteren <fora@annevankesteren.nl> wrote:
> 
> I think the specification should have a section that clarifies the terms
> SHOULD, MUST, etc. The rest of the comments I gave per section. I might
> have missed a few bits, I'll reread the draft when it becomes last call.
> 
> * 1. Dependencies with other CSS 3 Modules
> 
> Does it really depend on those modules? I think this section need to be
> revised. Probably on all CSS3 modules as the graph that was produced a
> few weeks ago doesn't seem to be correct. A specification that
> implements the CSS3 Background module does not need the 'rgba' color
> value for example. It would be nice, but it doesn't depend on it.
> 
> * 2.1. Changes from CSS 2.1
> 
> There are new 'border' properties as well. 'box-shadow' wasn't in CSS
> 2.1 either.
> 
> * 5. The 'background-image' property
> 
> # An image that is empty (zero width or zero height), that fails to
> # download, or that otherwise cannot be displayed (e.g., because it is
> # not in a supported image format) has the same effect as a non-empty
> # transparent image.
> 
> Wouldn't it be easier to specify that if an image can't be displayed the
> initial value should be used instead?
> 
> # If 'background-repeat' or 'background-position' has more
> # comma-separated values than 'background-image', the series of values
> # is repeated as needed.
> 
> As the editor's note already mentioned, it makes more sense for
> 'background-image' to determine the number of layer and let all the
> extra values specified be ignored.
> 
> Actually, it might make even more sense to fall back to the initial
> value when one of the properties specifies a layer too much. For
> 'background-image' that would be 'none' if either 'background-repeat' or
> 'background-position' has more comma-separated values.
> 
> # Editor's Note: Conformance properties for an image should be
> # addressed here: MIME type image/*, require support for PNG, refer to
> # profiles…
> 
> I don't think it is up to the CSS WG to require support for images.
> 
> * 6. The 'background-repeat' property
> 
> # Should there also be values of "repeat-up", "repeat-down",
> # "repeat-right", and "repeat-left" for this property?
> 
> What exactly would these values do?
> 
> I think it might be wise to specify how 'space' should work. I am aware
> of a large discussion how 'letter-spacing' should be implemented exactly
> and it would  be nice if this module would specify in more detail how it
> should work. (Personally I think the space at the edge should be halve
> the space that is between the images.)
> 
> * 8. The 'background-position' property
> 
> It would be nice to have a way to position a background from somewhere
> else than '0 0' (top left). Using the 'calc()' proposal to express what
> I mean:
> 
>   background-position:calc(100%-5px) calc(100%-5px);
> 
> ... it would be very nice if that was made possible. Perhaps using '-5px
> -5px' or so.
> 
> Or, to determinate the canvas in which the 'background-image' is drawn.
> Such a possibility would also remove the need for the editor's note in
> section 9 and probably remove the need for section 10.
> 
> * 11. The 'background-size' property
> 
> I'm not sure if this is useful at all. I don't see that a stretched --
> it is a better name, indeed -- image could work out nice and I expect
> authors to not take advantages of the possiblities. This also introduces
> complexity for UAs and all kinds of rounding issues/errors. I suggest
> marking this as a feature at risk if it is desired by the WG to keep it.
> 
> * 16. The 'border-style' properties
> 
> I think this should specify that UAs are allowed to fallback to 'solid'
> if they don't have an appropriate implementation for the specified
> values. I think this might be useful for UAs implementating 'border-radius'.
> 
> * 18. The 'border-image' property
> 
> Again, this makes me wonder how UAs are going to do this "correctly".
> The idea is quite nice, although it seems strange that a 'border'
> property sets the background image...
> 
> * 23. The background of the canvas
> 
> I think the specification should not give any recommendations anymore to
> authors. Most UAs have implemented support for 'background' on the root
> element. (Even Internet Explorer, be it just for 'background-color'.) I
> also think it should say XHTML/XML or just XML.
> 
> * 26. Tests
> 
> How can a basic test suite guarentee interoparable implementations? Test
> suites have to be detailed. I'd argue tests are more important than the
> specification.
> 
> --
>   Anne van Kesteren
>   <http://annevankesteren.nl/>
> 
> 


-- 
http://www.ben-ward.co.uk

Received on Saturday, 9 April 2005 14:57:31 UTC