Created attachment 8339647 [details]
Screenshot 2013-11-27 17.26.53.png
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131112160018
Steps to reproduce:
1. Go here: http://bowser.effectgames.com/~jhuckaby/bugs/firefox-text-overflow.html
2. Notice how main text overlaps float:right block.
Explanation: The page has a simple container DIV with a set width and some text, along with a float:right block with a fixed size. The main text is set to text-overflow:ellipsis and forced to a single line only. However, in Firefox, the main text overlaps the float:right block. It should wrap and have an ellipsis inserted before overlapping (as it does in Chrome and Safari).
Main text overlaps float:right block (see URL / screenshot).
Text should be cropped and have ellipsis inserted before hitting float:right block. This is how all other browsers render my page (I tried both Chrome and Safari).
I can reproduce this on latest Nightlies, so moving this to Core :: Layout.
Joseph, would you mind adding your testcase as an attachment to this bug so we'll still have it if your website or that page goes away at some point in the future? Thanks for the report! :-)
Firefox, IE10 and Opera(Presto) does this correctly per spec. The overflow occurs
at the block edge and that's the edge that is relevant for ellipsing.
Please report the bug to webkit.
That said, I do sympathize with your use case. I think it would be a useful feature
to add to the spec, something like "text-overflow-ellipsing-edge: block | line".
Feel free to propose it on email@example.com if you want.
Why would anyone ever prefer the spec behavior over the WebKit behavior? Maybe the spec should just change, which would be far better than having an additional property.
I agree with David. Why dies the spec say what it does?
Created attachment 8339998 [details]
As requested, the test case as an HTML attachment, in case my server goes down.
Created attachment 8340052 [details]
Consider the following testcase. In the block at the top the text
overlaps the float but does *not* overflow the block. Still, webkit
does ellipsing here. The middle block has the float removed, this is
just so that you can verify that the text does not overflow. The block
at the bottom is the same as the first, except with overflow:visible.
If we change the spec to ellipsize at the line box edge instead of the
block's content edge then I think it would be logical to also ellipsize
for overflow:visible (the bottom block), because text-overflow is then
unrelated to block overflow.
This seems like a dup of bug 864759?
There is a very interesting discussion about this very bug over at WebKit: https://bugs.webkit.org/show_bug.cgi?id=115746
They concluded that the text should indeed clip at the edge of the float:right DIV, not at the boundary of the outer DIV, and closed the bug.
Yeah, they did the usual webkit thing of silently deciding to ignore the spec if they don't like it without bothering to submit feedback about the spec needing to change. :(
(In reply to Boris Zbarsky [:bz] from comment #9)
> Yeah, they did the usual webkit thing of silently deciding to ignore the
> spec if they don't like it without bothering to submit feedback about the
> spec needing to change. :(
To be fair, in this case the spec is probably newer than their implementation, no?
If you read the bug cited in comment 8, they checked in a patch to follow the spec as written around end of May 2013, then backed it out about a month later because they decided they wanted to keep the old behavior.
All of that very much postdates the spec. So I think comment 9 is in fact an eminently fair summary of what they did.
So should we bring this to the CSSWG's attention perhaps?
FWIW, I don't feel strongly either way about the technical issue at hand.
I can easily change our implementation to use line box edges instead of
block edges if the CSSWG decide to change the spec.
I *do* feel strongly about Apple blatantly disregarding CSS specs though.
And when it is pointed out to them they don't even honor you with a response.
I find such behavior uncivilized, to put it mildly.
Agreed with bz and dbaron. I also agree with Mat's additional point in Comment 6 regarding attachment 8340052 [details].
Since both require changes in several shipping implementations, yes, as Mat suggests, I'll mail www-style about it with a proposed edit to text-overflow (with an objection time-out of say a week, and then make the spec edit next week assuming no objections).
fantasai - any comment before I move forward on this?
This proposal was posted to www-style in Feb 2014 (by Tantek):
Tab responded "Sounds reasonable to me". There were no other responses.
I'm not sure if the spec has been updated, the opening sentence is still:
"This property specifies rendering when inline content overflows its block container element"
for example, which seems wrong given the proposal.
Tantek, can I assume the proposal was accepted in the CSSWG?
When will the spec be updated?
BTW, is the revision history for this spec publicly accessible somewhere?
It would be very useful to be able to see which edits have been made.
(In reply to Mats Palmgren (:mats) from comment #15)
> This proposal was posted to www-style in Feb 2014 (by Tantek):
> Tab responded "Sounds reasonable to me". There were no other responses.
> I'm not sure if the spec has been updated, the opening sentence is still:
> "This property specifies rendering when inline content overflows its block
> container element"
> for example, which seems wrong given the proposal.
> Tantek, can I assume the proposal was accepted in the CSSWG?
Yes, there was no objection.
> When will the spec be updated?
Issue and resolution captured: https://wiki.csswg.org/spec/css3-ui#issue-32
Updating editor's draft next.
> BTW, is the revision history for this spec publicly accessible somewhere?
> It would be very useful to be able to see which edits have been made.
Yes it's on Mercurial on the W3C server.
Editor's draft updated to line box edge rather than block container edge.
*** Bug 1149710 has been marked as a duplicate of this bug. ***