If either overflow-x or overflow-y value is not visible, Webkit will change it to auto
https://bugs.webkit.org/show_bug.cgi?id=17488
Summary If either overflow-x or overflow-y value is not visible, Webkit will change i...
johnnyding
Reported 2008-02-22 06:41:23 PST
See attached test cause, The first div has style: ""height:100px; overflow-y:hidden; overflow-x:visable; width:1px", which means the page author wants to make sure that the div box have hidden clipped content in y direction, but doesn't clip the content in x direction. In IE 6/7, Opera 9, I think they have correct behavior. But in FireFox 2/3, Safari, the overflow-y:hidden will cause the actual used value of overflow-x is auto, since the div's width is not long enough for creating horizontal bar, the content in x direction has been clipped. The reason of this problem is if either overflow-x or overflow-y value is not visible, Webkit will change it to auto. then the element will be treated as having overflow clip property. See function CSSStyleSelector::adjustRenderStyle (file: CSSStyleSelector.cpp, line:1201) and function RenderBox::setStyle (file: RenderBox.cpp, line:110). I did not see that The CSS 2(http://www.w3.org/TR/CSS21/visufx.html#propdef-overflow) and CSS3(http://www.w3.org/TR/2002/WD-css3-box-20021024/#the-overflow-x) specification have define the behavior just like webkit did. Is that a bug? Anyone can point me for this problem. The problem caused some contentz can't be displayed in webpages for some high traffic Chinese websites.
Attachments
test case for this problem (581 bytes, text/html)
2008-02-22 06:42 PST, johnnyding
no flags
Overflow-x/y visible/hidden testcase (840 bytes, text/html)
2008-04-01 00:31 PDT, Faruk Ates
no flags
johnnyding
Comment 1 2008-02-22 06:42:23 PST
Created attachment 19278 [details] test case for this problem
johnnyding
Comment 2 2008-02-26 01:19:51 PST
How about using 2 flags: m_hasOverflowXClip, m_hasOverflowYClip instead of using m_hasOverflowClip, then we can discriminationally deal with clipped content in either x or y direction.
Faruk Ates
Comment 3 2008-04-01 00:29:50 PDT
The reason why your test case breaks is because it's spelled "visible" (not visable) — changing it to visible makes the JavaScript detect the property correctly. Nonetheless, the behavior is still incorrect: adding a test case that shows this in a different way. The combination of overflow-x: visible; overflow-y: hidden; (or vice-versa) is a desirable combination and should behave exactly as it reads: elements expanding outside the containing "viewport" should only be rendered along the x-axis but not along the y-axis. What doesn't get defined by the spec, however, is what happens to content that is outside _both_ x and y axes. Should elements always get clipped to exact rectangles? (by far easiest to implement) Which axis/setting gets precedence? Letting it be dependent on CSS property order AND allowing for non-rect rendering would be very tricky to implement I'm sure.
Faruk Ates
Comment 4 2008-04-01 00:31:12 PDT
Created attachment 20270 [details] Overflow-x/y visible/hidden testcase The overflow-x: visible; should mean that on the x-axis, the element should still be rendered. Instead, it is being treated as overflow-x: scroll.
vituko
Comment 5 2010-01-15 00:07:34 PST
Sorry Until the patch comes, possible workaround : overflow-x:hidden + padding-right (scroll width) ... ... but the padding is seen in IE and Firefox, both work as expected. The behavior in Opera and Khtml is similar to Webkit. overflow-x:visible also becomes auto in Firefox, but the vertical scroll width is computed and the box pushes its container without showing the horizontal scroll nor hiding some content.
Simon Fraser (smfr)
Comment 6 2011-02-23 22:25:49 PST
Firefox does the same thing.
Simon Fraser (smfr)
Comment 7 2011-05-19 17:21:50 PDT
Note You need to log in before you can comment on or make changes to this bug.