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

On Mar 27, 2009, at 8:41 AM, Bert Bos wrote:

> On Thursday 26 March 2009, Brad Kemper wrote:
>> On Mar 25, 2009, at 12:06 PM, David Hyatt wrote:
>>> http://www.w3.org/TR/2008/WD-css3-background-20080910/#the-border-
>>> image
>>>
>>> contains the following sentence:
>>>
>>> "If the slash is present in the property value, the one to four
>>> values after it are used for the width of the border instead of the
>>> ‘border-width’ properties (but only if the specified image can be
>>> displayed)."
>>>
>>> [..]
>>>
>>> If the image fails to load, it's only going to be after trying for
>>> a while, and therefore an implementation honoring the language
>>> above would end up popping back to the original border-widths as
>>> specified somewhere else, but only after the image load has failed.
>>>
>>> It's best for the border-image to just always set the border
>>> widths, even if the image fails to load.  That way on a failure,
>>> the entire box doesn't change size.
>
> If these border widths are never ignored, then it is not necessary to
> have two sets of widths, and we can just as well use the 'border- 
> width'
> property.
>
> It certainly simplifies things, both for authors and for implementers,
> if 'border-image' loses the slash-part. The fallback border if the
> image doesn't load is likely to be rather thick in that case, but  
> for a
> fallback that's maybe not such a big deal.

That would be pretty ugly. Not a reasonable fallback. A big deal.  
However, if we had Andrew's :incomplete and :busy pseudo-classes for  
image data, that would be a good way of dealing with fallback. In  
fact, in that case, you could use "border-width" to determine the  
width of the image-border, allow border-radius to clip if you want,  
and do whatever you want with box-shadow, because then the fallback  
would be dealt with separately (and for IMG and LI and background- 
image too). That actually seems like the best of all worlds to me,  
which should satisfy both sides of the arguments about how image- 
border should combine with box-shadow and border-radius.

> I guess I'm saying: I'm OK with having just one set of border widths,
> whether or not the image loads, but then I want the syntax to reflect
> that, and allow just one set, too.
>
>>
>> Is this mainly a problem with the geometry changing? That is, if the
>> width of the image border were the same as the border-width, would
>> you be able to go in and un-paint the border and repaint it with the
>> image many seconds or minutes later (after the image loaded), without
>> too much trouble? If not, because of the complexities of stacking
>> contexts and such, then maybe "failed to load" should be excluded
>> from the fallback feature of this property, and it should only fall
>> back for "user has images turned off" and "UA doesn't support images
>> or this image type".
>
> An image of the wrong type or an image that fails to load is pretty  
> much
> the same thing: both of these you only know when the server's response
> arrives.

Wouldn't you know pretty early on from the mime-type or content-type  
or something? I guess at least the header would have to load and be  
looked at for that, but still...

Anyway, my primary question was about if it is still a problem to  
comeback in after image loading and unpaint the standard border type  
and then repaint it with images? Or is that fine as long as the  
dimensions don't jump around?

Received on Friday, 27 March 2009 20:14:03 UTC