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

Hi, Bert,

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

Take a look on last background on the image:
http://terrainformatica.com/htmengine/v3/screens/backgrounds.png
It is declared as top/middle/bottom - strteched and left/right - repeated.

If we will define such backgrounds as a function ( tile(url, parameters)  )
I think that it is not a big deal to
add stretching flags for the areas (top,left,right,bottom,middle).
Image tiling is significantly effective than stretching. On big background
areas you will see difference by naked eye.

"...if you want an image at the top and dots at the bottom..."
I can imagine backgrounds which needs stretched tops (or sides) and dotted
(repeatable) bottom.

Andrew Fedoniouk.
http://terrainformatica.com



----- Original Message ----- 
From: "Bert Bos" <bert@w3.org>
To: "W3C Style List" <www-style@w3.org>
Sent: Monday, August 23, 2004 6:36 AM
Subject: Re: Border and background images (Re: CSS Attribute Proposal)


>
> 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
> implemented.
>
> >          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
> -- 
>   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 21:19:57 UTC