W3C home > Mailing lists > Public > www-style@w3.org > March 2009

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

From: David Hyatt <hyatt@apple.com>
Date: Wed, 25 Mar 2009 14:06:01 -0500
Message-id: <F3630619-C1FB-4B0B-829D-BE39579C4A4D@apple.com>
To: "www-style@w3.org list" <www-style@w3.org>
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)."

I'd like to request that "(but only if the specified image can be  
displayed)" be dropped.  An image can be thought of as having three  
states:

(1) Loading
(2) Successfully loaded
(3) Failed to load

When rendering a box, you start off in state (1) trying to load the  
image.  Before you know whether or not the image has loaded  
successfully or not, you obviously would like to use the values  
specified by border-image for the border widths, since you don't want  
to change size when the border-image finishes loading.

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.

You could argue that until the image has loaded, you should not use  
the widths specified by border-image, but then you're just setting it  
up so that you pop on a successful load instead of on an error.  That  
is obviously not desired.

Please just remove this restriction and make the border widths always  
apply so that ugly visual popping won't occur on failed loads.

dave
(hyatt@apple.com)
Received on Wednesday, 25 March 2009 19:06:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:17 GMT