357714 - rendering of overflow: auto lost style for offscreen content

Status: RESOLVED DUPLICATE of bug 309110

(Core :: Layout: Positioned, defect)

Description

[Yannick Koehler]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061015 Firefox/1.5.0.7
Build Identifier: 

I created a layout with a menu at the top.  

Firefox and IE behave properly for it.

Except for firefox when the menu is larger than the default area width.

Use my provided html and css, you will see the menu and you will also see a horizontal scrollbar at the bottom, now if you scroll that bar, the background color is lost when displaying the menu outside of the default visual area.

IE will not have this behavior as it wrap the menu.  I personnaly prefer the way firefox renders it, except that I would like my background to continue to the right.

Now... I have no idea of what the CSS standard says about this.  Help appreciated.

Reproducible: Always

Steps to Reproduce:
1. open firefox with my test.html and css

Actual Results:  
part offscreen doesn't have cSs style applied to it.

Expected Results:  
Either like IE, the menu wrap so that no offscreen area exists or that the background be displayed on the offscreen part

Comment 1

[Yannick Koehler]

Attachment: test layout (minimal layout to show the problem.)

Comment 2

[Yannick Koehler]

Attachment: CSS Stylesheet that goes with the test layout

Comment 3

[Mats Palmgren (inactive)]

Attachment: Testcase #1, position:fixed; right:0

This is a reduced version of the markup/style from the first two attachments.
I think this is rendered correctly.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase #2, position:absolute; shrink-wrap width

Similar case, but with shrink-wrap width.

Comment 5

[Yannick Koehler]

The issue I have with this is that the LI on the right are rendered in a different style than the left ones even thought they are inside the same UL attribute and that UL is styled.

Using DOM navigation tools and such, when you go over the UL DOM part it correctly highlight the whole rectangle (from the styled part to the end of the list where the entries are unstyled) meaning the width of that DOM object (the UL) is taking the whole area not just the visible one.  Therefore I also think the style associated with the UL must follow its width.

But I am far from being a standard expert here.  Yet the behavior I see doesn't seem normal, why would someone want to have the overflow text scrollable but with a different style.

Comment 6

[Yannick Koehler]

What is the step to move this forward?  Who can confirm or not this issue?

Comment 7

[Eli Friedman]

The background doesn't extend beyond the bounds of the block.  The block's width is the available width. The inline content overflows the block, and therefore doesn't get a background.

You can probably get the behavior you want by floating the list and its container, which triggers shrink-wrapping.

Comment 8

[Yannick Koehler]

I solved my issue by adding overflow:auto to the regi and glob id.

Comment 9

[Mats Palmgren (inactive)]

I still think we render Testcase #2 wrong.

http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width
says that for absolutely positioned non-replaced elements the shrink-to-fit
width is: min(max(preferred minimum width, available width), preferred width).
Since there are no possible line breaks the "preferred minimum width" is
the width of the text which will also be the result of the equation above.

Note that the only difference between the examples in the testcase is
that the pink box has 'overflow: auto' whereas the yellow has
'overflow: visible' -- there is nothing in CSS 10.3.7 that says anything
about giving different results for different values of 'overflow' AFAICT.

FWIW, Opera 9 and WebKit have the correct layout IMO.

Comment 10

[Mats Palmgren (inactive)]

Attachment: Testcase #2b, slightly simplified version of #2

Comment 11

[Eli Friedman]

Isn't that just a variant of Bug 309110?

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Looks like it to me.

Comment 13

[Mats Palmgren (inactive)]

Bug 309110 was resolved WONTFIX and as far as I can tell we are not
compliant with the CSS 2.1 spec (see comment 9). Shouldn't we track
this discrepancy somehow, possibly requesting a change in the spec?

Comment 14

[Boris Zbarsky [:bzbarsky]]

I think so, yes.  Care to bring it up on www-style?

Comment 15

[Boris Zbarsky [:bzbarsky]]

Note, though, that the CSS spec doesn't say anywhere exactly how the "preferred minimum width" is computed...

Comment 16

[Boris Zbarsky [:bzbarsky]]

I sent mail.  Note that in Opera, the preferred min width seems to depend on the ancestors or something...  In particular, Opera renders the testcase in bug 309110 like we do (if you do s/overflow-x/overflow/).