Last Comment Bug 944200 - CSS text-overflow ellipsis overlaps float:right elements
: CSS text-overflow ellipsis overlaps float:right elements
Status: REOPENED
csswg
: testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: 25 Branch
: All All
: -- enhancement with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 1149710 (view as bug list)
Depends on: 864759
Blocks: 1070742
  Show dependency treegraph
 
Reported: 2013-11-27 17:29 PST by Joseph Huckaby
Modified: 2015-04-01 14:16 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshot 2013-11-27 17.26.53.png (315.50 KB, image/png)
2013-11-27 17:29 PST, Joseph Huckaby
no flags Details
firefox-text-overflow.html (1.18 KB, text/html)
2013-11-28 08:19 PST, Joseph Huckaby
no flags Details
Testcase #2 (736 bytes, text/html)
2013-11-28 10:29 PST, Mats Palmgren (:mats)
no flags Details

Description Joseph Huckaby 2013-11-27 17:29:50 PST
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).


Actual results:

Main text overlaps float:right block (see URL / screenshot).

http://bowser.effectgames.com/~jhuckaby/bugs/firefox-text-overflow.html

https://www.dropbox.com/s/0plw11wuug1sq56/Screenshot%202013-11-27%2017.26.53.png



Expected results:

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).
Comment 1 :Gijs Kruitbosch (away 26-29 incl.) 2013-11-28 02:14:01 PST
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! :-)
Comment 2 Mats Palmgren (:mats) 2013-11-28 06:57:20 PST
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 www-style@w3.org if you want.
Comment 3 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2013-11-28 07:50:09 PST
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.
Comment 4 Boris Zbarsky [:bz] 2013-11-28 08:00:52 PST
I agree with David.  Why dies the spec say what it does?
Comment 5 Joseph Huckaby 2013-11-28 08:19:41 PST
Created attachment 8339998 [details]
firefox-text-overflow.html

As requested, the test case as an HTML attachment, in case my server goes down.
Comment 6 Mats Palmgren (:mats) 2013-11-28 10:29:39 PST
Created attachment 8340052 [details]
Testcase #2

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.
Comment 7 Kang-Hao (Kenny) Lu [:kennyluck] 2013-11-29 08:09:48 PST
This seems like a dup of bug 864759?
Comment 8 Joseph Huckaby 2013-11-29 08:33:48 PST
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.
Comment 9 Boris Zbarsky [:bz] 2013-11-29 14:28:59 PST
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.  :(
Comment 10 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2013-12-02 18:35:17 PST
(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?
Comment 11 Boris Zbarsky [:bz] 2013-12-02 18:41:02 PST
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.
Comment 12 Mats Palmgren (:mats) 2014-02-01 06:09:14 PST
So should we bring this to the CSSWG's attention perhaps?
Comment 13 Mats Palmgren (:mats) 2014-02-01 06:21:28 PST
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.
Comment 14 Tantek Çelik 2014-02-03 14:52:07 PST
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?
Comment 15 Mats Palmgren (:mats) 2014-09-26 13:34:21 PDT
This proposal was posted to www-style in Feb 2014 (by Tantek):
http://lists.w3.org/Archives/Public/www-style/2014Feb/0140.html

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"
http://dev.w3.org/csswg/css-ui/#text-overflow
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.
Comment 16 Tantek Çelik 2014-11-20 21:18:57 PST
(In reply to Mats Palmgren (:mats) from comment #15)
> This proposal was posted to www-style in Feb 2014 (by Tantek):
> http://lists.w3.org/Archives/Public/www-style/2014Feb/0140.html
> 
> 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"
> http://dev.w3.org/csswg/css-ui/#text-overflow
> 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.

https://dvcs.w3.org/hg/csswg/file/176c544cf1c5/css-ui
Comment 17 Tantek Çelik 2014-11-20 21:39:52 PST
Editor's draft updated to line box edge rather than block container edge.

http://dev.w3.org/csswg/css-ui/
Comment 18 Boris Zbarsky [:bz] 2015-04-01 14:16:20 PDT
*** Bug 1149710 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.