Re: Display Property Suggestion

On Sun, 1 Nov 1998, Christian Kaufhold wrote:
>> Another problem is that the whole point of having multiple values
>> is that if one cannot be drawn then you fall onto the next one,
>> until you get to the last value in the `content` list, which is
>> text-based (or a mixture of text and uri). If you allow text first,
>> as your suggestion does, then it allows for the content value "
>> attr(alt), uri(xyz) ", which would be pointless (the uri would
>> *never* be shown) while still being valid.
> But the last uri offered can also be mixed with text and attribute
> values, why not the first ones?
Well, to start with, if you allow text first, as your suggestion does,
then it allows for the content value " attr(alt), uri(xyz) ", which
would be pointless (the uri would *never* be shown) while still being
valid.

> For example consider the following
> XML fragment which uses an XML link to cite some other author (or is
> it too far-fetched?):
>   <headline>Mr. Miller says to this topic:</headline> <quote
>   xml:link="simple" inline="true" show="embed" actuate="auto"
>   href="http://www.whatever.com/article.xml#special"/>
> Now quotes could be inserted even though it is a replaced element:
>   quote[show=embed][actuate=auto] { display:block;
>   content:open-quote url(attr(href)) close-quote, attr(href) }
> (The attr(href) is added as a backup if the resource is not
> available, so that you user can the uri at least.)
This is *not* replaced content, though, it is flowing the document in.

It is the same difference as between SSI and IFRAME inclusions. One is
flowed in, the other has it's own box.

I really cannot see how you would define the rendering of *replaced
content*, which is what we are doing here, while still allowing
*multiple uris* and *text*!

Seriously: how would you render the following?

   IMG  { display: block; content: "Hello" uri(hello.gif) "World"
          url(world.gif), auto; border: thin solid black; }
          /* the gifs are very different sizes */     

AFAICT, currently 'content' works by *flowing in* the text, with
inline replaced elements as part of the flow. This *prevents you* from
accessing the replaced elements directly.

For example, how would you resize the graphic in the following:

   IMG  { content: uri(hello.gif), auto; }

using your system? You can't set the width/height, because that would
have the same effect as it does now on before/after -- just setting
the size of the container, presumably cropping the image. Imagine:

   IMG  { content: uri(hello.gif) " the " uri(world.gif); }

How do you resize the replaced elements now?

This is why I really do suggest only allowing uris, and only single
uris, in the first part. We are *only* referring to replaced content,
here, not generated (flowed in) content. *That* we can already do, by
using the last part of the content property.

> But this still has the problem that the even the last possible value
> for content can contain an uri, and if the browser can't handle
> that, something undefined is displayed.
As in CSS2, yes.

> I would suggest that the last value for content must _not_ contain
> an uri (like the last value for font-family has to be a generic
> font-family and the last value for cursor a generic cursor), even if
> this is "" or auto (which would mean "" with empty elements).
That would break backwards compatability with CSS2.

> My suggestion is now:
> [ [ [ <string> | <uri> | <counter> | attr(X) | open-quote |
>       close-quote | no-open-quote | no-close-quote ]* , ]*
>    [ [ <string> | <counter> | attr(X) | open-quote |
>       close-quote | no-open-quote | no-close-quote ]* | auto ] ]
>     | inherit
> (looks quite ugly).
Yup.

-- 
Ian Hickson

Received on Sunday, 1 November 1998 17:53:11 UTC