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

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

From: Justin Wood <jw6057@bacon.qcc.mass.edu>
Date: Sat, 21 Aug 2004 03:38:19 -0400
Message-ID: <4126FBEB.7040601@bacon.qcc.mass.edu>
To: Bert Bos <Bert.Bos@sophia.inria.fr>, W3C Style List <www-style@w3.org>

Bert Bos wrote:

>On Thu, 19 Aug 2004, Anne van Kesteren wrote:
>
>  
>
>>>Looking at the above code, imagine what it'd be like if you were to have two
>>>or more separate page elements that required these corners in order for the
>>>page's design to flow properly.  What if, also, those other elements were
>>>different sizes than the original?  That'd be a very big problem, indeed, as
>>>CSS is supposed to eliminate more code than it adds.  This being the case,
>>>problems like this defeat the entire purpose of CSS, which is, need I remind
>>>you again, to make it simpler.
>>>      
>>>
>>You might want to look at the CSS3 Border Module[1]
>>    
>>
>
>Yes, that is indeed the right place, but you probably noticed that that
>draft is quite old. It isn't abandoned, but interest in fancy borders
>seems to have diminished a lot and it didn't seem important to publish a
>new version.
>
>However, seeing this message, maybe there is interest still and we should
>publish another draft, even if it has many loose ends still...
>
>Because there is a rather interesting idea in there:
>
>In fact, in an attempt to reduce the rather large number of properties in
>the old draft[1], and noticing how designers often go about making their
>images, somebody came up with the idea to merge the border and background
>and allow both to be specified with a *single* image, plus four numbers,
>that specify how to cut it into nine parts: four corners, four sides and
>the center part for the background itself. 'Background-repeat' and the new
>'background-size' together then not only specify how the background is
>tiled and stretched, but also cause the four sides of the border to tile
>or stretch to match the background.
>
>The typical application is that you draw a picture of a complete box with
>the desired background and borders at some small size and then you only
>have to specify how it scales or tiles to adapt to differently sized
>boxes. No need to cut it up yourself, the browser will do it for you.
>
>There is probably no need for new border properties at all, this way,
>while (nearly?) all the functionality of the border module is retained.
>Adding four custom corners in particular could be done with just one image
>and one property.
>
>As I said, there are a number of details that we haven't come round to
>defining yet, but one of the possibilities is that, if you specify
>
>    background-image: tile("image.png", 15px, 15px, 15px, 15px)
>
>the presence of a tile() value instead of a url() automatically disables
>'border-style' and causes the outer 15px of the image to be used instead.
>(Unless the image fails to open, in which case 'border-style' is the
>fallback.) Many other syntaxes are possible, but this should give an idea.
>
>
>
>Bert
>  
>

As far as the border module, imo we still need the rounded corner 
features intact, 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.

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?

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)

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.

~Justin Wood
Received on Saturday, 21 August 2004 09:00:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:32 GMT