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

   border-image: ....;
   border-width: 10px;

   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

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


Andrew Fedoniouk.

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