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: Brad Kemper <brad.kemper@gmail.com>
Date: Tue, 14 Apr 2009 10:26:25 -0700
Cc: www-style@w3.org
Message-Id: <73655E82-54C0-4AF4-95A4-02C48BB621B1@gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>

On Apr 14, 2009, at 9:38 AM, fantasai wrote:

> Brad Kemper wrote:
>> On Apr 13, 2009, at 6:32 PM, fantasai wrote:
>>>> ... what would be more useful would be the ability to scale the  
>>>> image edge parts by the same percentages, so that specifying 50%  
>>>> would result in image parts that were predictably half of their  
>>>> original size on the screen (and full resolution when printed).
>>> You're still stuck on this idea that solving the image resolution
>>> problem requires the ability to scale down the image. There are
>>> more appropriate and more general ways to solve this problem, like
>>> using vector images for drawings, or actually associating a
>>> resolution with bitmap images. I'm not disputing that this is a
>>> problem worth solving. I'm disputing that we should solve it here
>>> in border-image by giving explicit scaling factors, and thereby
>>> not solve it everywhere else where it is equally relevant.
>> But why allow scaling based on the border-width, but not allow  
>> scaling based on the original intrinsic width? If changing the the  
>> size from the intrinsic is useful, then it is useful however its  
>> done. But it seems more natural to base the scaling on the original  
>> intrinsic size, and have a good idea that way of whether or not it  
>> is going to end up in even multiples (by choosing 25% or 200%, for  
>> example). This is an important consideration if some of the lines  
>> in the image are straight and the author wants to keep the edges of  
>> those lines in high contrast (i.e. no grey line along side the  
>> black line from anti-aliasing a half pixel).
> Because scaling based on the border-width lets you
> design borders that fit onto CSS border rules,
> whereas scaling by intrinsic width, afaict from
> your comments, is just a hack for increasing the
> resolution of bitmap images.

No, I wouldn't say that. The "hack" is a welcome and useful side  
effect though, and one I am familiar with because I've done it with  
IMG elements to size a black & white image for the screen while  
allowing 300 dpi output to the printer, with no separate printer style  
sheet required to do so.

> If what you're
> proposing is not needed for vector images, then
> we shouldn't be considering it for border-image.

I am saying that scaling is useful for any type of image. Just as you  
might want to use border-width to scale the image for different  
situations, you may also want to scale the image for different  
situations using a method that has more predictable results WRT the  
antialiasing of rasters and (at least equally) intuitive results in  

With 'background-size', it is most useful for percentage size to refer  
to percentage of its container. But with 'border-image' it is most  
useful, IMO, for percentage size to refer to percentage of its  
intrinsic size, due in part to the extra benefits it confers upon  
raster images.

Regardless, scaling images for the border will be useful, its just a  
matter of which is more useful for what percentage should refer to,  
and I think it is more useful and intuitive for sizing according to  
intrinsic size. Even for vector images, I think it would be good to be  
able to look at the results and be able to say something like, "oh,  
that's too big; let's make it three fourths that size", without having  
to multiply the border-width by .75. If my border-width is 3px, I  
would rather write 75% in that situation than 2.25 (especially if I  
wanted to later adjust the fallback border-width without changing the  
border-image sizes, which seems like what might not be an uncommon  
Received on Tuesday, 14 April 2009 17:27:03 UTC

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