W3C home > Mailing lists > Public > www-style@w3.org > November 1998

Re: Display Property Suggestion

From: Ian Hickson <py8ieh@bath.ac.uk>
Date: Wed, 4 Nov 1998 19:49:18 +0000 (GMT)
To: Christian Kaufhold <chka@uni-bremen.de>
cc: www-style@w3.org
Message-ID: <Pine.GSO.4.04.9811041932400.15103-100000@midge.bath.ac.uk>
On Wed, 4 Nov 1998, Christian Kaufhold wrote:
> But still a problem is left: Should replaced() uris always be resized?
> There are cases when that is not appropriate, 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"].

True. Good point.

Your suggestions are very comprehensive, but you missed one
possibility: instead of just "replaced()", we could have "resized()"
and "inserted()".

However, the best option, as you say, is to let the UA decide.

If the content has an inherent size, then the box should be resized
and the contents should be scaled to fit the box. For example, images
(bitmapped or vector). If the content does not have an inherent size,
for example an XML, MathML, or HTML document, then the contents should
have their normal display dimensions, and the box should merely crop
the contents (as an IFRAME does, currently, in IE).

If the replaced elements want to be cropped, then the author can use
the "clip" property.

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

I would advise against such complications.

After all, the next stage after that is to say "but what of padding?
Surely we need multiple values for that. And clip. And border. And
background. And color. And why not font, and..." and that would be
plain silly. After all, the "text-shadow" property already takes
commas, so if you get that far then the grammar will need a wild
rethink! No, I think it is best to only extend content, height and
width for the replaced content idea.

Ian Hickson
Received on Wednesday, 4 November 1998 14:49:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:48 UTC