WebKit falls back to text-overflow: clip (the default). Firefox and Opera handle this correctly. Example: 4th example in the spec; http://www.w3.org/TR/css3-ui/#text-overflow http://dev.w3.org/csswg/css3-ui/#text-overflow Sample markup <div style="text-overflow:ellipsis; overflow:hidden"> NESTED <p>PARAGRAPH</p> WON'T ELLIPSE. </div>
Created attachment 173534 [details] test case from the spec Expected results: an ellipsis after the words:'nested', 'won't and 'ellipse'. Actual results: no ellipsis is shown.
Created attachment 188244 [details] Patch Fix for bug
Comment on attachment 188244 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=188244&action=review > Source/WebCore/rendering/RenderBlockLineLayout.cpp:1828 > // FIXME: CSS3 says that descendants that are clipped must also know how to truncate. This is insanely > // difficult to figure out (especially in the middle of doing layout), and is really an esoteric pile of nonsense > // anyway, so we won't worry about following the draft here. It looks like you're partially implementing this FIXME. Do we care about the multiple-nested anonymous block case? > Source/WebCore/rendering/RenderBlockLineLayout.cpp:1830 > + bool hasTextOverflow = (style()->textOverflow() && hasOverflowClip()) > + || (isAnonymousBlock() && parent() && parent()->isRenderBlock() && parent()->style()->textOverflow() && parent()->hasOverflowClip()); Since textOverflow is the uncommon case, this will always hit the second part of the branch, but will exit quickly with the isAnonymousBlock check. I dno't think this code is super-hot, but it's on a common path.
(In reply to comment #3) > (From update of attachment 188244 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=188244&action=review > > > Source/WebCore/rendering/RenderBlockLineLayout.cpp:1828 > > // FIXME: CSS3 says that descendants that are clipped must also know how to truncate. This is insanely > > // difficult to figure out (especially in the middle of doing layout), and is really an esoteric pile of nonsense > > // anyway, so we won't worry about following the draft here. > > It looks like you're partially implementing this FIXME. Do we care about the multiple-nested anonymous block case? Can you explain to me when this case happens (or link to the spec that describes this behavior)? It is possible that it makes the most sense to just update the FIXME saying that it doesn't work in the multiple nested anonymous block case and file a bug for that. > > Source/WebCore/rendering/RenderBlockLineLayout.cpp:1830 > > + bool hasTextOverflow = (style()->textOverflow() && hasOverflowClip()) > > + || (isAnonymousBlock() && parent() && parent()->isRenderBlock() && parent()->style()->textOverflow() && parent()->hasOverflowClip()); > > Since textOverflow is the uncommon case, this will always hit the second part of the branch, but will exit quickly with the isAnonymousBlock check. I dno't think this code is super-hot, but it's on a common path. I'm not sure I understand what needs to be changed here. Are you suggesting that I flip around the order of the conditions in the or expression?
Created attachment 189547 [details] Patch Updated FIXME comment to reflect that this change fixes part of what it is referring to.
Comment on attachment 189547 [details] Patch This seems reasonable to me. Mitz and Hyatt are CC'd and can scream if they disagree.
Comment on attachment 189547 [details] Patch Clearing flags on attachment: 189547 Committed r143754: <http://trac.webkit.org/changeset/143754>
All reviewed patches have been landed. Closing bug.