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

Ian Hickson wrote:
| 
| 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.

So, now we have established that
  a) 'content' generates an inline box along with
     the content. This box is the child of the box
     of the element being affected.
  b) As an exception to the above, "content: none"
     does not create an inline box, nor does it
     destroy the element's box or affect its 
     display.

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

Then explain the difference between 'content's
effect on an inline element and its effect on a
block element, since your reply above did not
make it clear that there was one.
 
| >  | > | > 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).
| >  | 
| >  | > The replaced() notation also takes a string, but what
| >  | > does replaced() return?
| >  | 
| >  | 'replaced content'
| >
| > background-image takes type 'mixed content replaced content'?
| 
| Sure, why not. 

And does it also take type 'replaced content'?

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

Thus a new CSS property is allowed to create a new data type
solely for its own use, regardless of the fact that prior
to this new property and its new data type, CSS data types
were all *universal* to the language.
 
| 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.

And cause CSS functions to become context-aware.

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

In order to avoid redundancy with other properties.


I don't think it's worth the cost of recasting the
language like this.

As for proposing, I already posted a proposal.
Another alternative would be to redefine a single
url() value as replaced content. This would avoid
adding another "redundant property".

Received on Thursday, 19 July 2001 04:53:18 UTC