W3C home > Mailing lists > Public > www-style@w3.org > April 2005

Re: [css3-background] comments

From: Bert Bos <bert@w3.org>
Date: Tue, 12 Apr 2005 22:52:49 +0200
To: W3C CSS List <www-style@w3.org>
Message-Id: <200504122252.49317.bert@w3.org>

On Saturday 09 April 2005 14:08, Anne van Kesteren 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.

You're probably right. The current list is 

  - General Syntax [CSS3SYN] 
  - Values and Units [CSS3VAL] 
  - Cascading and Inheritance [CSS3CASCADE] 
  - Box Model [CSS3BOX] 
  - Color module [CSS3COLOR]
  - Absolute Positioning Module [CSS3POS] (in particular the section
    “Elaborate description of Stacking Contexts”) 
  - Paged Media [CSS3PAGE] (breaking elements across pages) 

How about reducing it to

  - Box Model (we need content edge, padding edge and border edge)
  - Absolute Positioning (in particular the section
    “Elaborate description of Stacking Contexts”)

> * 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?

The initial value is 'none', i.e., no image at all. If there is a stack 
of five images and one of them fails or turns out to be zero by zero, 
do you want to remove the other four as well? That seems a bit drastic.

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

I think I also like it better to make 'background-image' determine the 
number of layers: you only have to look in one place to know how many 
there are. But there is the case where you want a single image in 
multiple places (for example, one in each corner) and then you only 
need to specify it once. We'll see.

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

Yes, I think we considered that possibility, too. It is easy to specify 
and to understand, but hardly ever useful. If you have too many images, 
they are all tiled.

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

I think it is, although maybe not in this draft. SVG includes such 
requirements and they turned out to be a big help in reaching 
interoperable implementations quickly. SMIL doesn't, and although there 
are several implementations of SMIL itself, there is almost no overlap 
in the video and audio formats they support, making SMIL rather less 
useful. (Can't blame the SYMM WG for that though: almost every audio 
and video format is patented...). We are lucky that browsers already 
supported JPEG, GIF and PNG (mostly) before CSS, but on other platforms 
than desktops, such support cannot be taken for granted.

> * 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?

They would put one image at the 'background-position' and then repeat up 
from there, but not down. But I think there are no actual use cases for 

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

I agree that being more specific is a good thing. I just don't know yet 
what the right answer is: the final image against the edge, half the 
space away from it or a full space away from it?

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

If we decide to introduce expressions, that would indeed make it 
possible. (Just '-5px -5px' doesn't work. It positions the image a 
little above and to the left of the top left corner.)

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

Something like

    background-position: NW 0% 0%, SE -5px -5px

to put the first image in the top left (northwest) corner and the second 
a little inside the bottom right (southeast) corner?

Need to think about that more...

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

This is one of the most often asked for features. The image may be 
adapted to a particular font size, thus the size should be a number of 
ems, not pixels. Or you want exactly one image, no matter what the size 
of the box.

Yes, there are rounding issues, but no worse than with any other 
properties (or with foreground images, for that matter).

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

Let's first see if they indeed can't support the other values. There is 
time enough to relax requirements at the end of the CR period...

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

Many designers appear to work by drawing background and border in one 
image (in Photoshop or similar) and then cutting the image up and 
making an HTML table out of it. Cutting the image and using CSS 
properties instead of a table is an improvement, of course, but having 
a single property that avoids having to cut up the image in the first 
place seems even more attractive. It's faster to download, too.

We thought of making a shorthand to set background and border, but just 
putting another background in front appeared easier.

You don't have to use 'border-image' to create image borders: a lot of 
"borders" can in fact be made with multiple background images. Some 
things work better with one method, other things with the other.

The confusing part is indeed that 'border-image', despite its name, can 
also set the background, and that 'background', despite its name, will 
be the preferred method for many designers to create borders...

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

The recommendation to use BODY isn't there because browsers have trouble 
with the root element (they indeed support the root element fine now), 
but it is to have some hope that author style sheets and user style 
sheets cascade well. (A faint hope, of course, because most authors 
don't read the spec, but some tool implementers might.)

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

That section will most likely be removed. There will be a test suite, 
but it will not be contained in the spec. It will be separate, like the 
other CSS test suites.


PS. Very good comments, b.t.w. Thanks!

  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, 12 April 2005 20:52:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:17 UTC