User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:184.108.40.206) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:220.127.116.11) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Combining overflow:hidden and display:inline-block appears to give wrong offset and/or height numbers to the layout engine.
Results are sensitive to the vertical-align setting. Default and explicit vertical-align:baseline both produce the problem. Explicit vertical-align:top removes it.
Possibly related to Bug 235524, though the numbers I'm seeing here look plain wrong; they're not "as if we weren't clipping" as suggested by that bug.
Steps to Reproduce:
1. Load attached ff_overflow_hidden.html
In case 3, the two spans are misaligned; the left is 5px lower than the right. Firebug reports this as extra top offset.
In case 4, the containing para has 5px of unexpected space at the bottom.
Will attach screenshot.
Span pairs should be aligned vertically in all cases.
There should be no background-para visible above or below the spans.
IE7 and WebKit (Chrome) both render the demo page as expected. Opera (9.62) exhibits the same bug as FF for case 3 but not case 4.
Created attachment 375851 [details]
Minimal page demonstrating bug
Created attachment 375852 [details]
Screenshot of actual results
Reproduced on Mac, changing Platform to All
Still reproducible as of FF 3.5.3
As far as I can tell, in an overflow:hidden inline-block Gecko is treating the bottom of the box (including glyph descent) as its baseline, and (with vertical-align:baseline) lining that up with the parent's baseline. The misalignment is exaggerated if you set a big line-height.
Using overflow-x:hidden doesn't help.
Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091201 Minefield/3.7a1pre
This bug does not occur in Safari 4 and Chrome 3 eg webkit.
In transitional mode if one of the two spans is removed (point 4 from the testcase) which have display:inline-block, vertical-align:top and overflow:hidden, the bug disappears. But if the doctype is switched to strict mode the bug is still there.
Oops, to correct myself point 4 does not have vertical-align:top.
I thought I commented on this already; that suggests it might be a duplicate of another bug that I did comment on.
In any case, it's not completely obvious to me what the correct behavior is here; things with overflow: hidden, auto, or scroll are scrollable, and we currently treat their baseline as being at the bottom of the container. Maybe we should inside the scrollable area and get the baseline from what's inside as though it's scrolled to its initial position. The question then is whether to do that for all values of 'overflow' or just some of them.
Additional testcases involving 'overflow:auto' and 'overflow:scroll' might be useful.
Actually, according to CSS 2.1, our behavior is correct and WebKit's is wrong. http://www.w3.org/TR/CSS21/visudet.html#propdef-vertical-align says:
# The baseline of an 'inline-block' is the baseline of its last line box in
# the normal flow, unless it has either no in-flow line boxes or if its
# 'overflow' property has a computed value other than 'visible', in which case
# the baseline is the bottom margin edge.
I think if you want to propose a spec change, the working group might be receptive to it; however, without a spec change the spec is quite clear that this bug is invalid since our current behavior is correct.
dbaron: I bow to your spec-fu.
I also see your point about the non-obviousness of correct behaviour in the general case. The reason this was annoying me was text-overflow:ellipsis, which requires the "display:inline-block; overflow:hidden" combo even though you don't explicitly want either of them. However, comment 82 on Bug 312156 mentions that "Dave Hyatt wanted to remove the dependency on overflow:hidden", and that feels like a better solution.
*** Bug 570060 has been marked as a duplicate of this bug. ***
*** Bug 737757 has been marked as a duplicate of this bug. ***
This workaround solved the problem for me. From David Tang on: https://bugzilla.mozilla.org/show_bug.cgi?id=737757#c1
"Setting the child's vertical-align to anything other than baseline produces the correct height."