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

On Fri, 15 Jun 2001, fantasai wrote:
>
> 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.

Nope. The empty string and nothing are not the same thing. You have
probably spent too much time playing with untyped languages. :-)


> So I ask, what is the difference between [''] and nothing?

The same as the difference between:

   <inline></inline>

...and

   <none></none>

...when the following stylesheet is applied:

   inline { display: inline; }
   none { display: none; }

Namely, one (the empty string) takes up space, whereas the other (nothing)
doesn't exist. It is similar to the difference between the Perl string ''
and the Perl value 'undef'.


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

(Right. Emphasis on 'content'. This is one of the places that mean that
:before and :after are actually ":just-inside" and "just-before-the-end".)


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

Where does it say that? The only mention I have found of this is in
section 3.1, the definitions section, which states:

# For example, the content of the IMG element is often replaced by the
# image that the "src" attribute designates.
  -- http://www.w3.org/TR/REC-CSS2/conform.html#replaced-element


> The image's CSS box is inline. So that's inside an inline box,
> before/after the image.

But 'height' and 'width' don't apply to non-replaced inline boxes, only to
replaced inline boxes. So you end up with an undefined case. (Which was my
original point. Generated content on replaced elements is currently
undefined. Or at least poorly defined!)


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

This is what my proposal (given above) does, except with one property, by
making it possible to say:

   content: replaced(lala), 'some-content';

...where "lala" is used if possible, and otherwise 'some-content' is used
instead. The working group generally feels that it is better to not add
new properties if that can be avoided.


> | 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 agree. Of course we already have this. (e.g., color and background on a
single element, or display: table-* on a bunch of elements).


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

That's a good idea (and can be ported to my proposal just by making
"replaced()" take more than one argument) but it doesn't solve the
existing problem of sizing images and other replaced content that is
given in the 'content' property value.

   cards:after { content: url(visa) url(mc) url(barclays) ' accepted' }


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

A very good point.


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

Doesn't work for inline replaced elements or floats. Or absolutely
positioned elements.



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

It also won't solve the display: table-* problem I mentioned above.

Nice, though. :-)

-- 
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, 19 June 2001 05:27:18 UTC