W3C home > Mailing lists > Public > www-style@w3.org > April 2013

Re: [css3-text-overflow] Question regarding float and text-overflow: ellipsis

From: Alan Gresley <alan@css-class.com>
Date: Wed, 24 Apr 2013 19:53:08 +1000
Message-ID: <5177AB84.4030608@css-class.com>
To: Øyvind Stenhaug <oyvinds@opera.com>
CC: Zalan Bujtas <zbujtas@gmail.com>, Robert O'Callahan <robert@ocallahan.org>, www-style <www-style@w3.org>
On 23/04/2013 6:59 PM, Øyvind Stenhaug wrote:
> On Tue, 23 Apr 2013 07:54:39 +0200, Robert O'Callahan
> <robert@ocallahan.org> wrote:
>
>> I think this is unspecified.
>>
>> I think it wouldn't be hard for us (Mozilla) to change our rendering to
>> exclude floats when we decide where to draw the ellipsis, and that sounds
>> reasonable. File a bugzilla bug.
>
> The spec says:
>
> "This property specifies rendering when inline content overflows its
> block container element […]"
>
> If floats are to be excluded then this part should be changed. Maybe it
> would talk about overflowing line boxes instead, I don't know.

This is not really a bug with using ellipsis, inputs or floats.

The input has both overflow: hidden and white-space: nowrap and this is 
causing the bug like behaviour. The reason that you can not interact 
with the input is because the line box is painted above all the other 
elements.

The implementations are disagreeing over how white-space: nowrap should 
work with overflow: hidden. The test case itself is over constrained.

IE10 seems do to what I would expect in such an over constrained 
situation and that is to clip the text and eclipses at the left edge of 
the input and thus allowing the input to be interacted with. Please see 
attachment showing IE10 behaviour.


Alan




-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/


input.jpg
(image/jpeg attachment: input.jpg)

Received on Wednesday, 24 April 2013 09:53:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 24 April 2013 09:53:40 UTC