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

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.
> 
> 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.
> 
> (There can be a difference in the case of images large enough to not fit 
> in one TCP packet, in the sense that the failure may be noticed only on 
> a subsequent TCP packet, but the longest wait is typically for the 
> first packet anyway. And there can be a difference in case the failure 
> to load is not due to the image being absent, i.e., a 404, but due to a 
> network time out.)
> 
> 

I have invented ':incomplete' state flag and pseudo-class for fall-back 
cases.
It is "on" if some data requested by the DOM element is not loaded yet.
"Component" here is an image background or foreground (image of <img> 
element) or content of the <frame> for example.

Thus you could have

#with-fancy-border
{
   border-image: ....;
   border-width: 10px;
}

#with-fancy-border:incomplete
{
   border: 2px solid red;
}

Another state flag and pseudo-class named ':busy' is "on" if
element's "data request queue" is not empty - it is still loading
something.

Beside of handling "border-image-is-not-available" case
these two allow to style cases like "img data is not available"

img:incomplete
{
    background-image:url(for-img-not-found.png);
    width:xx;
    height:yy;
}
img:incomplete:busy
{
    background-image:url(that-spinning-thing.apng);
}

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 27 March 2009 16:36:23 UTC