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

Ian Hickson wrote:
> 
> > II) Do all empty inlines exist, or just some of them?
> > [...]
> > So, which obscure clause did I skip this time?
> 
> You missed two things. First, there is an error in the 
> CSS2 spec. The initial value of 'content' should not be 
> the empty string, it should be nothing at all. This is 
> similar to border-color, whose initial value is not 
> representable in CSS (yet). This is a known error that 
> will be corrected in CSS3.

The empty string /is/ nothing at all. So I ask, what is the 
difference between nothing and nothing?

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

from Section 12.1, "The :before and :after pseudo-elements"

 "As their names indicate, the :before and :after pseudo-
 elements specify the location of content before and after 
 an element's document tree content."
 
 "The formatting objects (e.g., boxes) generated by an 
 element include generated content. So, for example, 
 changing the above style sheet to:
       P.note:before { content: "Note: " }
       P.note        { border: solid green }
 would cause a solid green border to be rendered around 
 the entire paragraph, including the initial string."
 ---
 "Replaced element 
     An element for which the CSS formatter knows only the
     intrinsic dimensions. In HTML, IMG, INPUT, TEXTAREA,
     SELECT, and OBJECT elements can be examples of
     replaced elements. For example, **the content of the
     IMG element is often replaced by the image that the
     "src" attribute designates.** CSS does not define how
     the intrinsic dimensions are found." (emphasis mine)

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. The image's CSS box is inline. So that's inside
an inline box, before/after the image.

================

> http://lists.w3.org/Archives/Public/www-style/1998Nov/0035.html
> http://www.bath.ac.uk/%7Epy8ieh/internet/wwwstyle.html#replaced

| <replaced> := "replaced(" <string> | attr(X) ] ")"
|
| Each item brought in as replaced() should be used as a
| source file for making the element into a replaced
| element.

The 'content' property is meant to control the content
of an element. Thus it can replace the content of an
element, but it keeps the CSS box intact, along with all
inheritance and proper CSS behavior through and within
the box.

In a replaced element, the outside content does not
replace the content; it replaces the CSS box itself.
The replaced content's only connection with the parent
document is its boundaries (content edge, not border
edge). Rules from the document neither flow through these
boundaries, nor affect the content within, and, in the CSS
model, the parent document is only aware of the replaced
content's size. (which implies :before and :after have no
effect on a replaced element)

We're dealing with two different concepts here, so I 
propose splitting the above-defined 'content' property 
into a 'content' property and a 'replace' property.
If the UA cannot replace the CSS box, then it displays
the element's 'content'.

| The "simplest" way of resizing each of the contents
| individually would be to allow comma separated values for
| width/height, each applying to the respective entry in
| the content property that is used.

This sort of correspondance by position is very hard to
follow. When you combine this with CSS's cascading nature,
and the use of style sheets from different sources, it
becomes nightmarish. The cascade can change width or
or height or content without accounting for the rest, and
stylesheets from other sources won't be aware of content
rules in this stylesheet.

I suggest that the 'replace' property be allowed to take
initial width/height arguments for each item. This will
be treated as the content's inherent size; a value of
auto on the 'width' property resets the width to this
specified value (which itself defaults to auto). Then
the cascade can take over. This will not only make it
significantly easier to specify width/height in the 
simpler (more prevalent) cases, but also lets other 
rules blindly assign and unassign widths in more 
complicated stylesheets.

| Note, when height and width are given but there are less
| heights/widths than contents, missing values are assigned
| "auto".

Missing values should be assigned the last value in the 
list. That way, if a style rule is not aware of the list 
of replaced content and its specifics, it will still 
effect something sensible. A typical replacement rule would 
probably involve different formats but similar sizes. So 
this way, if I choose to strech an image across 100% of
the width, it gets stretched no matter how many different
formats I specify it in. If width defaulted to 'auto' for
all unspecified values, the effective width would depend on
whether or not the browser supported the first format in the
replacement list.

| If the height and width properties are set to auto and
| the replaced content does not have an inherent size, such
| as a vector graphic, then the results are (for the
| moment) undefined by this suggestion.

How about using the non-replaced block width equation?

---------------

| The ability to link multiple declarations so that if one 
| is overruled by a later (or eariler!) rule in the
| cascade, then all related declarations are ignored too.

Hm..

P { color: black;~ background: white; }

The tilde looks a bit like a piece of string.
One can think of it as tying a not between the two
rules.

BTW, this might mitigate the color-background problem, but
it won't solve it because transparency lets other elements
affect the one in question.

Received on Friday, 15 June 2001 17:38:57 UTC