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

Re: [Backgrounds/Borders] What to do when a border-image fails to ?load

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 1 Apr 2009 15:52:15 -0500
Message-ID: <dd0fbad0904011352ob733d0cl7f397831e04084eb@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org list" <www-style@w3.org>
On Wed, Apr 1, 2009 at 2:14 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> Brad Kemper wrote:
>>> border-image: url(Aladdins_Lamp.png) 4 125 141 44 // 0px 14px 12px
>>> 27px / stretch round;
>> Yes, that works for me (except no third slash before the "stretch round"
>> part). Note that currently in the WD, omitting the second set of numbers
>> means that the image border width will be equal to the border-width property
>> value, which is much less useful that just having a 1 to 1 correspondence
>> between image pixels and CSS pixels.
> It depends on what you're trying to do and whether you're using vector
> images or not. If you want to give the border some texture but not to give
> it shape, then you'd want to match the border-width. I can see the
> usefulness of an easy way to say "use the intrinsic size", but I think
> there should also be a way to say "use the given border-width".
> I'll note that we probably also want to allow percentages for the
> border-image widths here.

How difficult is it to have a keyword *or* a set of lengths there?
Just slap in "intrinsic" and "border" (with "intrinsic" being the
default when nothing is specified), and we've got it.

Taking it just a touch further, make *each length* replacable by one
of those keywords.  That way you can, say, have the sides take on the
border-width, while the top and bottom take on specified, or
intrinsic, widths.  If there are less than four length/keywords, the
missing ones are inferred the normal way (L take R, B takes T, R takes

Agreed on percentages.  I'm not certain why border widths ever dropped
support for percentages.

Received on Wednesday, 1 April 2009 20:52:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:35 UTC