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

Re: content: url() is bad

From: <staffan.mahlen@comhem.se>
Date: Wed, 14 Apr 2004 15:31:57 +0200
To: Ian Hickson <ian@hixie.ch>
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, www-style@w3.org
Message-ID: <407D596D.22613.1B00C5E@localhost>

On 14 Apr 2004 at 10:02, Ian Hickson wrote:

> On Wed, 14 Apr 2004 staffan.mahlen@comhem.se wrote:
> >
> > When testing with a long alt-text in a broken img, the nowrap of the
> > alt-text used by two of three tested browsers suggests to me that the
> > img alt-text is not handled as if the image was made non-replaced due to
> > its alt-text being used.
> This is considered a bug in Opera, as it makes the text unreadable in
> cases such as:
>    http://ln.hixie.ch/?start=1075242104&count=1
>    http://ln.hixie.ch/?start=1081717954&count=1

In both those cases using the object element seems more appropriate? 

> In any case, if <img> doesn't convince you, try <object>, which is the
> same concept.

I'm not convinced CSS needs to support the same mechanisms that 
object does, due to aiming at different concepts. I also think there 
are some issues with object and interoperability between major 
> Why? What is it about my proposal that doesn't work, in practice?

In practice i think it is likely to work fine, but will produce some 
difficult-to-debug-side-effects. If the box is acts different 
depending on the content property, it will be hard to see what causes 
the height/width/display etc not to "work" without digging into the 
other CSS properties on the element. The effects wont be of the type 
listed under "Applies to:" of theese properties.

By creating a new a property/selector the problem would be more 
confined to this specific feature, and those who wish to create the 
more advanced effects are more likely to know those details. I'm also 
vaguely concerned with how well the feature will interact with future 

> > The reason i prefer to view the content value as replaced is probably
> > that i dislike the concept of having a pseudo-document-fragment in the
> > content value
> Why? It's no more than is allowed on 'content' in CSS2.
IMVHO this is where CSS oversteps its boundries, and mixes layers. I 
agree that creating limited effects in the document tree is quite ok, 
but i think that giving CSS the capabilities of a markup langauge 
makes it unecessarily complex and does not add enough value for this 
cost. To have 'content' be quite as capable as object i suppose you 
need to allow it to contain not a list but a tree, but then again, 
such trees could be built if there was a way to select parts of the 
content value.

> So why make
> the simpler cases more complicated?

IMHO viewing the 'content' property as more of a replaced than non-
replaced feature seems much less complex than viewing the value as a 
similar to a document fragment. The simple cases can be resolved 
either way.

> I still don't know what you mean by that. If you mean "force 'display' to
> 'inline-block' when 'content' has a value other than 'contents'", then the
> problem is that that breaks cases such as:
>    abbr[title] { content: attr(title); }
>    img { content: attr(alt); }
> ...where you _really_ want the wrapping.

Yes i realised that after your last post, but felt it was better to 
make the exception on that end rather than for the single image case 
if such an exception is needed. A content value only holding strings 
could be considered non-replaced if that is really desired, but 
personally i think that such strings probably belongs in the markup 
if they need wrapping and that CSS only needs to be able to do image 
replacement at this point (and doesn't need to explicitly require 
"replacedness" depending on the value of this property). 

I think i've made my position clear enough by now and this is 
probably not a major issue anyway.
Received on Wednesday, 14 April 2004 09:32:36 UTC

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