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

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



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Friday, 27 March 2009 15:41:39 UTC