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

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

From: fantasai <fantasai@escape.com>
Date: Tue, 26 Jun 2001 22:47:29 -0400
Message-ID: <3B394941.7E94183B@escape.com>
To: www-style@w3.org
Ian Hickson wrote:
| 
| On Tue, 26 Jun 2001, fantasai wrote:
| > Ian Hickson wrote:
| > | fantasai wrote:
| > | > So I ask, what is the difference between [''] and nothing?
| > |
| > | The same as the difference between:
| > |  <inline></inline>
| > | ...and
| > |  <none></none>
| > | ...when the following stylesheet is applied:
| > |  inline { display: inline; }
| > |  none { display: none; }
| >
| > But you're changing the display here--this is the content
| > property we're talking about, remember.
| 
| I was merely using that as an example. In the context of the
| 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.

==========================================================
| [...]
| > | 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~?
|
| 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?

| > As I've pointed out in English above, the values for
| > replacing content and replacing elements mean different
| things.
| 
| I'm confused.
| 
| Here are the cases I see need supporting for replacing
| the content of elements:
| 
|    1. Don't replace anything, let the DOM determine what
|       is used.
| 
|    2. Replace all the children of the element with a new
|       set of content with its own formatting rules, for
|       example mixed text and images. ("generated content")
| 
|    3. Replace all the children of the element with a
|       single item that is out of the scope of the 
|       stylesheet. ("replaced content")
| 
| None of these replace the element itself. When I've said
| "replaced element" I have always meant "replaced content"
| (and I apologise for not being clear).

In the first two instances, 'content' (auto or explicit) only
affects the stuff inside the element's CSS box.

In the last instance, 'content' would not only affect the
stuff inside the element's CSS box, but also change the
nature of the CSS box.


Ok. Suppose I'm given a colander with vegetables in it.
    _m,#.__
    \:::::/  <- colander with veggies
     -----

The contents of the colander are the vegetables.
The content of the CSS box is its document content.

Now, if I put the colander in a sink full of water,
the water will flow through the holes and soak its
contents (my vegetables).
Now, if I put the CSS box in an HTML document,
the style rules will inherit through the box and
affect its content (the document content).

I can replace the vegetables in my colander with
some other vegetables.
I can replace the document content in the CSS box
with some other content.

The water still flows through the holes in the
colander.
The rules still inherit through the CSS box.

Now, suppose I decided to replace the colander with
a Tupperware(R) of some lettuce.
Now, suppose I decided to replace the CSS box with
another document (like what happens with IFRAME).

The water doesn't flow through the Tupperware(R)
box, and my lettuce doesn't get wet.
The rules don't inherit through the replaced CSS
box, and they don't affect the inserted content.

Do you see what I'm getting at?
Received on Tuesday, 26 June 2001 22:45:32 GMT

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