Re: content: url() is bad

Ian Hickson / 2004-04-12 23:58:

> On Mon, 12 Apr 2004, Boris Zbarsky wrote:
> 
>>>...but when would you ever want a single image on its own _not_ to be a
>>>replaced element?
>>
>>   h1 { content: "foo" }
>>   h1 { content: url(foo) }
>>
>>Should both be replaced elements?
> 
> For the first one I would want h1 to be a block-level element containing a
> line box containing an anonymous inline box containing the text "foo".
> 
> For the second I would want a block-level replaced element rendering the
> resource "foo".
> 
> Why would anything else make sense?

I think that for the second one, I would want h1 to be a block-level 
element containing an anonymous inline-level replaced element 
rendering the resource "foo" (I consider that as the closest match 
possible to math the behavior for plain text). If the property is 
called 'content' it should modify contents of the element, not the 
element itself. I'd rather have "display: replaced" (or 'replace') 
to say that the element should be removed from the flow and replaced 
with all of its childs.

I think it's becoming more and more important to quickly define how 
form elements work with CSS. Should it be possible to change look of 
the form elements? How do you modify the looks of a 'select' (as 
defined in HTML 4.01) or a 'input type="file"'? What's a replaced 
element and how do you morph replaced element to normal with CSS 
only and the other way around?

> Well, it's pretty clear that
> 
>    :before { content: 'PASS' url(404); }
> 
> ...should render "PASS", isn't it?

That might be the behavior of the browsers that currently support 
:before do it. I could easily live with the change that "PASS" 
wouldn't be rendered. I don't expect :before to work right yet so 
making a small change shouldn't matter. In addition, I believe that 
"," isn't allowed in the 'content' property right now, so there 
would be an easy workaround -- I could use something like

:before { content: 'PASS' url(404); }
:before { content: 'TRY' url(404), 'PASS'; }

and achieve improved results with user agents that support this 
extended behavior and fall back to original behavior with user 
agents that don't support this new feature. Or I might write

:before { content: 'PASS' url(404), content; }

to make sure that no content would be generated unless the user 
agent supported this extended specification and it was able to load 
the linked resource. (Arguably, I'd need to specify 'none' or 
'normal' depending on what 'content' ends up meaning with 
pseudo-elements. I believe that it shouldn't matter which selector 
was used to select the pseudo-element so final rules should be made 
so that they are not compliant with :before and :after *only*.)

-- 
Mikko

Received on Tuesday, 13 April 2004 12:46:04 UTC