Last Comment Bug 912434 - text-overflow: ellipsis does not work, when specified on an element that has "display: flex"
: text-overflow: ellipsis does not work, when specified on an element that has ...
Status: RESOLVED INVALID
[DocArea=CSS]
: dev-doc-needed
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-04 03:20 PDT by Anthony Ricaud (:rik)
Modified: 2015-02-03 10:59 PST (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (2.74 KB, text/html)
2013-09-04 03:20 PDT, Anthony Ricaud (:rik)
no flags Details
testcase 2: flex container with anonymous vs. explicit flex item [demonstrating webkit inconsistency] (456 bytes, text/html)
2013-09-04 11:38 PDT, Daniel Holbert [:dholbert]
no flags Details
Testcase #3 (try it in Chrome) (252 bytes, text/html)
2013-09-04 13:10 PDT, Mats Palmgren (vacation)
no flags Details

Description Anthony Ricaud (:rik) 2013-09-04 03:20:16 PDT
Created attachment 799391 [details]
Testcase

See the attached test case.
Comment 1 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2013-09-04 04:25:49 PDT
Posted http://lists.w3.org/Archives/Public/www-style/2013Sep/0070.html on whether this ought to work.  The spec currently says it shouldn't, I think, but the expectation that it does seems reasonable.  See post for details.
Comment 2 Anthony Ricaud (:rik) 2013-09-04 04:59:27 PDT
Thanks for bringing the discussion there. FYI, this works in Chrome.
Comment 3 Daniel Holbert [:dholbert] 2013-09-04 11:38:55 PDT
Created attachment 799679 [details]
testcase 2: flex container with anonymous vs. explicit flex item [demonstrating webkit inconsistency]

I think we're actually correct on this.

What's not clear in the original testcase is that we generate an anonymous box (the "anonymous flex item") around the raw text in the flex container, and **that anonymous box** is really what needs to have "text-overflow:ellipsis" if we want an ellipsis.

For some reason, webkit lets that anonymous box inherit the "text-overflow" value from the flex container (or something like that).  It does *not* do this if you use an *explicit* flex item (just wrapping the text in a <div>), instead of an anonymous flex item, as shown by this testcase.

Other properties (e.g. "border") don't inherit from the flex container to its anonymous flex item, so I don't see why "text-overflow" should inherit.

So, I tend to think this is actually a webkit bug.
Comment 4 Daniel Holbert [:dholbert] 2013-09-04 11:44:59 PDT
If we really want this specific use-case to work, I think we could add a "text-overflow: inherit" rule to the *|*::-moz-anonymous-flex-item  block in ua.css. (sort of like how certain properties inherit from a table's anonymous outer-frame to the table itself)

I worry, though, that if we establish a rule of "flex containers with raw text should behave like blocks with raw text, including the handling of properties", then we're going to need to add a *lot* of inherited properties there.
Comment 5 Daniel Holbert [:dholbert] 2013-09-04 11:46:52 PDT
(In reply to Daniel Holbert [:dholbert] from comment #4)
> I worry, though, that if we establish a rule of "flex containers with raw
> text should behave like blocks with raw text, including the handling of
> properties"

I meant to say at the end there:
... "including the handling of *non-inherited* properties, *despite* the anonymous flex item being in the way"
Comment 6 Daniel Holbert [:dholbert] 2013-09-04 11:53:57 PDT
(In reply to Daniel Holbert [:dholbert] from comment #3)
> What's not clear in the original testcase is that we generate an anonymous
> box (the "anonymous flex item") around the raw text in the flex container,
> and **that anonymous box** is really what needs to have
> "text-overflow:ellipsis" if we want an ellipsis.

This is sort of what Tab just said on www-style, here:
 http://lists.w3.org/Archives/Public/www-style/2013Sep/0084.html
Comment 7 Mats Palmgren (vacation) 2013-09-04 13:10:15 PDT
Created attachment 799728 [details]
Testcase #3 (try it in Chrome)

Having multiple ellipsis seems less desirable though, especially since
in the A's does not overflow the flex container.
Although I see we have text-overflow:inherit on ::-moz-column-content
in ua.css already so I guess that can already occur for columns.
Comment 8 Daniel Holbert [:dholbert] 2013-09-04 13:36:19 PDT
(In reply to Mats Palmgren (:mats) from comment #7)
> Created attachment 799728 [details]
> Testcase #3 (try it in Chrome)
> 
> Having multiple ellipsis seems less desirable though

That's a good point. In your testcase, AAAAAAAAA<b>B</b>CCCCCCCC, we generate 3 flex items, the first and last being anonymous & using the parent's "text-overflow" value.

Note also that any attempts at inline styling on raw text inside of a flexbox will already fail (since inline elements like the <b> in this example will automatically get promoted to block-level and converted to flex items). So, I don't think it's a particularly useful to add special cases to make "text-overflow" work, when <b>/<span>/etc. already _won't_ do what the author expects.

> Although I see we have text-overflow:inherit on ::-moz-column-content
> in ua.css already so I guess that can already occur for columns.

That makes more sense -- in that case, the ::-moz-column-content is more conceptually still a part of the multicol element (as indicated by the fact that it has "display: inherit" in ua.css), and there's also no way to directly style the columns themselves.  (Whereas in a flex container, you *can* style the flex items - you just need to explicitly add an element for each flex item.)
Comment 9 Mats Palmgren (vacation) 2013-09-04 14:39:50 PDT
One could also argue that flex container ellipsing should remove the whole item
as an atomic unit when it overflows the container.  That behavior would be more
consistent with how a block removes inline-block and replaced element children
as atomic units, compare for example:
https://bug312156.bugzilla.mozilla.org/attachment.cgi?id=529421
Comment 10 Daniel Holbert [:dholbert] 2013-09-04 14:46:50 PDT
I'm not sure what you mean by "remove the whole item as an atomic unit", as applied to your testcase.

In the testcase you attached, there are *three* flex items -- not one -- so I don't know what you mean by "the whole item". Each of those three items is sized (and shrunk) according the rules of the flex layout algorithm. Only after that do we find out that there's going to be text overflowing.
Comment 11 Mats Palmgren (vacation) 2013-09-04 15:13:05 PDT
In my example it would mean removing the last of those three items - the anonymous item
that contains the C's.  The remaining two items are not overflowing the flex container
so they are left as is and not resized in any way since ellipsing never affects layout
at all.
Comment 12 Mats Palmgren (vacation) 2013-09-04 15:23:11 PDT
... and by "removing" here I mean its DisplayItems during the paint process,
nothing in the DOM / frame tree is ever affected by ellipsing.
Comment 13 Daniel Holbert [:dholbert] 2013-09-04 15:29:29 PDT
OK -- thanks for clarifying. I think I understand what you're describing, but I'm not convinced it'd be particularly useful, especially in light of my second paragraph in comment 8.
Comment 14 Daniel Holbert [:dholbert] 2013-09-04 16:04:26 PDT
For reference: I posted to www-style expressing skepticism about the value of supporting this:
  http://lists.w3.org/Archives/Public/www-style/2013Sep/0089.html
...and I also posted with two possible routes forward to make "text-overflow" work in a flex container, neither of which I particularly like:
  http://lists.w3.org/Archives/Public/www-style/2013Sep/0090.html
(The latter way, flagged "ALTERNATELY", is essentially what Mats suggested here in comment 11-12)
Comment 15 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2013-09-05 03:29:11 PDT
Yeah, after reading the www-style thread I agree with dholbert that this shouldn't work.
Comment 16 Jean-Yves Perrier [:teoli] 2013-09-05 04:01:22 PDT
Added the dev-doc-needed flag so that I can update the doc one way or the other once the problem would have been settled ;-)
Comment 17 Daniel Holbert [:dholbert] 2013-09-05 12:32:24 PDT
OK, I'm going to call this INVALID, then, since the current behavior is correct per spec, and there doesn't seem to be anyone lobbying to change the spec on this.

I'll file a Blink bug on the fact that this "works" in chrome (when it shouldn't), too.

Rik, if you need this to work, you should be able to get the behavior you want by putting your testcase's <p> styling on a <div> *inside* of a "display:flex" element. (Or just don't use "display:flex", since (at least in your testcase) it doesn't add anything.)  Feel free to ping me on IRC if you have further questions about this.
Comment 18 Daniel Holbert [:dholbert] 2013-09-05 13:05:09 PDT
(In reply to Daniel Holbert [:dholbert] from comment #17)
> I'll file a Blink bug on the fact that this "works" in chrome (when it
> shouldn't), too.

Filed: http://code.google.com/p/chromium/issues/detail?id=285943

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