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.
Thanks for bringing the discussion there. FYI, this works in Chrome.
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.
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.
(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"
(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
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.
(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.)
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
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.
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.
... and by "removing" here I mean its DisplayItems during the paint process, nothing in the DOM / frame tree is ever affected by ellipsing.
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.
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)
Yeah, after reading the www-style thread I agree with dholbert that this shouldn't work.
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 ;-)
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.
(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