overflow:hidden + display:inline-block causes vertical misalignment

RESOLVED INVALID

Status

()

Core
Layout: Block and Inline
RESOLVED INVALID
8 years ago
3 months ago

People

(Reporter: Mike Capp, Unassigned)

Tracking

({testcase})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-webkit])

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:1.9.0.10) 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:1.9.0.10) 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.
(Reporter)

Comment 1

8 years ago
Created attachment 375851 [details]
Minimal page demonstrating bug
(Reporter)

Comment 2

8 years ago
Created attachment 375852 [details]
Screenshot of actual results
(Reporter)

Comment 3

8 years ago
Reproduced on Mac, changing Platform to All
OS: Windows Server 2003 → All
Hardware: x86 → All

Updated

8 years ago
Component: General → Layout: Block and Inline
Product: Firefox → Core
QA Contact: general → layout.block-and-inline
(Reporter)

Comment 4

8 years ago
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

8 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [parity-webkit]

Comment 6

8 years ago
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.
Keywords: testcase

Comment 7

8 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
(Reporter)

Comment 10

8 years ago
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.

Updated

7 years ago
Duplicate of this bug: 570060

Updated

5 years ago
Duplicate of this bug: 737757

Comment 13

5 years ago
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."

Comment 14

3 months ago
Also setting "display:flex" to a parent element kind of solves vertical misalignment problem.
You need to log in before you can comment on or make changes to this bug.