- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 12 Feb 2009 23:22:42 -0800
- To: David Hyatt <hyatt@apple.com>
- CC: "www-style@w3.org" <www-style@w3.org>
David Hyatt wrote: > > On Feb 12, 2009, at 7:22 PM, fantasai wrote: > >> BTW, Hyatt, on a tangential note.. does Webkit implement this part >> # 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). >> and is its effect on layout desired or should it merely be a graphical >> thing? > > I assume you're asking if WebKit handles "(but only if the specified > image can be displayed)." No, we don't. I don't like that part of the > spec. > > We just always set the border widths, and don't check to see if the > image has loaded first. I don't see any situation where the author > would actually want the border box to change size if the image fails to > load. > > Right now our behavior while a border image is loading is to just not > draw any border. That way the image just pops in like any other image > on a page. If the image fails to load, then we'll go ahead and display > the fallback border. I don't like the idea of selectively honoring the > widths specified by border-image, since prior to the image loading, > you'd want to honor the image's widths anyway. Otherwise you could do a > size jump on a successful load, and that would be lame. > > The widths specified by border-image should just always be honored so as > not to create a trap for authors to fall into. Ok, so if that's what you're doing then wouldn't it make more sense to have the border-image widths /not/ influence layout and make the author add space into the padding as necessary? Because this way a browser that supports border-image but doesn't load the image and a browser that doesn't support border-image will give different fallback behaviors. ~fantasai
Received on Friday, 13 February 2009 07:23:24 UTC