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

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; }
>>
>> Namely, one (the empty string) takes up space, whereas the other
>> (nothing) doesn't exist. It is similar to the difference between
>> the Perl string '' and the Perl value 'undef'.
> 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.


>>> Ian Hickson wrote:
>>>> The second thing you missed is that the CSS2 specification is
>>>> completely silent on how :before and :after should interact with
>>>> replaced content. One could argue that the spec says that the
>>>> text should go inside the image (:before and :after are actually
>>>> ":just-inside" and ":just-before-the-end" if you read the spec
>>>> carefully).
> <snip>
>>> It says, within the element's CSS box, and before/after the
>>> elements "document tree content"--according to the definition of
>>> replaced element, that would be the image itself.
>>
>> Where does it say that? The only mention I have found of this is in
>> section 3.1, the definitions section, which states:
>>
>> # For example, the content of the IMG element is often replaced by the
>> # image that the "src" attribute designates.
>>   -- http://www.w3.org/TR/REC-CSS2/conform.html#replaced-element
>
> There's the mention. Unless you have something else to contradict
> it, that's all I have to go on for defining replaced elements'
> content.

Examples are non-normative. "often" makes it even less normative. I'm
not saying there is anything to contradict it -- in fact I'm saying
the opposite, there is nothing there to give the answer either way.


[...]
>> 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. 'content'
decides what the content of the property is. It could be replaced
content or inline content or whatever, it's still content.


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

As I see it the three cases can all be supported by one property,
namely 'content'.

   1. content: normal;
   2. content: 'Hello World' url(astrophy);
   3. content: replaced(astrophy);


> As you've pointed out in syntactic notation in your post, they are
> incompatible. As you've explained to Christian Kaufhold[1], mixing
> them is meaningless. Why force them into a single property?

Because they are mutually exclusive. You will _never_ use them
together, _ever_. (And for that matter, from an implementation point
of view it saves memory and processing power).

Similarly, I would not have had separated 'position' and 'float'
properties, and I would not have had 'position: static' (the only
difference between 'position: static' and 'position: relative' is that
if 'top', etc are not 'auto' then you ignore them if it is 'static'
but not if it is 'relative').

> [1] http://lists.w3.org/Archives/Public/www-style/1998Nov/0004.html

-- 
Ian Hickson                                            )\     _. - ._.)   fL
Invited Expert, CSS Working Group                     /. `- '  (  `--'
The views expressed in this message are strictly      `- , ) -> ) \
personal and not those of Netscape or Mozilla. ________ (.' \) (.' -' ______

Received on Tuesday, 26 June 2001 18:18:06 UTC