W3C home > Mailing lists > Public > www-style@w3.org > August 2004

Re: Border and background images (Re: CSS Attribute Proposal)

From: Bert Bos <bert@w3.org>
Date: Mon, 23 Aug 2004 15:36:44 +0200
Message-ID: <16681.62188.869157.713553@lanalana.inria.fr>
To: W3C Style List <www-style@w3.org>

Justin Wood writes:

> As far as the border module, imo we still need the rounded corner 
> features intact,

Yes, I expect that we'll have a 'border-radius' property in some form
or another. Mozilla has already shown that it is useful and can be

>          and I like the suggestion for the "all in one" syntax, 
> *but* to play devils advocate, how would one specify [x] length into 
> padding should not be stretched for padding itself, such as say I have a 
> 3 px wide border, and then 5 px padding...  I create my image with 8px 
> of unstretchable "width wise" image space.
> It can be an issue.

I think it will be overkill to specify more than nine different
regions or to have individual control over the stretching and tiling
of each area. You'll introduce complications for implementers and
users (and for us poor spec writers :-) ), just to be able to handle
some rare cases a little bit better.

If I understand your example correctly, you can probably get very
close to what you want by saying that, instead of 3px border and 5px
padding, you have 8px border and no padding. The outer 8px of your
image will then not be stretched. The disadvantage is that the border
will be too think in the case that the image fails to download and the
fallback border-style is used.

> Also Allowing the individual border properties have their uses as well, 
> what if I want to *just* replace a corner/one side of a border image 
> when my class = [x], or use a repeating background with an imaged 
> looking border?

That's one of the questions we don't have an answer to yet: is it
necessary to specify just one corner or edge as an image, or is it
enough to either have images all around or no images at all. The
argument for the all-or-nothing solution is simplicity: fewer
properties to learn and to implement, smaller datastructures in
memory, fewer interactions between properties (e.g., how do you
connect disparate borders in the corner?). But it means that, if you
want an image at the top and dots at the bottom, you will have to
*draw* the dots in your own image, since you cannot use the built-in
dots of the browser.

At the moment, I'm leaning towards all-or-nothing. Note especially
that what I expect to be the most common case, having a drawn border
on one side and nothing on the other, is quite easy: just draw nothing
on that side.

> Or replace the one side of my border that needs to be a higher res when 
> my content is large (said side looks horrible when scaled to a really 
> large size;  this issue is less needed than others but still valid)

In one of the proposed definitions, the side part of the image is
scaled to the value of 'border-width', so if you have a border of 5px
and you want it to look good on 600 dpi printer, just draw your image
larger, such that the part for the border occupies 25 pixels. Then
it will be scaled down for the screen, but drawn at full resolution
on the printer.

(Note that there are also Media Queries, that allow you to test for
media and resolutions.)

> the individual border image properties I admit would be less used if an 
> "all in one" method existed, but less used does not negate their "use" 
> or need, imo.

  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 Monday, 23 August 2004 13:37:24 UTC

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