- From: David Hyatt <hyatt@apple.com>
- Date: Tue, 02 Nov 2010 17:39:42 -0500
- To: Rob Crowther <robertc@boogdesign.com>
- Cc: www-style list <www-style@w3.org>, public-css-testsuite@w3.org
Really the sticking point is overflow:hidden, which is commonly used in conjunction with text-overflow to truncate content in the inline direction. In the vertical direction nothing is clipped. Think of a button built using inline-block that clips/truncates its content horizontally (with ellipses). If you force the baseline to be the bottom margin edge just because overflow:hidden was specified, then you can no longer baseline align this control. What the spec says makes sense to me for overflow:auto/scroll, and we could change that in WebKit I think, but there's a problem with what is specified for overflow:hidden. dave (hyatt@apple.com) On Nov 2, 2010, at 5:30 PM, David Hyatt wrote: > This may be difficult for us to change, since it's going to be a compatibility concern for us (given how heavily inline-block is used on OS X in conjunction with overflow:hidden). > > WebKit's current behavior (which predates the spec, and is in my opinion superior to what is specified) is actually to respect the line box baseline if the overflow section isn't scrolled and the line box baseline is visible. Otherwise we do switch to using the bottom margin edge. This allows overflow:hidden inline blocks that don't actually end up doing any clipping in the block progression direction to still respect baseline alignment. > > dave > > On Nov 2, 2010, at 5:21 PM, Rob Crowther wrote: > >> On 02/11/10 16:03, Rob Crowther wrote: >>> Boris Zbarsky wrote: >>>> Yep, that'd be a bug. Want to report it to the webkit folks? ;) >>>> >>> Yeah, I'll do it this evening. >>> >> There's already an open defect: >> >> https://bugs.webkit.org/show_bug.cgi?id=36084 >> >> Rob >> > >
Received on Tuesday, 2 November 2010 22:40:16 UTC