Re: content: url() is bad

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