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: Sat, 11 Apr 2009 11:11:39 -0700
Cc: David Hyatt <hyatt@apple.com>, Anne van Kesteren <annevk@opera.com>, Bert Bos <bert@w3.org>, "www-style@w3.org list" <www-style@w3.org>
Message-Id: <DA6B58FB-F9E9-4CF7-B5BC-66E03D2FE957@gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>

On Apr 10, 2009, at 11:15 AM, fantasai wrote:

>>> If a slash is present in the property value, the one to four  
>>> values immediately after it specify the border-image widths:  
>>> offsets that are used to divide the border-image area into nine  
>>> parts. If the keyword ‘border-width’ is given after the slash  
>>> instead of length values, then the image sections are scaled to  
>>> the corresponding border-width. If a slash is not present or if  
>>> there are two slashes with no value between them, then the offsets  
>>> are found from the intrinsic sizes of the image slices, with one  
>>> CSS pixel per image pixel for raster images (resolution specified  
>>> in image is ignored). If a percentage is given instead, then the  
>>> images slices are scaled by that amount from the intrinsic size.  
>>> If the image does not have the required intrinsic dimensions, then  
>>> the appropriate border-width is used instead.
>
> I disagree with these changes. Firstly, the resolution mapping of
> one px per image pixel should not be defined here. In general this is
> how images are rendered in CSS, but there are proposals out there
> that would allow an explicit resolution to be applied or the image's
> own resolution to be used, and this text would conflict with those.
> Secondly, if you want a higher-resolution image, using those proposals
> and true high-res images would be much better than applying a squeeze
> factor in border-image.

How about at least the following change (it seems more natural to talk  
about the common cases first, and since the second set of numbers have  
the effect of scaling the image it seems more useful and more easily  
understood if percentages referred to the same intrinsic size  
mentioned in that shorter paragraph):

# If no slashes are present in the property value, or there are two  
slashes with no value between them, then the offsets are found from  
the intrinsic sizes of the image slices. If the image does not have  
the required intrinsic dimensions, then the corresponding border-width  
is used instead.

#Otherwise, if a slash is present in the property value, the one to  
four values immediately after it specify the border-image widths:  
offsets that are used to divide the border-image area into nine parts.  
The four values represent inward distances from the the top, right,  
bottom, and left sides of the border-image area, respectively. If the  
fourth value is absent, it is the same as the second. If the third one  
is also absent, it is the same as the first. If the second one is also  
absent, it is the same as the first. Percentages refer to the  
intrinsic sizes of the image slices (or corresponding border-width, if  
the image does not have intrinsic dimensions). Numbers represent  
multiples of the corresponding border-width.


I don't really see a very strong use case for basing percentages in  
this scaling set of numbers on the border-image area (presumably the  
border-image area before offsets are applied?). It would allow large  
circular corners that scaled with the width and/or height of the  
border box. But 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).
Received on Saturday, 11 April 2009 18:12:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:46:58 GMT