Re: content: url() is bad

Ian Hickson wrote:
>>   h1 { content: "foo" }
>>   h1 { content: url(foo) }
>>Should both be replaced elements?
> I don't understand what it would mean for the "foo" case to be a replaced
> element.

The string "foo" has an intrinsic size, no?

> For the first one I would want h1 to be a block-level element containing a
> line box containing an anonymous inline box containing the text "foo".
> For the second I would want a block-level replaced element rendering the
> resource "foo".
> Why would anything else make sense?

Well, having the rendering of an object completely change based on its 
contents is a very backwards logical relationship to me (this is my 
author hat on, now).

> They're not conceputally different. They're conceptually the same. The
> concept is "the content of the element".

To me, replacing the entire element altogether is not "the content of an 
element".  The content of an element are the things that live inside the 

> The "content" of an "img" element is either the image specified by the
> "src" attribute or the text specified by the "alt" attribute, for
> instance.

Again, I'm having a very difficult time getting into this mode of 
thinking; it seems very bizarre to me, as do most modes that exhibit 
discontinous behavior at what should be continuous transitions.

>    img { content: attr(src, uri), attr(alt), none; }
> I don't understand how another property would do this. Cound you expand on
> your proposal?

I don't have a proposal yet.  I'm just pointing out that yours does not 
really map well to what I think of as "content of an element".  Perhaps 
others think differently of "content of an element".

> Well, it's pretty clear that
>    :before { content: 'PASS' url(404); }
> ...should render "PASS", isn't it?

Well.... not sure.  The spec says absolutely nothing about what to do if 
you can't access the resource (and even what it says about media types 
is so vague as to be all-encompassing with enough spin of the sort I've 
seen when people defend their interpretations of the spec).


Received on Monday, 12 April 2004 17:26:39 UTC