Re: content: url() is bad

Ian Hickson wrote:
>>h1 { content: url(xyzcompany-logo); }
>>h1 { content: "Logo: " url(xyzcompany-logo); }
>>h1 { content: "\160  " url(xyzcompany-logo); }
>>h1 { content: "\feff  " url(xyzcompany-logo); }
>>h1 { content: url(something) url(xyzcompany-logo); }
>>
>>How would these all render if the company logo fails to load?
> 
> The key is to consider how these would render if the company logo _did_
> load.

Sure.

> The current idea (not in any published spec) is that the first one would
> cause h1 to become a replaced element, and the other four would cause the
> contents of the h1 to be removed

Um.. That's a pretty serious difference between the two renderings, no? 
  In particular, if there is a border on the <h1>, the replaced element 
rendering and the rendering with a zero-width space in there will look 
totally different (the latter will have the border at the width of the 
containing block, the former at the intrinsic width the the image).

In my opinion, that's a pretty radical difference in the behavior of the 
"content" property (and may be better served by having two different 
properties if we really want two widely disparate behaviors like that; 
what if I want to create something a la <input type="file"> with this 
setup, for example?  I'd want it to be a replaced element....)

> So when the first fails, it gets replaced by its contents, but for the
> the three there is no fallback so it just uses what it says.

Again, that's a fairly major difference in behavior for things that are 
called the same and should really act pretty similarly.  Very 
counterintuitive (forget a bit of a pain to implement).

> Do you have a better proposal? I haven't fully thought this through yet.

Well, one proposal would be that if any single piece of content in a 
given grouping (however one defines that) fails, you fall back (to 
something).  I think this makes more sense in general -- the content in 
a "grouping" would be designed to work together.

-Boris

Received on Monday, 12 April 2004 16:06:30 UTC