- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Tue, 1 Mar 2011 15:36:52 -0800
- To: David Hyatt <hyatt@apple.com>
- Cc: robert@ocallahan.org, Rob Crowther <robertc@boogdesign.com>, www-style list <www-style@w3.org>, public-css-testsuite@w3.org
On Tue, Nov 2, 2010 at 20:11, David Hyatt <hyatt@apple.com> wrote: > On Nov 2, 2010, at 7:44 PM, Robert O'Callahan wrote: > > On Wed, Nov 3, 2010 at 11:39 AM, David Hyatt <hyatt@apple.com> wrote: >> >> 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. > > > Sounds like what you really want is overflow-x:hidden, overflow-y:visible > ... with the baseline behavior depending only on overflow-y. > > Yeah, that would be an acceptable solution. Unfortunately CSS2.1 doesn't > define overflow-x and overflow-y and only talks in terms of overflow. > That's really what creates the problem here. Maybe the language could be > modified to state overflow in a particular direction without naming the > specific properties? I've accepted this an issue for CSS3-UI, that is, that CSS3 UI should define 'overflow-x' and 'overflow-y' properties. http://wiki.csswg.org/spec/css3-ui#issue-19 Thanks, Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Received on Tuesday, 1 March 2011 23:39:11 UTC