Re: Display Property Suggestion

Ian Hickson wrote:
>True, but without allowing this you cannot do:
>
>   XYZ { content: open-quote attr(name) close-quote " said: "
>                  open-quote attr(text) close-quote; }

In this case, you can say:
XYZ:before { content:open-quote attr(name) close-quote " said: "
open-quote }
XYZ { content:attr(text) }
XYZ:after { content:close-quote }
But actually the other solution is simpler to read, so leave it that
way.

I fully agree with your definition of the content property now.

But still a problem is left: Should replaced() uris always be resized?
There are cases when that is not approbiate, e.g.
OBJECT[TYPE="text/html"] which has to be displayed in its original size,
but with scrollbars (if big enough) - in contrast to
OBJECT[TYPE="image/jpeg"].

I think there are three solutions to this:
1. The renderer should use the content type of the uri to decide whether
the replaced() element should be resized or be made scrollable (maybe
every type starting with "text" should be scrollable, about every other
resized).

2. replaced() uris are always resized, uri() is always shown in original
size.

That would make
OBJECT { content:replaced(attr(data)), auto; }
OBJECT[TYPE="text/html"],
OBJECT[TYPE="text/xml"]
/* ... and many others (would be easier with more matching
possibilities) */
{ content: uri(attr(data)), auto; overflow:auto }

and gets in fact impossible if IFRAME is not forbidden to contain an
image because IFRAME has no TYPE attribute. So this works only for
scrollable uris().
IFRAME { content:uri(attr(src)), uri(attr(longdesc)), auto;
overflow:auto }
IFRAME[SCROLLING="no"] { overflow:hidden }
IFRAME[SCROLLING="yes"] { overflow:scroll }

This is also bad because uri() is used for generated content (and might
be combined with text etc.) and replaced() for replaced elements, so it
is contrary to the idea that OBJECTs contents and IFRAMES contents are
replaced.

3. It depends on the overflow property. If overflow is set to "auto" or
"scroll", scrollbars are (if needed with "auto") provided, if it is set
to "resize" (which makes only sense with values for width or height
given), the content is resized, if "hidden", the content is clipped (in
original size).
That way, overflow must also take multiple values (like width and
height) for the different possibilities of the content property.
This means that you always have to set overflow:resize; when including
images etc. (which will often be forgotten). overflow might also be
reset by some other declaration with a higher specificity, so that the
displaying can become unreadable.

IFRAME { content:replaced(attr(src)), replaced(attr(longdesc)), auto;
overflow:auto, auto, visible } /* visible is used if the the uri()s
can't be accessed, so the children of IFRAME are displayed */

IFRAME[SCROLLING="yes"] { overflow:scroll, visible }
IFRAME[SCROLLING="no"] { overflow:hidden, visible }

OBJECT { content:replaced(attr(data)), auto; overflow:resize, visible }
OBJECT[TYPE="text/html"],
OBJECT[TYPE="text/xml"] { overflow:auto, visible }

TITLE { content:replaced(welcome_and_logo.mov),
                replaced(welcome_and_logo.html),
       "Welcome to " uri(logo.gif) " !!",
                      "Welcome to CSS!!";
             width: 256px, 300px, auto;
             height: 64px, 80px, 58px;
            overflow:resize, auto, hidden, visible;
}

I think the only practical solution is 1 (although it might leave space
for ambiguities). Everything else makes the declarations *very*
confusing.

But maybe we need the multiple overflow (and clip as well) even then
(for the multiple generated content values):
TITLE { content:replaced(welcome_and_logo.mov),
       "Welcome to " uri(logo.gif) " !!",
                      auto;
        overflow:visible, hidden, scroll;
        width:300px, auto;
        height: 64px, 58px, 100px;
    }

This way (It does not matter for replaced() elements what value overflow
has), if the browser can't play .movs,
anything of the generated content "Welcome to " [CSS] " !!" that is
higher than 58px is cut. If even logo.gif can't be read, vertical
scrollbars are provided for the children of TITLE which then occupy a
height of only 100 pixels.

Christian Kaufhold

Received on Wednesday, 4 November 1998 13:38:30 UTC