Last Comment Bug 491549 - overflow:hidden + display:inline-block causes vertical misalignment
: overflow:hidden + display:inline-block causes vertical misalignment
: testcase
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: unspecified
: All All
-- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
: 570060 737757 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2009-05-05 12:57 PDT by Mike Capp
Modified: 2012-07-12 16:15 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Minimal page demonstrating bug (2.09 KB, text/html)
2009-05-05 12:59 PDT, Mike Capp
no flags Details
Screenshot of actual results (22.26 KB, image/png)
2009-05-05 13:01 PDT, Mike Capp
no flags Details

Description User image Mike Capp 2009-05-05 12:57:44 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv: 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: 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.

Reproducible: Always

Steps to Reproduce:
1. Load attached ff_overflow_hidden.html

Actual Results:  
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.

Expected Results:  
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.
Comment 1 User image Mike Capp 2009-05-05 12:59:15 PDT
Created attachment 375851 [details]
Minimal page demonstrating bug
Comment 2 User image Mike Capp 2009-05-05 13:01:46 PDT
Created attachment 375852 [details]
Screenshot of actual results
Comment 3 User image Mike Capp 2009-05-05 14:04:44 PDT
Reproduced on Mac, changing Platform to All
Comment 4 User image Mike Capp 2009-09-16 06:56:22 PDT
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.
Comment 5 User image Emil Ivanov 2009-12-01 17:01:44 PST
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.
Comment 6 User image Emil Ivanov 2009-12-01 17:18:22 PST
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.
Comment 7 User image Emil Ivanov 2009-12-01 17:28:06 PST
Oops, to correct myself point 4 does not have vertical-align:top.
Comment 8 User image David Baron :dbaron: ⌚️UTC-8 2009-12-01 21:05:45 PST
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.
Comment 9 User image David Baron :dbaron: ⌚️UTC-8 2009-12-01 21:11:50 PST
Actually, according to CSS 2.1, our behavior is correct and WebKit's is wrong. 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.
Comment 10 User image Mike Capp 2009-12-02 07:22:05 PST
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.
Comment 11 User image philippe (part-time) 2010-06-03 20:59:45 PDT
*** Bug 570060 has been marked as a duplicate of this bug. ***
Comment 12 User image Cork 2012-03-20 23:52:03 PDT
*** Bug 737757 has been marked as a duplicate of this bug. ***
Comment 13 User image Johnny Rodgers 2012-07-12 16:15:07 PDT
This workaround solved the problem for me. From David Tang on:

"Setting the child's vertical-align to anything other than baseline produces the correct height."

Note You need to log in before you can comment on or make changes to this bug.