- From: Mikko Rantalainen <mira@cc.jyu.fi>
- Date: Mon, 12 Apr 2004 18:05:27 -0400 (EDT)
- To: www-style@w3.org
- Cc: Ian Hickson <ian@hixie.ch>
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