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

On Apr 9, 2009, at 6:15 PM, fantasai wrote:

> Ok, this is now in the Editor's Draft:
>  http://dev.w3.org/csswg/css3-background/#the-border-image-property
>
> 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):

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


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

> If two slashes are present in the property value, the one to four  
> values after the second slash represent the border-image outset: the  
> amount by which the border-image area extends beyond the border box  
> on the top, right, bottom, and left sides respectively. If the  
> fourth length 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. Numbers represent  
> multiples of the corresponding border-width.
> 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.

> The syntax is particularly arcane. [...] Comments on this idea, or  
> any others for making border-image easier to understand?


See my comments above about removing the series of four numbers after  
the slash. I think for the majority of the cases, it will be pretty  
simple to write, with only two or three groups of subvalues:

Common:

border-image: <image> <number>

With offsets, adds one more set of 1-4 numbers:

border-image: <image> <number> // <offsets>

Less (probably much less) common, something other than intrinsic:

border-image: <image> <number> / <scaling> / <offsets>

Several people have commented that they would like a way to clip out  
the center part of the image [...] Comments? What would you use?
For myself, I think it is almost unimaginable that I would ever use an  
image that I didn't edit before using, prepping it to be as small as  
possible for its stretching or tiling sides. At that time I would set  
which parts were transparent, and in most cases (for anything other  
than very strictly rectangular images) there would be transparent  
areas along the edges, both inside and/or outside the design. So I  
would naturally make the middle section transparent too, if that's the  
effect I wanted. I realize this can't be done for JPEG, but neither  
can having useful transparency along the outer edges, which means  
solid color (such as white) on those edges and no worse on the inner  
section.

In the interest of not complicating this property further, I don't  
think we need a way to clip out the center part via keyword. It can  
just be there unless clipped in the image editor.