Re: Display Property Suggestion

On Mon, 2 Nov 1998, Christian Kaufhold wrote:
>> 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.
> Well, it would be stupid for the author to write it, won't it?
And stupid for us to allow it, yes.

> You can also write: font-family: serif, sans-serif, monospace,
> cursive, fantasy, "Times New Roman", serif. and "Times New Roman"
> will never be used.
NOT TRUE.

If a glyph that is used by the document cannot be found in the five
generic font-families given, but "Times New Roman" *does* contain it,
then "Times New Roman" *will* be used.

However, with the replaced content there is *no* way that the text
content will give way to the graphic.

>>> 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.
> But even the own box of an IMG element had to be floated in if we said:
>   IMG:before { content:"Image start "; }
>   IMG:after { content:" That was the image" }
> or should the :before and :after pseudo-elements automatically be set to
> "block" on a replaced element?

If IMG is set to float *and is replaced*, but has :before and :after
generated content, it is my understanding that the :before and :after
text will flow as inline text (maybe with mixed in replaced content)
into the document where the IMG is, and not be floated.

eg, with the above styles and the HTML:

   <P>Hello <IMG SRC="W.PNG"> World</P>

...we would get:

   +-----+Hello Image start  That was the image World
   |W.PNG|
   |FLOAT|
   +-----+

Isn't this what the spec says? (Actually, AFAICT it doesn't mention
anything to do with generated content interacting with either replaced
or floated elements, but this rendering is the only thing that IMHO
makes sense, unless you want to start inferring anonymous block boxes
around floated elements which themselves are block boxes!).

>> 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 */
>>
You didn't reply to this, and I really would like to know the answer.

>> 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?
> We would have to add to the definition of width and height that if
> they are used with replaced content, they resize the element.
That is already the case.

Height and Width resize replaced elements.

However, with your suggestion you can have *many* replaced elements --
and which element do you resize? In the last example above, what would

   height: 200px; width: 200px;

...do?

> Or maybe a keyword "resize" could be added to the overflow property
> for replaced elements. Actually setting width/height has the problem
> that if you offer multiple uris, they might not all have the same
> size (maybe width/height should also take multiple values, in the
> same order as content).
Exactly the reason for not allowing multiple uris for the replaced
content of a single element.
 
>> 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 only allows one chance for flowed-in content, but several
> for replaced content. I think if we want (or have to) distinguish
> between these two, we also have to allow multiple possibilites for
> flowed-in content.
Why? This only makes things exceedingly complicated.

Something I learnt is that implementors (and authors, by and large)
want things to be *simple*. Witness what they thought of regexp
attribute selectors.

> Maybe like this:
> content:
> 
>   [ [ replaced( <uri> [ "," <uri> ]* "," ) ] ?
>   [ [ <string> | <uri> | <counter> | attr(X) | open-quote |
>     close-quote | no-open-quote | no-close-quote ]+ "," ]* | auto ]
>     | inherit
> 
> with the recommendation that the last flowed-in content should not
> contain an uri.
> That would make:
> 
> * { content: auto; }
> IMG { content: replaced(uri(attr(src))), attr(alt); }
> OBJECT { content: replaced(uri(attr(data))), auto; }
> IFRAME { content: replaced(uri(attr(src)), uri(attr(longdesc))), auto; }
This is incredibly messy now. 

> A[HREFLANG|="de"]:before { display:inline; content: uri(german.gif), "in
> German: "; } /* an example of multiple flowed-in content */
This can also be done using my suggestion. The german.gif is a
replaced element, effectively, except using your semantics you cannot
resize it.

Also, authors will forget to add "replaced()" and then get annoyed
when they crop instead of resize content.

> And now we still have to think about
> a) if it should be allowed for :before and :after elements to contain
> replaced content (I think not).
I see nothing wrong with it.

They can already have a single uri, so why not let it be resized?

> b) if content for the element itself should really take quotes and
> counters (I am still not convinced of that, and it only complicates
> things - I think they can also be set with :before and :after).
You think *that* complicates things, yet having multiple *textual*
content possibilities doesn't?!

>>> 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.
> But it would not do any harm (if there actually a style sheet
> existed that used it that way). Or we could say the renderer should
> assume "" (or display an error message) if even the last option
> contains an uri and it can't be accessed.
Backwards compatability in CSS is *very* important.

Let's not start adding workarounds. CSS2 added enough of those to get
around CSS1 things (eg, redefining the cascade).

-- 
Ian Hickson

Received on Monday, 2 November 1998 18:37:01 UTC