- From: Allan Odgaard <Duff@DIKU.DK>
- Date: Thu, 13 Jan 2000 22:37:26 +0100
- To: Bert Bos <Bert.Bos@sophia.inria.fr>
- CC: WWW-Style@w3.org
On 12-Jan-00, Bert Bos wrote: >> The standard says: >> "Since an inline box may not exceed the width of a line box, >> long inline boxes are split into several boxes [...]" >> [...] > We will probably have one or more properties for hyphenation and > line-breaking in CSS3 that specify whether you are allowed to break > such a long word or not, but for the moment it is not specified. > Unless you can do true hyphenation, I think it is better not to split > such a long word. I'll leave it as it is then -- I just hate that text and/or images can quite easily overlap other elements, which I'm sure any common user will interpret as a bug in my layout code :-( > Also take a look at the 'overflow' property of CSS2. That determines > whether the part that sticks out should be visible or not. Speaking of which, is there any recommended placement of the scrollbar when this property is set to 'scroll'? (i.e. inside or outside the padding, border or margin) -- and should the space it occupies be counted as content space? For example if I set the width of a box to 200px, and give it a scrollbar, should the 200 pixels then include the scrollbar? If yes then I think that it's a little problematic since the user has no idea of how wide the scrollbar is (and cannot calculate the proper width he should give to his box, assuming he e.g. has a box with an image of fixed size) Also, the standard says: "[...] the user agent uses scrolling mechanism [...] such as a scroll bar [...] that mechanism should be displayed for a box *whether or not* any of its content is clipped." Does that mean I should add both a vertical and horizontal scrollbar? Or could I settle with a vertical, and let the horizontal be 'auto'. Afterall, only the appearance/disappearance of the vertical one will cause lines to be re-flowed. The horizontal bar shouldn't affect the layout. Btw: In the earlier standard I read, the 'visible' setting for the overflow property said that the containing box should be expanded to hold all its children. Now it shouldn't, out of curiosity: is this to favor incremental rendering? >> About the 'width' property then it's said that for "Block-level, replaced >> elements in normal flow": "If 'width' is specified as 'auto', its value is >> the element's intrinsic width." [...] > The two DIVs are not replaced elements. As normal block elements, they > get their width from their parent or from their own 'width' property. OK, I think that I misunderstood the standard, as I took "Block-level, replaced elements [...]" to be block level boxes *containing* replaced elements, which is why I couldn't make much sense out of it... ;-) Now just one more question: From "9.5.1 Positioning the float: the 'float' property": 5. The outer top of a floating box may not be higher than the outer top of any block or floated box generated by an element earlier in the source document. Just to be sure, this rule says *both* left & right floated boxes, generated earlier, should be considered, right? I.e it would be incorrect to render this: Hello world <Img Align=Right Width=70 ...> <Img Align=Left Width=30 ...> this is nice! As: +-+ Hello world |2| this +-----+ +-+ is | 1 | nice! +-----+ Kind regards Allan -- URL: http://www.DIKU.dk/students/duff/ <sb> Always remember that you are unique. Just like everyone else.
Received on Thursday, 13 January 2000 16:38:56 UTC