Re: content: url() is bad

On Tue, 13 Apr 2004, Mikko Rantalainen wrote:
>>>
>>>   h1 { content: "foo" }
>>>   h1 { content: url(foo) }
>
> 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.

The only practical difference would be that you could no longer change the
size of the image, and that a border on the image would no longer go
around the image itself.

Based on cases where I've seen image replacement techniques used, I find
it hard to believe that that is actually what people want.


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

This is being addressed.


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

Very good point. Ok, I won't worry about this too much.


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

That's a reasonable guideline for things like this, yeah. (Computation
from the initial value would obviously still depend on which was used.)

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

Received on Monday, 12 April 2004 18:11:24 UTC