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