Re: [css3-background] comments

Bert Bos wrote:
> 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”)

How about reducing it to CSS 2.1 which is the best specification the WG
has made so far (albeit incomplete and sometimes incorrect). Most CSS3
modules only have to depend on CSS 2.1.


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

Unless you define it as:

# <uri> | none [ , <uri> | none ]*

... so you could define one of the images not to be displayed:

  div{ background-image:url(foo), url(bar), url(baz); }
  div:hover{ background-image:url(foo), none, url(baz); }


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

In such cases you can also use 'border-image' and otherwise you probably 
need four different images. Since it is about images, I think it is more 
logical to let the images rule about the number of layers.


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

This is to prevent authoring errors or so? I'm not really convinced this
is useful.


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

If the CSS WG is going to require something it might be nice to require 
browsers to use the same colors for CSS and for images:
  <http://hsivonen.iki.fi/png-gamma/>

... so at least they interoperate.


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

That would be useful actually. I can recall a particular case at the 
moment but I often wanted such functionality. When I started I actually 
expected CSS to work that way. Only repeat from left to right and from 
top to bottom.


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

You could either turn it into a new property or take a look at the use 
cases and take the one that fits best. Leaving it undefined probably 
makes this property unused if browsers don't implement it interoparable 
or browsers do implement it interoparable and every new browser has to 
look at current implementations instead of in the specification. (Like 
with HTML.)


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

Sorry about the syntax, I pressed send to soon.


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

Exactly. This is also something I encounter now and then and I mostly 
solve it by adding some whitespace in the image to move it away from 
'bottom right'. Which isn't particularly nice as it removes the ability 
to reuse the image for other purposes.


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

':css3' and similar are perhaps even more often asked features and yet 
the CSS WG (rightly) doesn't even consider them.

However, I agree that it would be very nice to have for vector images.


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

As Photoshop doesn't generate vector graphics I doubt designers will use 
'border-image' as browsers are not particularly good at scaling.


>> I also think it should say XHTML/XML
>> or just XML.

This was a comment about section 23 as well.


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

Thanks :-)


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

Received on Wednesday, 13 April 2005 17:44:37 UTC