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

On Mar 29, 2009, at 9:50 PM, Andrew Fedoniouk wrote:

> What to do when some images requested by the element is a separate  
> question. What to do when say 'list-style-image' is not available and
> you set padding already to accomodate it?
>
> As I mentioned already I am using :incomplete and :busy state
> flags to trigger styling for the case when element is either not  
> complete for the moment or will never be complete (when image  
> request got 404).

I am not opposed to having those pseudo classes. I like the idea. They  
just would be needed as much for the border-image the way I am  
proposing it. And the bigger win of my proposal IMO is the increased  
design capabilities and power for decorative borders.

> [..] You may have nice design that rely on the fact that background  
> and border images are both there. And they *will* be used almost  
> always together.
>
> But what if one of them is not available? You have to have better  
> fall-back mechanism.

If border-image images are not available, then border-style would be  
used, with no changes to padding or margin required. But again, I am  
in favor of :incomplete and :busy also. They just are not required for  
border-image in most cases, IMO.

> [...]
> 1) "to cast a decorative element in front"
>
> There are many cases when it is needed. Usually it is about
> semitransparent images. Consider your case:
> http://www.bradclicks.com/cssplay/border-image/Alladins_Lamp.png
> Think if your design will require that smoke from the lamp to
> go over the text. Or as here:
> http://terrainformatica.com/w3/lamp.png

The changes I am proposing to make to border-image really don't have  
anything to do with whether or not the images are in front of or  
behind the content, so I don't think my proposal should be judged on  
that. In the implementations I've seen, they are drawn behind the  
content. But either way, it doesn't change what I am proposing.

> 2) "But borders have always been behind the content"
>
> Borders are not behind the content. They are on top of it.
> You have mentioned overflow:hidden. When content overflows it goes
> *underneath* borders.

Actually, I mentioned overflow:visible, not hidden. And that does not  
go in front of borders in Safari or Firefox (I didn't test in IE).  
This conforms to section 9.9 of "Visual Formatting Model" of CSS2.1  
[1], which states "the background and borders of the element [form]  
the stacking context", and all the descendants stack on top of that.

> And in case of non-trivial borders defined
> by border-image content will go underneath these borders to
> achieve clipping effect. At least in case of overflow:hidden.

I don't think clipping effects are necessarily achieved by painting  
borders over the content, but maybe I am misunderstanding you.

> 3) "we should not (by default) let the border obscure what is
> supposed to be visible."
>
> And here you started talking about borders as backgrounds. That is  
> what I am talking about too - border-images are not borders but
> rather backgrounds. From this point of view background-repeat:expand;
> is not making non-achievable promises - background is background.

I disagree. They can achieve a lot of the same things (just as IMG and  
background-image can achieve a lot of the same things), but  
conceptually borders are primarily things that happen around the  
periphery of the (possibly padded) content.

> And yet. There are elements already that have foreground-image that
> can coexist with background image. <img> and <object> in HTML as an  
> example. It is nice to have ability in CSS to define where
> and how foreground-image is rendered in at least <img>.

I agree. It doesn't have much to do with my proposed changes, and you  
will find the idea controversial from the standpoint of many people  
considering IMG to be content instead of styling, but I agree with you  
on that.

> Such attributes as 'image-orientation' [1] should go to the
> foreground-*** attribute set. And the 'fit' [2] is just one
> more value of
> foreground-repeat: no-repeat | repeat | fill | meet | slice | etc.

If there was a foreground-image property, I imagine it would share a  
lot with background-image.

> [1] http://www.w3.org/TR/css3-page/#image-orientation
> [2] http://www.w3.org/TR/css3-page/#fit
>
>> 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.
>
> I am not sure I understand you here.
> Here is a real background image from my site:
> http://www.terrainformatica.com/res/side-left.png
> How do you propose to use it without paddings?

I didn't mean I would use it without padding. Just that the padding  
would not need to be different based on whether or not images were  
drawable. Your image may not be the best example, since it is not tile- 
able or stretchable that much, and doesn't have anything that would  
really need my proposed changes to the working draft, but if:

• the image was much narrower with just a few pixels to the left of  
the curved corner be stretched horizontally, and
• if you wanted it to stretch vertically to the height of the whole  
element, and
• if you wanted to eliminate the 1px of white on the top and right,  
then..

...it might go a little something like this:

#menu {
     padding:1em;
     border: 7px solid #DEEDE6; /* suppressed by border-image */
     border-top-right-radius: 11px; /* suppressed by border-image */
     border-image:
             url(http://www.terrainformatica.com/res/side-left.png)
	    12 12 0 0  /                 /* slice the image */
	    12px 12px 0 0  /        /* use image pixels as CSS pixels */
	    1px 1px 0px 0px /     /* offset tiles towards outside the border- 
box */
	    stretch stretch;
}


> And by the way this image visually has as a border as a background and
> it is a practical example that non-trivial border is used with non- 
> trivial background almost always. Makes no sense to separate them.

Sometimes it does make sense to separate them. Such as when you want  
to tile the background, but stretch the border. Or you want to tile  
the border, rounding it off to even divisions of the space available,  
but have a different tile size for the background.

>>> 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.
>
> Yeah, that is another argument for background-repeat:expand and use
> of paddings to offset content box properly. Border image *is not* a  
> border, it something that is drawn on perimeter of the background and
> usually it is coupled with the background.

Actually, I meant it as an argument for my proposed changes to what  
was already being implemented in WebKit and Firefox. There is more  
flexibility in decoupling it from background.

>> 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.
>
> Sorry but border is not an outline either. E.g. outline does not  
> participate in hits testing. But border does. How you border image
> solution will handle :hover state?

Those are good questions. I suppose for simplicity anything outside  
the border-box would not participate in hit testing or hover testing.

> It appears as we are again mixing background/content/foreground  
> layers.
> 'box-shadow' by definition casts shadow thus it is moving the element
> on the layer on the front of its static flow siblings.

box-shadow draws a decoration around the periphery of the border-box,  
which does not affect layout, and does not participate in hit tests or  
hover tests.

> See, you have: border that is sort of background according to this:
> http://www.bradclicks.com/cssplay/border-image/Alladins_Lamp.png

Not so much, really.

> and at the same time you want this border to be drawn on top of
> backgrounds

That much does not change anything about the current working draft, or  
the way Safari and Firefox implement this property.

> and content of other elements.

No.

> I am not sure how it will
> fit in that draw-all-backgrounds-then-draw-all-contents algorithm  
> that CSS carved in the stone of the spec already.

Backgrounds and borders are drawn first. This is already part of the  
CSS carved in stone.

>>> 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?
>
> I mean that this border-image in general is not a solution in  
> practical use cases. And you just have proven that.

Hopefully I have proven that a few changes to border-image in the  
Working Draft spec can make it better.

> My background-repeat:expand of course is not perfect. But it works
> without any need to change box model or drawing sequence.

Same with mine.

>
>
>>>
>>>
>>> [1]http://www.terrainformatica.com/wiki/h-smile/expandable-backgrounds
>>>
>>>
>
> -- 
> Andrew Fedoniouk.
>
> http://terrainformatica.com


[1] http://www.w3.org/TR/2007/CR-CSS21-20070719/visuren.html#layers

Received on Monday, 30 March 2009 07:09:38 UTC