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

On Mar 29, 2009, at 6:14 PM, Andrew Fedoniouk wrote:

> Brad Kemper wrote:
>> 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
>
> As more I am looking on this as more I think that complex borders
> are just such a backgrounds. It just foreground-image is what missed
> in CSS.
>
> Even in you nice design you clearly have a layer behind the text and
> layer (lamp and smoke from it) in front of it.
>
> Consider this mockup:
>
> http://terrainformatica.com/w3/lamp.png
>
> It is conceptually close to yours but as you see border and
> background are really non-separable. If to adopt expandable
> background images [1] then such borders with background are
> not a problem.

That is interesting, and your 'background-repeat:expand' does seem  
similar in a lot of ways to border-image. But one the goals of my  
proposal for changes was to have a good way to use regular borders as  
a fallback for border-image when no images load (like in working  
draft, in which a successful loading of the images in border-image  
causes the the regular border to go invisible), while also allowing  
those images to occupy spaces beyond the width of the border-width  
(for important extra design flexibility). It does not seem as though  
'background-repeat:expand' or 'foreground-image' allow either of those  
things.

> Lamp in front has alpha and is drawn as foreground
> image.
>
> My design uses single DOM element with the following style:
>
> #lorem-ipsum
> {
>  background-image: url(back.png);
>  background-repeat: expand;
>  background-position: 20 2 26 2;
>  foreground-image: url(lamp.png);
>  foreground-repeat: no-repeat;
>  foreground-position: bottom right;
>  padding: 48px 50px 80px 14px;
> }

I do like your ability to cast a decorative element in front of the  
content. But borders have always been behind the content, and I don't  
think we should change that (at least as the default). I think if the  
author specifies 'overflow:visible', then we should not (by default)  
let the border obscure what is supposed to be visible.

I also don't like that you have to add a bunch of padding to get the  
effect, and then would need to use some negative margin to get things  
to line up with other elements on the page. Both of those mean a less  
satisfactory fallback for folks without images. This is, I believe,  
where viewing this as a border property instead of a background  
property is conceptually different. If I think of this as a type of  
border, then I want to behave more like a border, in which the most  
border-like parts of the image appear just outside the padding box,  
and the padding and margin would be the same regardless of whether I  
used borders with or without images.


> All this is really very simple and does not require to change any
> layout mechanisms that we have in CSS so far.
>
> This border-images really look good only on paper but when
> you will start using them you will immediately bump into limitations.
> CSS is simply not that tool that is capable to define all possible
> interactions of backgrounds and borders.

Not Nirvana, but it would be very useful this way. I have already  
played around with the implementations in the nightlies for WebKit and  
Firefox, and found that they are very good and powerful, but the main  
limitations I found were the ones that my proposal address. In  
particular, I wanted to correct the problem of larger corner designs  
equating to smaller padding-boxes.

I wouldn't think that this would be too big of a change for CSS, which  
already allows 'outline' to draw outside the box without affecting  
layout, and 'box-shadow' does that too. And even earlier than those,  
we had 'position:fixed', which has one box for taking up space in the  
layout, and another box for painting. I suspect that 'position:fixed'  
is more complicated than 'outline', 'box-shadow', or 'border-image'  
with offsets, as elements with 'position:fixed' can change layout in  
more complex ways.

> I agree that something has to be done here. But border-image appears
> as too complex (in terms of interaction with box model) and not
> a perfect solution anyway.

Do you mean in general, or with regard to the changes I proposed?

>
>
> [1]http://www.terrainformatica.com/wiki/h-smile/expandable-backgrounds
>
> -- 
> Andrew Fedoniouk.
>
> http://terrainformatica.com
>
>
>> Sincerely,
>> Brad Kemper
>> home e-mail: mailto:brad.kemper@gmail.com
>
>