According to the CSS2 spec, overflow should default to visible so that the full contents of elements are shown. This works fine in many cases, but with fixed position elements this can result in a portion of the element being hidden and impossible to access. If overflow is set to auto on these elements, a scrollbar will appear when necessary and therefore fix this problem. In Cascading Style Sheets: Designing for the Web, by Hakon Lie and Bert Bos, it says "If the contents of the DIV is too large, scroll bars will appear" on page 218. It looks like the intent was for fixed position elements to have overflow: auto. This is also more consistent with using position: fixed in place of FRAMEs. With frames, scrollbars automatically appear when necessary unless authors go out of their way to disable them (overflow: hidden). It would be nice if position: fixed had the same behavior by default. I observed this problem with ASA's blog with Mozilla nightly 2002082208 on Win2K. With a small enough window or large enough font, some sidebar content disappears. http://www.mozillazine.org/weblogs/asa/ This is also reproducable with Debug Viewer Demo #12 More fixed pos. Resize your window to be smaller and you'll lose part of the sidebar content. To be complete, bug 105796 asks for the ability to force overflow: auto on ALL frames, not just by default.
This bug is invalid as stated (in proposes a specific, and impossible, technical solution to a valid problem) but it does raise valid issues.
Issues which should be raised in www-style, though, not here. INVALID. WG.
I was actually thinking about the fact that we might have serious problems on 'position: fixed' elements with 'overflow: visible' and we need some testcases (particularly fun mixed-transparency testcases).
David, Why is defaulting overflow to auto technically impossible? Also, what does "serious problems on 'position: fixed' elements with 'overflow: visible'" mean? Is that a new (potential) bug? Or related to this one? Or just something you happened to think of that's not really related? :-) Ian, I'd appreciate it if you'd raise this issue on www-style. Thanks.
Allowing the default value of a property to depend on the value of another property just isn't the way CSS works. Not really related.