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

Re: content: url() is bad

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 13 Apr 2004 20:14:49 +0000 (UTC)
To: staffan.mahlen@comhem.se
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, www-style@w3.org
Message-ID: <Pine.LNX.4.58.0404131910190.25979@dhalsim.dreamhost.com>

On Tue, 13 Apr 2004 staffan.mahlen@comhem.se wrote:
> However, my preference was to allow the above to "work". If you stated
> that all elements with a content value were to be considered replaced,
> what would break?

I have no idea what it means for an inline element to be a replaced
element. Or do you mean that 'display' could compute to 'inline-block'
whenever 'content' is not 'contents'?

How would you get the more usual case of text that flows?

> When the author uses a combination of text and imagas and tries to scale
> it at the same time, it might be ok with a UA dependant resolution since
> it such an edge case.

I don't think it's an edge case at all. I think it's a very common case.
For example:

   h1 { content: url(letter-X) url(letter-Y) url(letter-Z) " Company " url(logo); }

...to get:

   [X][Y][Z] Company {(@)}

...or some such.

> Using :before/:after nested with content values that themselves are
> somehow similar to document tree children does seem like a bit of an
> overkill to me.

I'm not sure what you mean by this.

> I really would hate the suggestion that we need a new selector for
> selecting parts of a content value...(oops to late).

I agree... that's why I think you want to make sure the solution addresses
the most typical use cases, which are, IMHO, a replaced element if there
is just one url() and mixed content if there is more than one.

Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 13 April 2004 16:15:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:12 UTC