Re: content: url() is bad

On Wed, 14 Apr 2004 staffan.mahlen@comhem.se wrote:
>>
>>    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?

Why? The two are basically equivalent.


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

It doesn't have to support the same mechanism (i.e. it doesn't need to
support <param>, codebase, pluginurl, etc). However, it does need to
support the same presentation.


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

I'm not convinced... could you give an example that is hard to debug?

If you have:

   ...
   h2#news { content: url(news.png); }
   ...
   h2#navigation { content: url(N) "avigation"; }
   ...
   h2 { border: solid; }

...then admittedly the borders on:

   <h2 id="news">News</h2>
   <h2 id="navigation">Navigation</h2>

...will look different, but isn't it going to be reasonably obvious that
the problem is that one just has an image and one has more than an image?

I guess what I'm saying is that I think the usability benefits (it Just
Works when you want to resize an image) outweigh the problems (that it
will be inconsistent when you use an image vs an image and some text).


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

But by doing this you also make it so complicated that only those who know
the details can actually use it.


> I'm also vaguely concerned with how well the feature will interact with
> future additions.

I don't really see any problems, but if you can think of any specific
concerns, let me know.


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

You mean as apposed to:

   head { display: block; }
   style, script { display: table-cell; }
   body { display: none; }

...?


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

The point is that markup languages *have no capabilities* in the first
place. It is only CSS that enables markup languages to have the default
renderings they do.

Either that, or hard coding, the later meaning that every markup language
has to have a specific UA. That's fine for MathML or SVG, where the
language is pretty rendering-specific anyway, but with languages like
HTML, Docbook, etc, which are much more common in industry, you really
don't want to have to write any more than a default stylesheet.

(The primary use case here is for when CSS is used internally, with the
data never sent over the public wire.)


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

Or using XBL.


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

It's not a document fragment, it's just a list of CSS boxes, like in CSS2.
There is no nesting allowed, no formatting allowed. It's just a list of
text strings mixed in with replaced elements.


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

In the two examples I gave above, the strings *are* in the markup. In both
examples, CSS is needed to do *text* replacement. There are no images
involved, there is no content actually in the stylesheet.

But there could be, and you'd still want it to be non-replaced -- in the
next too groups, you want the same results except for the second group
having a small inline image first:

    abbr[title] { content: attr(title); }
    img { content: attr(alt); }

    abbr[title] { content: url(icons/expanded-abbr) attr(title); }
    img { content: url(icons/image) attr(alt); }

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 14 April 2004 10:00:18 UTC