- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 06 Nov 2004 21:24:34 -0500
- To: www-style@w3.org
This came up recently in a bug filed on Mozilla... [1] Consider the following situation: <root> <node style="position: fixed">Fixed</node> Lots of content on many lines. </root> When laying this out, per section 10.6.4 [2] the UA must compute the hypothetical box of the <node /> element, then figure out the offset of that box from the top of the viewport, and use that offset as the computed value for "top". The problem is that scrolling should not affect the position of the <node /> element (since it is fixed-positioned), while scrolling affects the hypothetical box (for example, scrolling to the bottom of the document could put the entire hypothetical box above the top of the viewport). This means that if the document is scrolled and then the viewport size is changed (which necessitates a recalculation of the offsets of <node>), the fixed-positioned element will actually move. In UAs that recalculate the offsets more eagerly, it could even move when scrolling. This does not seem at all desirable, in my opinion. Would it not make more sense to specify that for fixed positioning auto top and left are replaced by 0 before doing the other calculations? There is no issue of compatibility with IE/Windows here, unlike absolute positioning, since IE/Windows doesn't support fixed positioning... I really don't see any way to use this "hypothetical box" concept for fixed-positioned boxes without running contradictions. -Boris [1] https://bugzilla.mozilla.org/show_bug.cgi?id=268111 [2] http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-height
Received on Sunday, 7 November 2004 02:24:49 UTC