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

Brad Kemper wrote:
> On Apr 9, 2009, at 6:15 PM, fantasai wrote:
>> Ok, this is now in the Editor's Draft:
>> I think I addressed all the comments and suggestions here. Please
>> take a look and let me know what you think.
> By the way, thank you fantasai, for working these ideas into the draft.
> Here are some thoughts and edit suggestions I came up with (additions in 
> green, if you are reading this with rich formatting):

Your formatting seems to be incorrectly applied. Anyway.

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

> I think that if we are looking for ways of simplifying this, we should 
> seriously consider discarding the 4 lengths after the slash idea. It 
> seems to me that it would be exceedingly rare that authors would need 
> anything other than 'border-width', intrinsic dimensions, or a single 
> scaling value of either percentage (such as 50%) or factor (such as .5). 

I would prefer to wait until implementors complain that lengths are
more complicated than they're worth. I'm not convinced that it's a
good idea to take them out.

> And using the border-width is such limited usefulness (only for for 
> thickness-scalable patterns, with corner sections no bigger than the 
> border-width), that it should not deserve the word "auto", especially 
> since there is automatic behavior for when the value is omitted 
> (intrinsic dimensioning).

There's no 'auto' keyword in the draft, there was just that snippet
of a sentence I hadn't deleted yet.

Instead of a 'border-width' keyword I added numbers. So if you just
wanted to fill the border-width, you'd specify
   border-image: url(...) 25% / 1;
But if you had fancy corners, say, a looped corner that's twice as thick
as the border,like this:


you could make the border-image scalable like so:

   border-image: url(...) 25% / 2 / 1;

This says to make the border-image area twice as wide as the border-width
(so that the colored part of the image border is exactly as wide as the
border-width), and then to outset it by the border-width (which places the
loops outside the border box).

>> If two opposite border-image widths are large enough that they 
>> overlap, then their used values are proportionally reduced until they 
>> no longer overlap.
> Does this mean that if the left width is 300px and the right width is 
> 100px, that they are both reduced by the same percentage in order to 
> maintain that 3:1 ratio? I was actually imaging that they would be 
> reduced by the same number of pixels so that they would just meet in the 

Yes, they would maintain the 3:1 ratio. That is more likely to preserve
the intended effect: it only shrinks the end result, instead of
distorting it. (Imagine in your example that the box is only 300px wide.)

> middle, but I'm not sure which way is better. In either case, we should 
> be explicit, including what side an extra pixel should go on if the 
> image is not evenly divisible that way.

The CSS specs don't specify pixel rounding behavior.

>> Negative values are not allowed for any of the border-image values.
> It's occurred to me after watching the thread about 
> animations/transitions that a negative value could be useful for 
> animated or transition effects, especially if the "overshoot and bounce 
> back" effect is possible.

Ok, but I'd like Hyatt's take on this before making a change.


Received on Friday, 10 April 2009 18:28:54 UTC