W3C home > Mailing lists > Public > www-style@w3.org > April 2004

Re: content: url() is bad

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 12 Apr 2004 20:26:48 +0000 (UTC)
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: Dave Shea <dave@mezzoblue.com>, www-style@w3.org
Message-ID: <Pine.LNX.4.58.0404122019070.27215@dhalsim.dreamhost.com>

On Mon, 12 Apr 2004, Boris Zbarsky wrote:
>>
>> 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?

Yes. In the last published draft, the syntax was such that you could
specify a list of single <uri>s followed by a single "compound" entry.
People want (apparently) to be able to do the fallback thing even with
compound entries, though.

A _really_ old proposal (we're talking like 1999 or something) that I had
was to have

   content: replaced(foo.png);

...vs:

   content: url(foo.png);

...for deciding if it is a replaced image or not.

Maybe a keyword would be better, as in:

   content: replaced url(foo.png), replaced url(foo.gif), "fo" url(o), "foo";

...but when would you ever want a single image on its own _not_ to be a
replaced element? It's the lack of such use cases that led me to the "it
should be replaced if it is on its own" idea.


> what if I want to create something a la <input type="file"> with this
> setup, for example?

XBL.


> I'd want it to be a replaced element....

No, you'd want it to be an inline-block. A "replaced element" is something
that has intrinsic dimensions and is by definition outside the scope of
CSS. An IFRAME, basically.


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

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.

Maybe the fallback should be defined to only be added for elements, not
:before/:after (since those never have any 'contents').

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 12 April 2004 16:26:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:29 GMT