W3C home > Mailing lists > Public > www-style@w3.org > July 2001

Re: replaced inlines [was: vertical-align content-generated image?]

From: fantasai <fantasai@escape.com>
Date: Wed, 04 Jul 2001 15:22:47 -0400
Message-ID: <3B436D07.6164D68C@escape.com>
To: www-style@w3.org
Ian Hickson wrote:
| 
| On Tue, 26 Jun 2001, fantasai wrote:
| > Ian Hickson wrote:
| > | In the context of the [CSS2] content property, the
| > | same applies: |content: ''| takes up room (just like
| > | an empty inline) and |content: none| or whatever it
| > | ends up being called just doesn't exist in the
| > | rendering tree.
| >
| > The fact that you're taking the box itself out of the
| > rendering tree means you're fiddling with something
| > other than the box's content.
| 
| That's a very poor explanation, I'm sorry. It only
| works for generated content, and not in the context
| that we are speaking about. Let me try again, this
| time covering the extended 'content' as well:
| 
| In the context of the extended content property, if
| you have <div/> in your document, then:
| 
|    div { display: block; content: none; }
| 
| ...is the same as <div/>, whereas
| 
|    div { display: block; content: ''; }
| 
| ...is the same as <div><span/></div>. The first has an
| intrinsic height of 0, whereas the second has an
| intrinsic height equal to the line height (typically
| 1.2em).

Ah, then a string creates not only content, but an inline
box around it as well.

So, what happens if the element in question is "display:
inline"?

 
| > ==========================================================
| > [...]
| > | > | This is what my proposal (given above) does, except
| > | > | with one property, by making it possible to say:
| > | > |
| > | > |    content: replaced(lala), 'some-content';
| > | > |
| > | > | ...where "lala" is used if possible, and otherwise
| > | > | 'some-content' is used instead. The working group
| > | > | generally feels that it is better to not add new
| > | > | properties if that can be avoided.
| > | >
| > | > Avoided by what, making function notation modify the
| > | > meaning of the ~property~?
| > | > _Every_ other function notation allowed in a property
| > | > value is or returns a CSS-wide data type. _None_ of
| > | > them change the meaning of the property in whose value
| > | > they appear.
| > |
| > | Well it doesn't change the meaning of the property itself.
| >
| > Then how come a url causes two different results based
| > on whether it's in the url() notation or the replaced()
| > notation?
| 
| "Then how come a counter identifier causes two
| different results based on whether it's in the
| counter() notation or the counters() notation?"

counter() and counters() both return type string,
do they not? And the content property treats that
string value as it does any other string value,
does it not?

AFAICT, the url() notation takes a string and
returns type URI, which is handled differently
from type string.

The replaced() notation also takes a string, but
what does replaced() return?
Received on Wednesday, 4 July 2001 15:20:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:10 GMT