- From: Ian Graham <igraham@ic-unix.ic.utoronto.ca>
- Date: Thu, 16 Sep 1999 17:16:20 -0400 (EDT)
- To: "L. David Baron" <dbaron@fas.harvard.edu>
- cc: ian.graham@utoronto.ca, tantek@cs.stanford.edu, www-style@w3.org
On Thu, 16 Sep 1999, L. David Baron wrote: > On Thu, 16 Sep 1999 12:25:29 -0400, Ian Graham > (igraham@smaug.java.utoronto.ca) wrote: > > However, returning to block element overlaps -- how should the overflow > > property affect this? > > The 'overflow' property is defined in CSS2 to control whether (and how) > the content of a box overflows outside of the value of the 'clip' > property. This includes the background and border of its children (and > all inline content), but not the element itself [1]. So this would mean that overflow should not in any way affect the rendering of statically positioned elements _unless_ the content overflows the block box (or the box of a parent). > I don't think it's implemented quite this way in current browsers. > Furthermore, it's not completely clear to me how (if at all) clip > should interact with scrollbars. Yes, the possibilities are rather ugly. > In the cases we've been discussing, I don't think there is any overflow > (except perhaps of floats in my example [2], but the example could be > changed easily). I agree. It would appear that Mozilla's implementation is correct, provided you don't try (as I did) to muck about with overflow properties for elements that don't overflow. This means that paragraph's can't be 'backed up' on top of previous elements and have the background overlap previous content. Too bad, as that 'might' be useful (and maybe more intuitive?). It might be nice if there were a way to bind the background and content together for rendering purposes, so that they could behave the way I want (how's that for hubris). Something like background-depth: normal | element where 'element' pops the background up to the depth one level below the element content. On the other hand, the type of rendering behavior I suggested is produced using positioned elements (and controllably using z-index), and perhaps that is a better way to go about overlapping stuff. Regardless, the behavior is sufficiently anti-intuitive that it probably warrants a note in the spec. > David > > [1] http://www.w3.org/TR/REC-CSS2/visufx.html#overflow > [2] http://lists.w3.org/Archives/Public/www-style/1999Sep/0067.html > -- Ian
Received on Friday, 17 September 1999 11:20:42 UTC