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

Brad Kemper wrote:
> 
> 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.

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).

Yes, in very narrow set of design cases you can reuse same borders when
some of images (or other external resources of the element) are not 
available. But in most cases acceptable quality can be reached
only when you have clear trigger that tells you "complete? yes/no".

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.

> 
>> 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.

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

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. 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.

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.

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>.

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.

[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?
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.

> 
> 
>> 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.

> 
> 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?

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.

See, you have: border that is sort of background according to this:
http://www.bradclicks.com/cssplay/border-image/Alladins_Lamp.png
and at the same time you want this border to be drawn on top of
backgrounds and content of other elements. 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.

> 
>> 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.

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

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

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Monday, 30 March 2009 04:51:32 UTC