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

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

So :before and :after boxes do not exist by default. 
Their box is generated by the "content" property. But,
unlike a box generated for any other element, this
content-generated box is stylable by its (pseudo-)
element.

Yes?

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

Obviously. It would not be rendered at all if the
<div>'s 'content' property were set to anything but
'auto'/'normal'.

Or did you mean the "root inline"? (It doesn't exist
in CSS2.[1])

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

Why should it not? Why should 'background-image' take
type 'mixed content replaced content' and not 'replaced
content'?

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

url() returns a URI. counter() returns a string. They
are different types. Just because @import accepts one
type of argument does not mean it accepts all of them.

| Why does attr() work for content, but not for 
| background-image?

Because attr() returns type string. 'content' already
handles type string. 'background-image' is defined to
accept url() notation, which returns something different.

| Why does 'normal' mean different things in different
| contexts?

It is a property-specific keyword, not a type. It is not
universal to the language. It is defined by the property,
just like SGML constructs like the following define 
attribute-specific keywords:

method  (GET|POST)  GET  -- HTTP method used to submit the form--

If I put POST in a class attribute, does it mean the
same thing? No. Even if I were to define two different
attributes that take the same two values, the values
would be independent of each other. They would only
/look/ the same.

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

Why should it? It is not necessary. 
It introduces complexity without adding power, and it
becomes extremely unwieldy in a strongly typed language
with "functions" (properties) already overloaded based
on argument type.

background: func(arg);

What does func() return?

| It's not a new concept.

It's new to CSS.

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

ok

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

...Actually, you probably could redefine url() content
without breaking the spec. CSS2 doesn't say that URI-
referenced resources should be inserted as inline-level
children of the pseudo-element's box--just that they're
inserted. So, theoretically, a later version of CSS
could clarify that by default, the content gets
appropriately "replaced" in a manner similar to <img>.

http://www.w3.org/TR/REC-CSS2/conform.html#replaced-element
http://www.w3.org/TR/css3-userint#content

Well, anyway..
</randomThoughtOfTheDay>

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

It is that you are introducing function notation to change the
behavior of the property, which I don't think is a good idea.
Whether the URI is noted by url() or replaced(), it is /still/
a reference to another file. It hasn't changed, so neither
should its handling.

If replaced() introduced something meaningful outside the
context of 'content', then I wouldn't have a problem with it--
but it doesn't.

[1] http://www.w3.org/TR/REC-CSS2/visuren.html#anonymous

Received on Friday, 3 August 2001 17:44:41 UTC