Re: Display Property Suggestion

Ian Hickson wrote:
[...]
>> Christian Kaufhold wrote:
>> 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!).


I didn't mean IMG to floated but to be in the normal flow (though it is
a replaced element).

>>> 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 IMG:before that would be valid CSS2, and I think it should be
rendered in just the same way:
                                          +----------+
                                          |          |
                           +------+       |          |
                           | Hello|       |  World   |
An image follows ... Hello +------+ World +----------+ End of it

That's at least how I imagine CSS2 would render this. It doesn't say
anything about the vertical orientation, but as baseline is default, I
think it should be that way.

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


I only found the expression (similar for width, CSS2, 10.4.2):
width:auto [...]
For replaced elements, user agents should use the intrinsic height of
the element's rendered content as the box's computed height. (Note that
for other values of 'height', the replaced contents may be scaled).

So there is nothing concrete said whether they *must* be resized, but
that they *may*.

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


I actually meant multiple urls like content:url(first.mpeg),
url(second.png), url(last.gif), attr(title);
as in your suggestion (as alternatives). And then still the problem is
what if first.mpeg should have always the size 300 x 400 px, but
last.gif is smaller, and the alternative attr() should also not have the
size that is used for displaying the images. Then allowing only one size
for width/height is not enough.
The same goes for IFRAME. If the IFRAME uri can be accessed, width and
height of IFRAME are used, otherwise the height is determined by the
size of the content. This could be expressed in CSS like this:

IFRAME
{
    content: replaced(attr(src)), auto;
    width:400px, auto;
    height: 300px, auto;
}

replaced() could always mean automatically uri(), because replaced
elements always include uris.

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


This could be written as:
IMG { content: replaced(attr(src)), attr(alt); }
OBJECT { content: replaced(attr(data)), auto; }
IFRAME { content: replaced(attr(src)), replaced(attr(longdesc)), auto; }

and e.g.
BIGIMAGE { content:uri(attr(src)), attr(alt); overflow:scroll;
width:300px; height:300px }

and it's not messier than using uri(), but it makes clear what is a
replaced element and what is generated content.

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


But what if I wanted to use (which is valid CSS2):
A[HREFLANG|="de"]:before { display:inline; content: "(" uri(german.gif)
")"; }
What happens if german.gif can't be accessed? Should () be displayed? I
think a solution to specify an alternative text *must* be found.

>Also, authors will forget to add "replaced()" and then get annoyed
>when they crop instead of resize content.
But maybe sometimes they want to crop or to scroll in a bigger image
(overflow:scroll).
Then they could use the generated-content syntax and have the image not
resized - and still offer a textual alternative if the image can not be
accessed.

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


They can in fact contain multiple uris.

>> 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 just don't think it is neccessary. Quotes and counters mostly are
before or after the element, so it makes things even more complicated if
you could both say:
QUOTE { content:open-quote attr(text) close-quote }
and
QUOTE:before { content:open-quote }
QUOTE:after { content:close-quote }
QUOTE { content:attr(text) }

I think that this is really redundant.

On the other hand, multiple textual possibilities (which make only sense
if an uri is contained, granted) don't make things more complicated IMHO
(except perhaps the formal description of the content property (-; ),
but that they _are_ needed (see above).

>>>> 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).
I already suggested only to recommend using a purely textual alternative
last.

Christian Kaufhold

Received on Tuesday, 3 November 1998 13:29:51 UTC