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

Ian Hickson wrote:
|
| fantasai wrote:
| > | The initial value of 'content' should not be the empty string,
| > | it should be nothing at all. 
| > |
| > 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. :-)

I hope you never take up gambling, Ian. >:)

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

But you're changing the display here--this is the
content property we're talking about, remember.

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

There's the mention. Unless you have something else to
contradict it, that's all I have to go on for defining
replaced elements' content.

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

If a property doesn't apply, it gets ignored. 
Regardless, width and height have have nothing to do
with whether :before and :after affect the image's
layout.

| Or at least poorly defined!)

Heh. I'll agree, with that.

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

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

Ian Hickson wrote:
|
| fantasai wrote:
| > The 'content' property... 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... replaces
| > the CSS box itself... Rules from the document neither
| > flow through these boundaries, nor affect the content 
| > within...
| >
| > 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.

Avoided by what, making function notation modify the
meaning of the ~property~?
_Every_ other function notation allowed in a property
value is or returns a CSS-wide data type. _None_ of
them change the meaning of the property in whose value
they appear.

As I've pointed out in English above, the values for
replacing content and replacing elements mean different
things. As you've pointed out in syntactic notation in
your post, they are incompatible. As you've explained
to Christian Kaufhold[1], mixing them is meaningless.
Why force them into a single property?

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

Yes, that goes back to the original topic of this
thread. To solve that problem, one needs a way of
directly addressing the various pieces of content.
I have several ideas, but none of them particularly
impress me. (One would be my reply to Bjoern
Hoehrmann.[2])


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

Sure it does. The element can stretch to its parent's
width, like the proposed inline-block does when its
contents get too large.

> Or absolutely positioned elements.

Calculate the width and then move it.

You could also pick an arbitrary value, like 100% of
the viewport, for example.

[1] http://lists.w3.org/Archives/Public/www-style/1998Nov/0004.html
[2] http://lists.w3.org/Archives/Public/www-style/2001Jun/0007.html

Received on Tuesday, 26 June 2001 10:55:44 UTC