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

On Mar 29, 2009, at 2:40 AM, Brad Kemper wrote:

> On Mar 28, 2009, at 7:54 AM, David Hyatt wrote:
>
>> On Mar 28, 2009, at 8:17 AM, Anne van Kesteren wrote:
>>
>>> On Fri, 27 Mar 2009 17:58:52 +0100, David Hyatt <hyatt@apple.com>  
>>> wrote:
>>>> Yeah, I guess I'm saying "let's just drop the ability to set  
>>>> border widths from border-image."
>>>
>>> Then you always have to set two properties. Is it worth  
>>> considering making border-image a special form of border-style?  
>>> That does not work for the border-*-style properties, but the same  
>>> applies to resetting border-image by setting border. As a bonus it  
>>> would make it easier to allow specifying some kind of fallback in  
>>> case the image fails to load, cannot be decoded, is not supported,  
>>> etc.
>>>
>>
>> I don't really care how this is solved.  I just don't like what's  
>> in the spec now, since snapping to different border widths just  
>> because an image failed to load does not seem like what any author  
>> or user would want.
>>
>> dave
>
> I written up a proposal that I think solves this problem, plus a  
> couple others that I think are even bigger for authors. I'd  
> appreciate it if everyone could take a look and let me know what you  
> think. In the following link, I describe three problems (including  
> this one), and a nice solution that I would love to see implemented:
>
> http://www.bradclicks.com/cssplay/border-image/Thinking_Outside_The_Box.html
>
>

I really love this proposal.

I can't implement it in WebKit until we drop the -webkit-, since it  
would break content all over OS X.  :)   The problem being of course  
that apps use -webkit-border-image and expect it to specify the border  
widths.  Since the images are guaranteed to be present (OS X resources  
after all), they didn't bother with fallback border widths.  Therefore  
changing the -webkit- version of the property to match this proposal  
isn't really possible. (I guess I could make a -webkit2-border- 
image... LOL)

I completely agree with the points though that:

(a) The nine-piece slice needs to be independent of the real border  
width of the box.
(b) The nine-piece slice needs to be allowed to specify its own  
inflated (deflated?) box.

If border-image can't alter the actual border-width of the box, then I  
think that is ideal, since it effectively *forces* the author to do  
fallback correctly by making them have to specify the real border- 
widths.  Sure, it's a bit more verbose having to specify two  
properties, but in this case I think it's good that the author has to  
do that.

Without this proposal being implemented, authors are going to resort  
to multiple background hackery to solve (a), which is something we  
don't want, and they'll end up using additional DOM elements to do  
(b), which is really something we don't want.

Should negative offsets be allowed for (b)?  I don't see why not, but  
just thought I'd ask, since your proposal doesn't really say one way  
or the other.

Anyway, I think this proposal is great and hope the WG will adopt it.

dave
(hyatt@apple.com)