Re: content: url() is bad

On Mon, 12 Apr 2004, Boris Zbarsky wrote:
>> ...but when would you ever want a single image on its own _not_ to be a
>> replaced element?
>    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

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?

> If they should not both be replaced elements, why are we using the same
> property for two things that are conceptually totally different for
> authors and require two totally separate implementations?

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

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

   img { content: attr(src, uri), attr(alt), none; }

I don't understand how another property would do this. Cound you expand on
your proposal?

>> Agreed, which is why I responded to Anne's suggestion that 'contents'
>> should always be a fallback -- the problem is, I just realised, that that
>> is not compatible with CSS2 'content' on :before/:after.
> CSS2 content on before/after is rather underspecified, so I'm pretty
> sure that just about anything we do will be "compatible" (in that it
> should agree in all the "easy" cases).

Well, it's pretty clear that

   :before { content: 'PASS' url(404); }

...should render "PASS", isn't it?

Which the proposal (minus the special casing for :before that I just
suggested) would not do.

Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.                         `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 12 April 2004 16:58:39 UTC