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

Re: border-image and border-widths

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 11 Mar 2009 10:13:10 -0700
Cc: David Hyatt <hyatt@apple.com>, "www-style@w3.org WG" <www-style@w3.org>
Message-Id: <8DB87BCE-81A4-4E48-9292-B272606D7A37@gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>

On Feb 13, 2009, at 12:22 AM, Brad Kemper wrote:

>
> On Feb 12, 2009, at 11:22 PM, fantasai wrote:
>> David Hyatt wrote:
>>> 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
>>
>
> I like that idea. It would also allow you to have image-based  
> shadows without getting into negative margins. You could even say  
> that the excess width did not capture clicks.

fantasai, I think you are saying that if the border-image didn't  
affect layout, then images wider than the original border would share  
a common outer edge and move inward from there, overlapping content if  
the padding was not thick enough to avoid that. That would be one way  
(and is very interesting, allowing for wide corner designs that  
extended further into the box than the corner where the contents start).

That has its advantages, but I would like to see the images extend in  
the other direction. Namely, that if the images are wider or taller  
than the border-width, then they would go outward from the padding- 
box, without taking up any space beyond what the border-width  
specifies. Thus, the author would be concerned about margin instead of  
padding. This would be very advantageous for many designs. Consider  
for instance, an auto-width box with a 4px border, in a narrow, fixed- 
width container. You want to replace the border with an image of a  
rope border, but with loops at each corner. You want the rope to be  
4px wide, to match the original border, but you need wider images to  
get the loops in there. But you don't want the content box to get  
narrower. You just want the loops to extend out beyond the box without  
affecting layout.

There are many designs where having a strong grid is good and having  
parts (such as border parts) poking outside that grid is even better.  
This would allow that, and also allow such things as artist-created  
shadows and glows in the images to be exactly where the artist wants  
them, without resorting to negative margins that could mess up the  
fallback version.

Ideally, there would be a keyword added to the border-image property  
to indicate what should happen to the difference between the image  
dimensions and the border-width. Something like this, perhaps:  
[ outward | inward | replace-width ], in which "outward" and "inward"  
would result in the excess image pixels extending outward or inward  
from the border's position, without affecting layout, and "replace- 
width" would act like it is currently specified to change the layout.


>
>
> I've uploaded a new sample of a plain border with a box-shadow (the  
> preferred fallback version), and the same box with a image-border  
> (but no box-shadow, because it messes it up currently).
>
> I would want the fallback version to work whether the shadow in the  
> second one was created the way I did, or generated by the UA. I like  
> the one I created better than what a UA could do though. I have some  
> shadows at different distances than others (which an automatic UA  
> algorithm wouldn't be able to do), and some objects casting shadows  
> on other objects within the same image (which would be pretty tough  
> to match up right to a UA-generated border around the whole image.
>
> You can take a look here:
>
> http://www.bradclicks.com/cssplay/bones_border/bones.html
>
> PS. There is some negative margin trickery on an inner element to  
> get the text to appear to have padding that is less than the width  
> of the image borders, so that I could chunk the image with bigger  
> corner pieces than I wanted for padding. I actually used border  
> instead of padding to accomplish that, since the border width would  
> be changed anyway. I don't know another way to accomplish the same  
> thing.
>
> The border-width is about half of the image-border's "border width".  
> If the excess did not effect layout (as fantasai's suggestion,  
> above), then the layout around the fallback version would be  
> unaffected.
>
Received on Wednesday, 11 March 2009 17:13:55 GMT

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