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

On Thu, 19 Jul 2001, fantasai wrote:
>
> 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.

With the following exceptions: For :before and :after, the actual type
of box generated depends on the 'display' property, for 'auto' the
actual boxes generated is dependent entirely on the content of the
element itself, and for replaced(), the box is a replaced inline
instead of a normal inline.

And of course, this is all a merely hypothetical based on what I am
proposing. :-)


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

Right. But it does prevent the rendering of any boxes that _would_
have been generated, e.g. the inline box that in CSS2 would be
generated by the following:

   <div><span/></div>

...would end up not being rendered at all if div's 'content' property
was set to 'none'.


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

Sorry, I should have been clearer. In CSS2, as written, the answer to
your question is yes. I have asserted, however, that this is an error
in the spec, and that the initial value of the CSS2 'content' property
should be 'none', even if that is not a value that one can explicitly
set. (There is a precedent for this. The initial value of the
'border-color' properties is 'value-of-color-property', which one
cannot set explicitly.)

If the answer to your question is yes, then CSS2 is completely
incompatible with CSS1...


>>> background-image takes type 'mixed content replaced content'?
>> Sure, why not.
> And does it also take type 'replaced content'?

Does it need to?


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

I challenge the assertion that they were universal. Why does @import
take a string or whatever url() returns, but not whatever counter()
returns? Why does attr() work for content, but not for background-
image? Why does 'normal' mean different things in different contexts?

Don't forget, CSS is not a programming language. The concept of typing
is useful, but like I said, it is not a formal part of 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.

This isn't as bad as you make it sound. They aren't functions in the
first place, they merely have "function notation". And why should CSS
not have function overloading based on return type? It's not a new
concept.


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

It's not redundant. What value one property takes is irrelevant to the
others, in the majority of cases.


> As for proposing, I already posted a proposal.

It introduces another property, though. The four properties I listed
above are already interdependent to the point where code which
calculates their computed value has to take each of them into account
at once. Adding another property into that particular mix is, IMHO,
unacceptable.


> Another alternative would be to redefine a single url() value as
> replaced content. This would avoid adding another "redundant
> property".

It's an interesting idea, but it is not backwards-compatible.


Is your only problem with my proposal that it introduces a new
function notation which you feel is redundant with url() ?

Here's is another example, to remind other people what my proposal
would look like:

  footer:before {
    /* insert the company tagline */
    content:
      replaced(theCatSaidHi.mng),
      "The cat, " url(meow.png) ", said " open-quote "hi" close-quote ".",
      "The cat said " open-quote "hi" close-quote ".";
    display: block;
  }

-- 
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 Thursday, 19 July 2001 14:56:21 UTC