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

On Mon, 9 Jul 2001, fantasai wrote:
>
> Let me recapitulate.
>
> If we have "display: block" and "content: none",
> the model is <div/> (which is the same as
> <div></div>).
>
> If we have "display: block" and "content: ''", the
> model is <div><span/></div>

Technically, no, because XML (or HTML) has no presentation semantics of
its own. It's a subtle issue, but what you really meant was:

   If we have "display: block" and "content: none", the model is "an
   empty block".

   If we have "display: block" and "content: ''", the model is "a block
   with an empty inline inside it"

It's a subtle difference.

Given that:

> Doesn't it strike you odd that by inserting the content of <div></div>
> with a stylesheet, I don't get the same rendering as by using the
> exact same string as its content in the markup?

No, because they are not the same. Only stylesheets are making them the
same in the first place. <div></div> is not the same as "block with an
empty inline child". It is _rendered as_ "empty block". In the DOM, the
<div> would have *no* children, not an empty text node child. An
important, if subtle, difference.

If the DOM allows empty text nodes, then an interesting test would be to
dynamically add such a text node to a block and making sure that UAs (if
they didn't delete the text node straight away) actually resized the
block. I have doubts anyone does that right, since CSS is not described in
terms of the DOM.


> Anyways, to go on...
>
>  | > So, what happens if the element in question is
>  | > "display: inline"?
>  |
>  | If the element in question is an inline box, then I
>  | believe the proposed value none should be
>  | indistinguishable from the value ''.
>
> So you agree that by default, :before/:after exist
> as inline boxes.

No. If they were, then every single block would have two empty inlines at
the start and end respectively. The initial values of 'content' for
:before and :after should be the keyword meaning "nothing". That's the
whole problem and why I keep saying CSS2 should have an errata made for
this issue. :-)

(Otherwise, in your terms,

   <div/>

...would be the same as:

   <div><span/><span/></div>

...which, assuming normal stylesheets, would be rendered as a block with
an empty line box containing two empty inline boxes of finite, non-zero
height; whereas in reality <div/> should have zero height and not contain
any line boxes at all.)


>  | > | > Then how come a url causes two different results
>  | > | > based on whether it's in the url() notation or the
>  | > | > replaced() notation?
>  | ...
>  | > AFAICT, the url() notation takes a string and returns
>  | > type URI, which is handled differently from type string.
>  |
>  | In the context of the 'content' property I imagine it
>  | returning the type 'mixed context replaced content'
>  | (i.e., it is replaced content but in the context of
>  | mixed data: it can appear in the middle of text, and
>  | doesn't directly replace the element itself).
>
> background-image takes type 'mixed content replaced content'?

Sure, why not. (Note that CSS2 doesn't have a formal type system, even
though I think everyone agrees that, implicity, CSS is strongly typed.)

And if you don't like that (after all it would be hard to argue that
@import takes either a string or a 'mixed content replaced content'),
maybe the url() function is a different function in different contexts.

How would you propose making the 'replaced content' / 'mixed content'
distinction without introducing another redundant property? (Redundant
with 'display', 'float', 'position' and 'content', all of which strongly
overlap each other and, IMHO, should never have come out as they did.)

-- 
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, 10 July 2001 09:31:31 UTC