Joeri Sebrechts Reporter
	Description • 19 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Please implement support for the ellipsis value of the text-overflow property in
CSS3's text module.

Reproducible: Always

Steps to Reproduce:
1. Use text-overflow: ellipsis on any element in combination with overflow: hidden

Actual Results:  
Text is cut off correctly, but rendered without ending ellipsis.


Expected Results:  
Render the text cut off, but with ending ellipsis.

	Gérard Talbot
	Comment 1 • 19 years ago

CSS3 Text module is still a working draft as far as I understand.

http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-overflow

Note that the CSS3 Text Effects Module
W3C Working Draft 27 June 2005 says:
"Many sections intended for this module are not yet represented in this draft.
In particular, the 'text-justify-trim', 'text-indent', 'text-overflow' (...) and
related properties have not yet been evaulated."
http://www.w3.org/TR/css3-text/#changes

	Joeri Sebrechts Reporter
	Comment 2 • 19 years ago

The reason I am submitting this is because IE already has support for it (I
don't know how, but probably CSS3 got its cues from IE for this), and we (the
programming team I am in) are finding it limiting in real life web app
development projects that firefox does not have it available.

	Mathieu Parent
	Comment 3 • 19 years ago

from http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-overflow-mode

	Fredrik Branstrom
	Comment 4 • 19 years ago

My programming team too. Just voted for this bug.

I could probably accomplish the same effect with a hack like maybe .box {overflow:hidden;} .box:after {content:"...";} ?

	Fredrik Branstrom
	Comment 5 • 19 years ago

This would really be great for Firefox 1.5.

	Anne (:annevk)
	Comment 6 • 19 years ago

This is not going to happen for Firefox 1.5 (that one is near final) and please keep comments out of this bug that do not help with fixing it. This is also not a support forum. Thanks.

	Dão Gottwald [:dao]
	Comment 7 • 18 years ago

Safari supports this since 1.2, Konqueror since KDE 3.5.6.

	Victor Cortez
	Comment 8 • 18 years ago

I think its first time when IE is better than Firefox, fight for your prestige guys and make some update for this...

	Cory Johnson
	Comment 9 • 18 years ago

It may not be an approved standard, but Firefox risks letting Microsoft remain the innovator if it waits for the long process of standards approval...

	Ryan Jones-Ward [:sciguyryan]
	Comment 10 • 18 years ago

I'm not sure if this can be done until the new textframe code is in place (or it could work but maybe require adaptation in order to function with the new code).

I would also like to pointout that you should rad the Bugzilla Etiquette before replying to a bug (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html).

	Thomas Goldstein
	Comment 11 • 17 years ago

I guess a [parity-Opera] tag could now be added...

	Gérard Talbot
	Comment 12 • 17 years ago

Hello all,

I tried the attachment 202163 [details] with MSIE 7, Opera 9.24 and Safari 3.0.4 and none of the 3 browsers rendered the testcase as expected. The CSS 3 Text module, May 14 2003 Working Draft
clearly says: "This will result in the content of the span to be partially visible and the ellipsis will be shown" 
http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-overflow-mode
but there is no ellipsis rendered when trying attachment 202163 [details] with those 3 browsers.

----------

Another issue: the CSS Text Level 3, March 6th 2007 (latest) Working Draft says:

"Many sections intended for this module are not yet represented in this draft. In particular, the 'text-justify-trim', 'text-overflow', 'text-decoration', 'text-transformation', 'text-autospace', other properties have not yet been evaulated."
http://www.w3.org/TR/css3-text/#changes

Note that text-overflow-mode is not mentioned and no longer even mentioned as a property to evaluate.

	Joeri Sebrechts Reporter
	Comment 14 • 17 years ago

The reason the attachment doesn't work is because it uses text-overflow-mode instead of text-overflow. "text-overflow: ellipsis" does work in IE6 and Safari 3.0.4. -o-text-overflow works in Opera 9.

	Thomas Goldstein
	Comment 15 • 17 years ago

This site has a testcase that should work with all major browsers except Gecko ones:
http://www.css3.info/preview/text-overflow/

	Scott Trenda
	Comment 16 • 17 years ago

I've run into this several times in development, particularly concerning displaying longer messages within tables where the message has an action (mouseover, click) that will display the full text as a tooltip or in a popup window.

I'd like to point out that Gecko already has this ability built into XUL, through crop="right" or crop="end" for XUL elements that serve a purpose identical to that of <xul:label>. (menus, bookmarks, tabs, etc.) I've tried to force this behavior upon HTML elements, via Mozilla-specific CSS selectors, with no success to date.

I'm not sure how accurately the behavior of @xul:crop follows that of the CSS3 text-overflow proposal. However, at least until a proper implementation can be developed, it could serve as a functional hack to fill in the gap, and I'm certain it would fulfill the needs of most developers who need a workaround for Gecko. And I don't think anyone could seriously complain, if it's implemented as -moz-text-overflow while CSS3-Text is still a Working Draft.

Could a developer who's more familiar with the inner workings of @xul:crop take a look and see if it'd be possible to directly transfer its behavior onto HTML elements with -moz-text-overflow: ellipsis? I'm sure you'd have a lot of grateful developers if this could be done and patched for Firefox 2. :)

	Emil Ivanov
	Comment 17 • 17 years ago

So this is not working only in firefox :(

	Maxime Delorme
	Comment 19 • 16 years ago

text-overflow offers a lot of usability for the end user, it is IMHO an important feature

	Zhang Weiwu
	Comment 20 • 16 years ago

I also vote for this.

Not being a standard is NOT a reason to not to implement. The innovator influence the standard, and we don't want a world where all innovation comes from Microsoft. If we don't do this, then MS's marketing slogan is actually correct, that "MS is the real innovator in all the time".

I think we did -moz-opacity; -moz-corner-radius and there is no reason not to have -moz-text-overflow. Besides, IE & Safari & Opera's move to support text-overflow makes W3 not possible to do it differently in the final CSS3, so even if it's draft, it's the part 'unchangable' in the draft.

There are other bugs that ONLY FIREFOX has and IE does it better *since 10 years ago*. See 41489 . the reason not to fix that one was the same, waiting for standard body. I even wouldn't expect a change in another 10 years...

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 21 • 16 years ago

The main thing we need here is a spec. Among other things, it needs to describe:
-- what style the ellipsis has (font, color, etc) ... does it come from the text or does it come from the element with text-overflow on it?
-- does text-overflow inherit by default or not?
-- how does it work with text-align:right, does the ellipsis go on the left?
-- how does it work with bidi text, e.g. a line of Hebrew? What about mixed bidi text e.g. English followed by Hebrew? Can bidi text make the ellipsis appear at the beginning of the line? I'm particuarly interested in the case of an LTR word followed by an RTL word that doesn't fit, e.g.

english WERBEH

where only "english HEB" fits, where should the ellipsis go?
-- what happens if there's replaced content near the end of the line, say an image? Do you get the ellipsis or does the image overflow? If an ellipsis, where does the ellipsis go?

And more things that I haven't thought of yet :-). This information needs to be gathered for different browsers and the most sensible common behaviour agreed on. It will help get text-overflow added to CSS3 too.

That's the most important thing someone can do to move this along.

	Simon Montagu :smontagu
	Comment 22 • 16 years ago

For bidi I think it's reasonable to follow the natural bidi reordering of the ellipsed text, i.e. the ellipsis will always appear at the end of the line (right for left-to-right or left for right-to-left) just as end-of-paragraph punctuation does even when the last line ends in text in the other direction.

However, this won't necessarily Just Work if any string can be specified for the ellipsis, as in earlier versions of CSS3 Text [1].

Other issues with complex and international text that occur to me:

In shaped text, e.g. Arabic, if the last character that fits is joined to the first character that doesn't fit, should it appear in the joining form or the isolated form?

What happens in Indic languages where short vowels are reordered before the preceding consonant, e.g. "wikipedia", which in Hindi is "vikipIdiyA" (where "i" represents a short i and "I" represents a long i), and appears visually as ivikpIidyA. If either "ivi..." or "ivk..." fits but "ivik..." doesn't, what should appear?

And more things that I haven't thought of yet either :)

[1] http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-overflow-ellipsis

	Boris Yeltsin
	Comment 23 • 16 years ago

Thanks Roc and Simon for your comments. It certainly points out that this isn't quite as simple as it sounds.

To answer your questions though - we can at least look at how Safari, Opera and IE have solved these issues?

They've already implemented it, so we could learn from their experience/mistakes.

The lack of this feature is holding back several of my own web site designs. I can use ellipsis for the other 3 main browsers, but users with Firefox get a poor user experience as I have to cut off boxes half-way through characters.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 24 • 16 years ago

(In reply to comment #23)
> To answer your questions though - we can at least look at how Safari, Opera and
> IE have solved these issues?

We certainly should, because we need a spec that interoperates reasonably well with those browsers.

Anyone who wants to help could make a big contribution by writing some testcases covering those questions and anything else they can think of and documenting existing behaviour on those testcases. For bonus points, actually write a spec suggesting what the preferred behaviour should be.

	Joeri Sebrechts Reporter
	Comment 25 • 16 years ago

Had I known test cases and specs were what held this back I'd have submitted them much earlier. I'm on the case. If anyone has any suggestions for additional test cases that are needed, or suggestions for how the spec should be structured, please add them to this bug and I'll take those comments into account too.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 26 • 16 years ago

Thanks!

I think some previous versions of CSS3 Text had a draft specification for text-overflow, but it was pretty incomplete. Still worth taking into account if you can find it.

If you do come up with something reasonable you should post it to www-style since the CSS3 Text module needs this and I'm sure fantasai could use the help.

	fantasai
	Comment 27 • 16 years ago

The old spec is at http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-overflow-props but you're better off checking e.g. http://msdn.microsoft.com/en-us/library/ms531174(VS.85).aspx and running tests. I think for CSS3 Text we'll only want something like text-ellipsis: clip | ellipsis | <string>. I can add in the syntax definition to the spec very easily. The part I'm having trouble with is defining exactly how it works. When I ran tests several years ago Safari and IE had very different interpretations of which box the ellipses belonged to, but IIRC interoperability has improved since then.

	Joeri Sebrechts Reporter
	Comment 28 • 16 years ago

I've done some tests, see the attachment for the results. IE 6 and 7 have identical renderings. I also tested with Safari 3 and Opera 9.5. A firefox 3 reference rendering is included.

I had to make some guesses with the bidi tests, because it's not really something I have any experience with, so if I messed that part up, please tell me. Also, if someone could point me to some educational materials that could get me up to speed on the topic, please do.

Behavior common across all browsers:
- Images never cause ellipsis (not even for replaced text)
- The color and style of the ellipsis come from the style of the overflowing element, not the element that causes overflow
- Text-overflow does not inherit automatically
- "text-align: right" renders the same as "text-align: left" (text is cut off at the right and rendered with a right-hand ellipsis)
- If the overflowing character is right after an ellipsis, that ellipsis is replaced just as if it were any other text to fit the overflow ellipsis

Differences:
- The ellipsis is rendered as three period characters in IE6, IE7 and Opera 9.5, and as an ellipsis entity in Safari 3
- The behavior of an overflow element with rtl direction is inconsistent:
  * Nonsensical in Opera (check out the screenshot)
  * Cut off at the left and rendered with a left-hand ellipsis in IE
  * Cut off at the left but rendered without an ellipsis in Safari
- The behavior of a ltr element with a rtl segment causing overflow is inconsistent:
  * Again nonsensical in Opera
  * Cut off at the right of the overflowing element in Safari, but rendered without ellipsis
  * Cut off at the right of the overflowing element in IE, and rendered with ellipsis

Generally the IE behavior seems sane to me, even for rtl, except that the ellipsis should be rendered using the correct entity, not as three dots.

If people agree, I'll try to spec that behavior (IE + ellipsis entity).

	fantasai
	Comment 29 • 16 years ago

Sounds about right. The RTL in LTR (or LTR in RTL) case is tricky. You can either truncate the text visually and then insert the ellipsis, or truncate the text logically and then insert the ellipsis. I am not sure which is better. smontagu?

Wrt inheritance etc: what happens if the outer div has text-overflow and *it* is the one with a constrained width? (Need to check both auto width and large fixed width on the child for this one.)

The other thing to check is if the ellipsis is triggered when overflow != hidden.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 30 • 16 years ago

Joeri: thanks a lot! That's a big help. The IE7 behaviour does seem pretty sensible. It would be good if you can extend your testcase for fantasai's questions.

Here are the relevant parts of Joeri's testcase:
jar:https://bugzilla.mozilla.org/attachment.cgi?id=325795!/text-overflow%20tests/test1.html
jar:https://bugzilla.mozilla.org/attachment.cgi?id=325795!/text-overflow%20tests/ie7.png
jar:https://bugzilla.mozilla.org/attachment.cgi?id=325795!/text-overflow%20tests/safari3.png
jar:https://bugzilla.mozilla.org/attachment.cgi?id=325795!/text-overflow%20tests/opera95.png

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 31 • 16 years ago

> You can either truncate the text visually and then insert the ellipsis

If you mean what IE7 does, I think that is far easier to implement. I think text-overflow can be implemented entirely at paint time, without affecting layout at all. But truncating the text logically would have to affect the layout.

Oh, one more thing that needs to be tested:

What happens if an overflowing line consists of text followed by image, where the left edge of the image is inside the area where the ellipsis would be? Do you get an ellipsis or not? It seems like either is possible/reasonable.

Thanks!

	Zhang Weiwu
	Comment 32 • 16 years ago

Hi. 2 cents from my understanding of Chinese/Japanese/Korean (I am native Chinese):

If eclipses was done logically, please note ideographs are not separated with space. They are not separated at all. So if the browser replace the overflowing space-separated "word" with eclipses, where "word" is defined as "space separated entity", it might have replaced the whole paragraph with eclipses, because there are usually only 0 space character in a Chinese paragraph.

Also note the eclipses in Chinese does not look like 3 dots or 4 dots, it is 6 dots. 10 years ago people would be surprised to see 3/4 dots used for eclipses but now it seems poor localized implemented systems are everywhere that nowadays Chinese people just tolerate 3/4 dot ellipses with no complain, although schools still teach 6-dot way. (It all starts from Windows which shows menu item that opens a dialog with padding 3 dots, now people think: "eclipses are 6 dots, but on computer it is 3 dots".) 

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 33 • 16 years ago

(In reply to comment #32)
> If eclipses was done logically, please note ideographs are not separated with
> space. They are not separated at all. So if the browser replace the overflowing
> space-separated "word" with eclipses, where "word" is defined as "space
> separated entity", it might have replaced the whole paragraph with eclipses,
> because there are usually only 0 space character in a Chinese paragraph.

text-overflow doesn't care about word boundaries so this issue will not arise.

	Tony Mechelynck [:tonymec]
	Comment 34 • 16 years ago

(In reply to comment #33)
> (In reply to comment #32)
[...]
> text-overflow doesn't care about word boundaries so this issue will not arise.
> 

The 3-dots vs. 6-dots issue will arise, unless the overflow is localized according to (I suppose) the last character before the cut. (English text on a Chinese page, or vice-versa, should get the ellipsis corresponding to the text, not to the page, and I don't think we can rely on a lang= attribute unless, maybe, it is present at the very level where the overflow happens.)

	Zhang Weiwu
	Comment 35 • 16 years ago

A question: what happens if overflowing text hits a right floated element? e.g.

<div style="width: 8em; white-space: nowrap; border: 1px solid red; overflow: hidden; text-overflow:ellipsis">
<div style="float: right; width: 4em;">MM M</div>
m mm mm mm mm mm
</div>

Would be displayed as:
-----------------
m ... MM M
-----------------
Or as
-----------------
      MM M
m mm mm ...
-----------------

I checked currently Opera does it in the second way. I don't know IE since I don't have it.

I as a web developer think the 1st way is better because it provides more possibility and in many cases provide better layout (think about a news teaser that has a picture of the story floating on the right). How do you think?

	Zhang Weiwu
	Comment 36 • 16 years ago

> think about a news teaser that has a picture of the story floating on the right

Just in case I wasn't clear about this. Think of this:

<p class="news_teaser">
<img class="news_picture"/>
This is the teaser text of the news teaser. The web developer does not know how long this teaser text is, but he is clear each teaser should only have 5 rows and everything after that should be eclipsed. He also want: in case there are no news_picture together with the teaser, the teaser text should use all space, otherwise it should surround the news picture which floats to the right ...
</p>

	Zhang Weiwu
	Comment 37 • 16 years ago

(In reply to comment #33)
> (In reply to comment #32)
[...]
> text-overflow doesn't care about word boundaries so this issue will not arise.

So it is clear we are not going to implement "text-overflow: ellipsis-word;"
or not?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 38 • 16 years ago

(In reply to comment #34)
> The 3-dots vs. 6-dots issue will arise, unless the overflow is localized
> according to (I suppose) the last character before the cut. (English text on a
> Chinese page, or vice-versa, should get the ellipsis corresponding to the text,
> not to the page, and I don't think we can rely on a lang= attribute unless,
> maybe, it is present at the very level where the overflow happens.)

Is there a Unicode character that displays 6-dots? The ELLIPSIS character displays only 3-dots in all the Chinese fonts on my Mac.

(In reply to comment #35)
For your example, the second way is the only way that's consistent with CSS, as far as I can tell.

If you put the float after the first character of the line, you might get the line to overlap the float. Firefox 3 would move the float to the next line but Firefox 3.1 (the nightly builds) behaves differently. However, text-overflow as specced so far is pretty clear that you only get an ellipsis when you overflow the edge of a container element that has text-overflow on it, so we wouldn't add an ellipsis just because it's overlapping a float.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 39 • 16 years ago

(In reply to comment #37)
> So it is clear we are not going to implement "text-overflow: ellipsis-word;"
> or not?

That's fairly doable and we already have pretty good knowledge of word boundaries (e.g. for caret movement).

	Zhang Weiwu
	Comment 40 • 16 years ago

In Chinese we use two 3-dot-eclipsis. U+2026

	Zhang Weiwu
	Comment 41 • 16 years ago

(In reply to comment #34)
> The 3-dots vs. 6-dots issue will arise, unless the overflow is localized
> according to (I suppose) the last character before the cut. 

Difficult.

Problem 1:===========

1) in Chinese ellipsis is 6 dots;
2) in Japanese ellipsis is 3 dots OR 6 dots;
3) most (>80%) Chinese ideographs are also Japanese ideographs;

http://en.wikipedia.org/wiki/Ellipsis

So you don't know if it is Chinese by just looking at the character.

Solution:

Since in Chinese 6 dots is the standard way of ellipsis and in Japanese both 3-dot and 6-dot are acceptable, then let's use 6 dots when it comes to a Chinese/Japanese ideograph. OK for Chinese and acceptable for Japanese.

Problem 2:===========

1) In Chinese dots in ellipsis can be on the baseline or vertically centered. vertically centered is the standard way, baseline dots are acceptable;
2) In Japanese dots in ellipsis must be vertically centered;

Solution: We vertically center the dots when it comes to a Japanese/Chinese ideograph, acceptable for both.

	Tony Mechelynck [:tonymec]
	Comment 42 • 16 years ago

In reply to comment #40 and comment #41
Problem: U+2026 (used also for Latin, Cyrillic, etc.) is on the baseline -- acceptable for Chinese but not for Japanese.
Solution: Display the CJK ellipsis as the equivalent of <sup>&#x2026;&#x2026;</sup> or similar.

	Zhang Weiwu
	Comment 43 • 16 years ago

I think it is font related.

A Chinese font places the dots of U+2026 on vertical center.

Important is to tell Mozilla to use a Chinese font for the Chinese ellipsis

	Richard Birkby
	Comment 44 • 16 years ago

(In reply to comment #38)
> 
> Is there a Unicode character that displays 6-dots? The ELLIPSIS character
> displays only 3-dots in all the Chinese fonts on my Mac.
> 

Wikipedia says:

In Chinese, the ellipsis is six dots (in two groups of three dots, occupying the same horizontal space as two characters).
...
In Chinese and sometimes in Japanese, ellipsis characters are done by entering two consecutive horizontal ellipsis (U+2026).

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 45 • 16 years ago

A few more things I thought of that need to be tested and specified:

-- what happens to position:relative and position:absolute content? if you position text so that it overflows the text-overflow element to the right, does an ellipsis occur there? What if you position it to the left of the left edge of the element, does an ellipsis occur there?

-- what if you have a line of text that overflows to the right, causing an ellipsis, but beyond that text on the same line you have more text in a span which is relatively positioned with negative 'left' so it's actually visible? Do you get *another* ellipsis drawn? Or is the stuff after the ellipsized text not rendered at all?

-- if you click on an ellipsis, does the event go to the element with text-overflow or the text "underneath" the ellipsis?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 46 • 16 years ago

Also, what text descendants are affected by text-overflow? Do the effects propagate to descendants inside overflow:scroll descendants? Positioned descendants? Float descendants? Descendants in tables? inline-block descendants?

	AndrewM
	Comment 47 • 16 years ago

Sorry this is a bit off-topic, but I was confused by this:

Robert O'Callahan (:roc) <roc@ocallahan.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #325795 [details]|application/zip             |application/java-archive
          mime type|                            |

Isn't it actually a ZIP file? When I download the attachment, it ends with .zip.

Also, when I click the links in comment 30, I get a Bugzilla message saying "Invalid Attachment ID" and e.g. "The attachment id 325795!/text-overflow tests/test1.html is invalid."

	Unknown W. Brackets
	Comment 48 • 16 years ago

(In reply to comment #47)
> Also, when I click the links in comment 30, I get a Bugzilla message saying
> "Invalid Attachment ID" and e.g. "The attachment id 325795!/text-overflow
> tests/test1.html is invalid."

Your questions are related.  Copy the full line (including the jar: part) and you'll see the specific file from the archive in Firefox (won't work in other browsers.)  This is for convenience.

-[Unknown]

	Simon Montagu :smontagu
	Comment 49 • 16 years ago

(In reply to comment #29)
> Sounds about right. The RTL in LTR (or LTR in RTL) case is tricky. You can
> either truncate the text visually and then insert the ellipsis, or truncate the
> text logically and then insert the ellipsis. I am not sure which is better.
> smontagu?

I never considered the possibility of truncating visually. It seems to me obvious that the text remaining after truncation must always be logically contiguous and therefore readable as the beginning of the original text.

	Simon Montagu :smontagu
	Comment 50 • 16 years ago

(In reply to comment #28)
> I had to make some guesses with the bidi tests, because it's not really
> something I have any experience with, so if I messed that part up, please tell
> me. Also, if someone could point me to some educational materials that could
> get me up to speed on the topic, please do.

Richard Ishida's "What you need to know about the bidi algorithm and inline markup" is an excellent introduction: http://www.w3.org/International/articles/inline-bidi-markup/

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 51 • 16 years ago

(In reply to comment #49)
> I never considered the possibility of truncating visually. It seems to me
> obvious that the text remaining after truncation must always be logically
> contiguous and therefore readable as the beginning of the original text.

But we don't do that for overflowing text that's just clipped, so doing it for text-overflow would make text-overflow behave more differently from clipping than I think was intended. Not to mention that it would make text-overflow much much harder to implement.

	AndrewM
	Comment 52 • 16 years ago

(In reply to comment #48)
> (In reply to comment #47)
> > Also, when I click the links in comment 30, I get a Bugzilla message saying
> > "Invalid Attachment ID" and e.g. "The attachment id 325795!/text-overflow
> > tests/test1.html is invalid."
> 
> Your questions are related.  Copy the full line (including the jar: part) and
> you'll see the specific file from the archive in Firefox (won't work in other
> browsers.)  This is for convenience.
> 
> -[Unknown]

Ah, thanks for the tip; it works fine when I copy the jar: part as well :)

	neil@parkwaycc.co.uk
	Comment 53 • 16 years ago

My understanding is that part of roc's interest in this bug is to unify XUL and HTML text frames. Now XUL text frames currently use the intl.ellipses localised preference to know how to ellipse text correctly. (I have it set to ... because my preferred UI font's bold ellipsis looks like an underscore.) Would this mean that the HTML ellipsing code would have to use the same preference?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 54 • 16 years ago

For Japanese, at least, we need to support two kinds of ellipsization, one for "content" text and one for UI text. We can easily do that with a -moz-ui-ellipsis value which XUL would use.

	Scott Trenda
	Comment 55 • 16 years ago

Two quick things:
1. Does text-overflow:ellipsis automatically happen when specified on tables with table-layout:fixed? (but without overflow:hidden and white-space:nowrap specified?) I'm not sure how IE/Opera/Safari handle this.
2. What should happen when the cut-off text is selected? I know IE hides the ellipsis and shows the cut-off text under the ellipsis when the text is selected.

Thanks for the activity, everyone! I'm really looking forward to seeing this implemented!

	Unknown W. Brackets
	Comment 56 • 16 years ago

(In reply to comment #55)
> 1. Does text-overflow:ellipsis automatically happen when specified on tables
> with table-layout:fixed? (but without overflow:hidden and white-space:nowrap
> specified?) I'm not sure how IE/Opera/Safari handle this.

That would be really strange and inconsistent with other css properties, wouldn't it?  Might be nice if it inherited from table to td/th though.... but I think those are both spec decisions?

-[Unknown]

	Scott Trenda
	Comment 57 • 16 years ago

(In reply to comment #56)
> (In reply to comment #55)
> > 1. Does text-overflow:ellipsis automatically happen when specified on tables
> > with table-layout:fixed? (but without overflow:hidden and white-space:nowrap
> > specified?) I'm not sure how IE/Opera/Safari handle this.
> 
> That would be really strange and inconsistent with other css properties,
> wouldn't it?  Might be nice if it inherited from table to td/th though.... but
> I think those are both spec decisions?

As I said, I don't actually know how it works/acts in the other browsers, nor how overflow and whitespace are specified for table-layout:fixed in HTML or CSS. This is more of an empirical observation that text-overflow:ellipsis requires overflow:hidden, white-space:nowrap, and a set width to be specified in order to be "triggered", and all three of those seem to automatically happen for text in TD's in a table with table-layout:fixed. Just a curious thought, but if it does happen in the other browsers, we might as well add it to the list of test cases. :)

	Unknown W. Brackets
	Comment 58 • 16 years ago

(In reply to comment #57)
> all three of those seem to automatically happen
> for text in TD's in a table with table-layout:fixed.

Ah, sorry about that.  I had read what you said as "act as if text-overflow: ellipsis were specified with table-layout: fixed applied."

Anyway, from my tests:
IE6 requires all three properties to do the ellipsis (even overflow: hidden), otherwise it just clips to width.
IE7 behaves no differently.
Safari acts like IE except that it (like Firefox) does not clip a fixed table with no overflow: hidden.

I don't have anything newer than Opera 9.21 and can't upgrade now, but hope that helps nonetheless.

-[Unknown]

	Joeri Sebrechts Reporter
	Comment 59 • 16 years ago

OK, I've done more tests, you can find screenshots in the attachment.

Some more conclusions:
- ellipsis only happens for runs of text. As soon as text-overflow is defined on an element, but it's blocks that cause the overflow to happen, no ellipsis is rendered.
- With the exception of opera, inline images don't cause ellipsis if they're the one triggering the ellipsis, even if they would be fully replaced by the ellipsis when rendered. Opera removes the text to fit the ellipsis, but not the image, so the ellipsis gets rendered on top of the image, which is clearly broken behavior.
- overflow auto causes ellipsis, but it is broken in all but IE, because scrolling the overflow element does not reveal more text (the ellipsis scrolls along, revealing empty space where text should have been).
- Chinese text gets an ellipsis with the same rules as english text (three dots, whole symbols are removed to make room for the ellipsis).
- There's no consistent behavior for a right floated element inside an overflowing element. I don't know the exact rules CSS specifies in this case (regardless of ellipsis). Safari does the intuitive thing by pushing back the text and rendering ellipsis right before the floated element. Opera and IE push the text down. Firefox renders the float on top of the text.
- Position relative/absolute of the overflowing content inside the overflowing element does odd things in IE, but generally I would say it doesn't cause ellipsis (because it turns the content that triggers overflow into blocks, and blocks don't trigger ellipsis).
- Tables don't trigger ellipsis if they have fixed layout, nor does the property inherit to the cells. I think this is quite acceptable behaviorally. I am in doubt about whether a fixed layout table should automatically set overflow to hidden for the cells, or leave it as visible. The correct behavior is unclear to me (someone with deep CSS knowledge who would like to comment?).
- When the overflow is caused by a child element, and you click the ellipsis, does the event get sent to the element that caused overflow, or the element that has the text-overflow style set? IE and Opera send it to the child, Safari to the parent.

Again, IE seems mostly consistent. There are a few things which are not correct, but it's a good baseline for the feature. I'll work on getting that spec, but I can already tell it's not going to be easy. I'm going to make a baseline spec just for text-overflow: ellipsis, but if someone wants to flesh it out for ellipsis-word later on, they're ofcourse welcome to.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 61 • 16 years ago

Thanks for all this analysis!!!

(In reply to comment #59)
> - Position relative/absolute of the overflowing content inside the overflowing
> element does odd things in IE, but generally I would say it doesn't cause
> ellipsis (because it turns the content that triggers overflow into blocks, and
> blocks don't trigger ellipsis).

position:relative doesn't change anything into a block. position:absolute kind of does, but the text inside it remains inline...

	Joeri Sebrechts Reporter
	Comment 62 • 16 years ago

I just want to get this implemented :)

I've posted an opening volley to www-style, in the hopes that we can get some kind of description for this feature worked out, but I don't know if it's really the right path, because the W3's task is more one of harmonization and documentation rather than one of prior specification.

http://lists.w3.org/Archives/Public/www-style/2008Aug/0006.html

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 63 • 16 years ago

You've made a lot of progress, but we still need a complete answer to comment #46 and the second item in comment #45 ... we really do need to specify what happens in positioned content. Note that normally, setting "position:relative" but leaving "top" and "left" as "auto" (or "0") will not change any rendering, so it would be nice if text-overflow preserved that invariant.

	fantasai
	Comment 64 • 16 years ago

"the W3's task is more one of harmonization and documentation rather than one of prior specification."

That's not true. W3C does both. (Ideally it's supposed to just do prior specification for everything, but that's not how reality works.)

I agree with roc that relative positioning should not change any rendering. I also don't think changing a relatively positioned element's offsets should change where the ellipsis shows up: I'm thinking of animated effects where a box e.g. slides into place. (In other words, I think the May 2003 spec is wrong in this aspect.

I'll add a skeleton for text-outline to the Editor's Draft, maybe you can start by proposing text to fill it in and we'll go from there.

	fantasai
	Comment 65 • 16 years ago

Probably also need to define what happens when the 'clip' property takes effect.

	Joeri Sebrechts Reporter
	Comment 66 • 16 years ago

I'm really getting the knack of this "testing" thing ;)

@Roc

In response to #45:
- position:absolute never renders ellipsis because it turns the element that triggers overflow into a block box (more or less, as you say)
- position:relative does in fact render ellipsis, unlike the wrong conclusion I took from my previous test, but it does it differently in every browser:
  * IE: ellipsis gets rendered, as far as I can tell, inside the relatively positioned element at the position that it would be rendered if the content of the relatively positioned element was placed directly inside the overflowing element. Yes, that is pretty weird, but do check out the screenshot.
  * Safari: space gets cleared in the relatively positioned element to make room for the ellipsis, as if the element wasn't offset, but then the ellipsis gets rendered at the end of the overflowing element anyway.
  * Opera: the ellipsis is simply offset with the rest of the positioned element.
- Positioning the element beyond the left edge does not cause an ellipsis at the left.
- Negatively positioned content "moving in" from beyond the overflow boundary does not cause a second ellipsis. In fact, it isn't even visible in opera and safari (just the border around the positioned element is), which I assume is due to the clearing of text that happens when ellipsis is drawn. In IE this causes the ellipsis to not be drawn at all.
- Relatively positioned content that wouldn't overflow if it wasn't positioned doesn't get an ellipsis.

And in response to #46:
- blocks across the overflow boundary prevent ellipsis, except in the case of IE, which renders ellipsis for divs inside overflow:auto elements for example (I don't quite get the pattern of when IE renders ellipsis). So, descendants that are block boxes don't cause ellipsis, while descendants that are inline boxes do cause ellipsis.

@Fantasai

I didn't mean to say that W3C does no prior specification of behavior, just that my view as an outsider is that the majority of the work they do is one of documenting what the standard is after it is created or modified de-facto. As a personal aside this is the role I prefer them in anyway.

The case of relative positioning is a tricky one:
- Either you consider the ellipsis part of the positioned element and you move it along. This is consistent and simple, but non-intuitive.
- Or you consider the ellipsis a hint of overflowing content, and render it at or near the overflow boundary, visually removing characters as needed. In this case changing positioning wouldn't affect the position the ellipsis is rendered much (except in that it must be rendered right after a character or block, so it might move a few pixels depending on the changes to the content). I prefer this approach because it is consistent and intuitive.
- Or you simply say that relatively positioned content doesn't trigger ellipsis. Simplest of all, but again non-intuitive.

Regarding clip, some quick testing showed that ellipsis is obscured along with the rest of the clipped content. This behavior makes sense as the border is obscured also, instead of moved to fit the clipped content.

I'd be more than willing to try to fill in the blanks in the spec, if you'll forgive me if my first attempts come up short :) Is this editor's draft you speak of the document at this location: http://dev.w3.org/csswg/css3-text/ ?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 67 • 16 years ago

Thanks for plugging away at this!!

(In reply to comment #66)
> In response to #45:
> - position:absolute never renders ellipsis because it turns the element that
> triggers overflow into a block box (more or less, as you say)

I don't know if that's the right reasoning but the behaviour sounds acceptable.

> - position:relative does in fact render ellipsis, unlike the wrong conclusion
> I took from my previous test, but it does it differently in every browser:
>   * IE: ellipsis gets rendered, as far as I can tell, inside the relatively
> positioned element at the position that it would be rendered if the content of
> the relatively positioned element was placed directly inside the overflowing
> element. Yes, that is pretty weird, but do check out the screenshot.

Oops.

>   * Safari: space gets cleared in the relatively positioned element to make
> room for the ellipsis, as if the element wasn't offset, but then the ellipsis
> gets rendered at the end of the overflowing element anyway.

That doesn't seem right.

>   * Opera: the ellipsis is simply offset with the rest of the positioned
> element.

Of these options, I prefer this behaviour.

> - Positioning the element beyond the left edge does not cause an ellipsis at
> the left.

Sounds OK.

> - Negatively positioned content "moving in" from beyond the overflow boundary
> does not cause a second ellipsis. In fact, it isn't even visible in opera and
> safari (just the border around the positioned element is), which I assume is
> due to the clearing of text that happens when ellipsis is drawn. In IE this
> causes the ellipsis to not be drawn at all.

The Opera and Safari behaviour sounds best. Hmm, so in general, ellipsization clears the text following it in the line, but non-text stuff like borders is still drawn? What about images, inline-blocks, and other stuff you can place in a line, are they all still drawn if relative positioning brings them back into view?

> And in response to #46:
> - blocks across the overflow boundary prevent ellipsis, except in the case of
> IE, which renders ellipsis for divs inside overflow:auto elements for example
> (I don't quite get the pattern of when IE renders ellipsis). So, descendants
> that are block boxes don't cause ellipsis, while descendants that are inline
> boxes do cause ellipsis.

The question is, do inline descendants which happen to be in a float descendant get ellipsized? What about inline descendants in a table, block or inline-block descendant? (You've already answered for inline descendants in an absolutely-positioned descendant --- "no").

> The case of relative positioning is a tricky one:
> - Either you consider the ellipsis part of the positioned element and you move
> it along. This is consistent and simple, but non-intuitive.
> - Or you consider the ellipsis a hint of overflowing content, and render it at
> or near the overflow boundary, visually removing characters as needed. In this
> case changing positioning wouldn't affect the position the ellipsis is rendered
> much (except in that it must be rendered right after a character or block, so
> it might move a few pixels depending on the changes to the content). I prefer
> this approach because it is consistent and intuitive.
> - Or you simply say that relatively positioned content doesn't trigger
> ellipsis. Simplest of all, but again non-intuitive.

I don't think your last option is acceptable, because it breaks the invariant that just setting "position:relative" on an element doesn't change rendering. I'm not sure which of the first two options I prefer, but I lean towards preferring option #2.

Thanks again!

	fantasai
	Comment 68 • 16 years ago

Yep. I just checked in the skeleton of a text-overflow definition: just the syntax, no prose. <http://dev.w3.org/csswg/css3-text/#text-overflow> Post your proposed text to www-style.

	Joeri Sebrechts Reporter
	Comment 69 • 16 years ago

I just tested the situation with an element with text-overflow containing a block descendant (float, table, inline-block), in turn containing an inline descendant (span). The block causes the inline descendants not to get ellipsis. There must be an ancestral path of only inline descendants to the overflowing element in order for ellipsis to be applied.

The question is ofcourse: is this the behavior we want? I don't doubt that it's easier to implement that way, but is it what authors want? I can imagine arguments in favor of applying ellipsis to block descendants and their children, as long as there is text at the overflow boundary.

But perhaps this is a case of "the enemy of the good is the perfect", and the existing cross-browser behavior is "good enough".

	Joeri Sebrechts Reporter
	Comment 70 • 16 years ago

I've posted a suggested spec wording to www-style. Anyone interested in getting this feature specified and implemented should discuss it there.

http://lists.w3.org/Archives/Public/www-style/2008Aug/0271.html

	k4mik4dze
	Comment 71 • 15 years ago

wow its over 3 years for this bug, all other major browsers support this normally already. 

before recent FF release (3.0.9) we could use XUL approach, but referencing pages to "outside" makes it invalid because of security patch:

http://www.mozilla.org/security/announce/2009/mfsa2009-18.html

(vote for fix)

	WulfTheSaxon [:Wulf]
	Comment 72 • 15 years ago

(In reply to comment #71)

You're supposed to vote via the "Vote" link, not by commenting. By doing it the way you did, you've just sent an email to somewhere around 150 people...

Also, the bug is already marked [parity-safari], [parity-IE] and [parity-opera].

	Matias Larsson
	Comment 73 • 15 years ago

The following CSS still works in Fx 3.09 Mac for me.

div#subMenu h2 {
    -moz-binding:url(ellipsis.xml#ellipsis);
    overflow:hidden;
    white-space:nowrap;
    width:150px;
}

	Martin Andersen
	Comment 74 • 15 years ago

Has the implementation of this begun?

	Simon Montagu :smontagu
	Comment 75 • 15 years ago

Yes, I am working on it.

	Martin Andersen
	Comment 76 • 15 years ago

How close ru (maybe in years) :) Do we have to wait for Fx 4.00 before we see it?

	Simon Montagu :smontagu
	Comment 78 • 15 years ago

Apparently no other UA supports text-overflow: <string>.

I also used attachment 387396 [details] to test behaviour when selecting text by dragging the mouse as far as the right-hand border of the <div> and copying.

IE8 (Windows XP): the text appears selected including the first two dots of the ellipsis. The text that appears before the ellipsis is copied.

Opera 9.64 (Windows XP): while dragging, the text hidden by the ellipsis reappear and the text appears selected up to the border. The text copied is the same as what appears selected.

Safari 4.0 (OS X 10.4.11): the text appears selected including the whole ellipsis. The text copied includes the text hidden by the ellipsis.

Opera's behaviour seems the most logical to me, and is also what is described at http://msdn.microsoft.com/en-us/library/ms531174%28VS.85%29.aspx:

"The hidden text can be selected by selecting the ellipses. When selected, the ellipses will disappear and be replaced by the text to the extent of the layout area."

	Joeri Sebrechts Reporter
	Comment 79 • 15 years ago

Opera's behavior is consistent with ellipsis being a visual hint only, that does not affect structure or behavior.

	Ernst de Haan
	Comment 80 • 15 years ago

(In reply to comment #77)
Would it be useful to add a soft hyphen (SHY character) in the test case?

While trying to figure out a solution for the lacking ellipsis-support for Gecko-based browsers, I used an XBL binding to produce a work-around, but it has issues with both text selection and with soft hyphens, as described at:
http://ernstdehaan.blogspot.com/2008/10/ellipsis-in-all-modern-browsers.html

I do realize that the solution being implemented may be completely unrelated to the issues I ran into. If there may be a relation, though, then adding a single soft hyphen character in each list-item may be useful.

	Mike Capp
	Comment 81 • 15 years ago

Is the implementation-in-progress going to require overflow:hidden, as IE's does and as documented at https://developer.mozilla.org/En/CSS/Text-overflow ?

If so, should bug 491549 be a dependency? The combination of inline-block and overflow-hidden triggers a nasty vertical misalignment which makes it almost unusable in a baseline-aligned inline context.

	fantasai
	Comment 82 • 15 years ago

Dave Hyatt wanted to remove the dependency on overflow:hidden, so if the rest of the WG agrees we can do that. I'm going to ask about putting text-overflow on the CSSWG agenda for the TPAC, as there's a lot of issues here.

	Makoto Kato [:m_kato]
	Comment 83 • 15 years ago

too early version.  I need to add some property to cache due to performance and fix selection bug.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 84 • 15 years ago

That's a good try, but unfortunately you can't do this just in the text frame. For example you need to be able to hide overflowing non-text content, and in an overflow:scroll context you need to be able to repaint the text as you scroll because the ellipsis is moving.

See https://wiki.mozilla.org/Gecko:TextOverflow

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 85 • 15 years ago

A better example of where doing this just in the text frame won't work is content like

hello<b>kitty</b>

where the 'k' overflows the boundary. We need to add ellipsis after the "hello", so you can't just implement it in the textframe that overflows (which is "kitty" in this case).

Another issue is that the ellipsis needs to use the text-style of the block that set 'text-overflow', not the style of the text itself, according to what other browsers have implemented.

	fantasai
	Comment 86 • 15 years ago

See also http://lists.w3.org/Archives/Public/www-style/2009Nov/0219.html, especially the replies.

	Robert E. McIntosh
	Comment 87 • 15 years ago

I hate to say this because I have never had a problem with Firefox being the one falling behind. But every other major browser has support for this. what doesn't Firefox. It just doesn't make any since. Its usually the only browser that I generally don't have to write little hacks for. I mean even IE 6.0 supports it.

	Zhang Weiwu
	Comment 88 • 15 years ago

This is not the only one issue that Firefox has and others don't. As a user I could just name a few without evening googling. For example, http authentication not working for multi-byte user name (frequent case in database driven web forums), jpeg2000, and so like. My favorites are two CSS limitations: inter-ideograph text align justification which is necessary to correctly display ideograph/latin mixed text line, and writing-mode which is necessary to render vertical Chinese text (widely used in Taiwan and Japan) correctly. Both are there since IE6, and both break Chinese typography so much that use of PDF for printing being not replaceable.

As a stupid luser when I found something is not working on Firefox, and question that, usually I was given a long explanation why it should not work and a list of technical reference plus a kind warning message that posting anything without fully understanding the former would not be constructive nor helping, as you should be in any opensource project. Meanwhile all other browsers offer it just fine without explanation nor discussion. Some say dictatorship occassionally are proficient in software development. I say they have to offer features without such discussion because many are not opensource thus there is no open place users can discuss ;( There is even a third funny theory that since opensource is celebration instead of competition, it effectively removed the need to compete for features nor the need to advance ;)

This is not a complaint, just facts. The next commenter, he would pointing out all I said above doesn't belong here, it belongs to newsgroups and mailing lists where developers don't listen as much as here. The saddest part is, he /is/ right.

	Kohei Yoshino
	Comment 89 • 15 years ago

This it not a spectacular feature but one of a must-have item for modern Web applications. Why not raise the priority and get fixed in Firefox 3.7? I don't want to use <xul:description crop="end" value="Foo" /> hack anymore.

	d
	Comment 91 • 14 years ago

Just bumping to make sure that the WIP patch isn't forgotten. How are you doing, Makoto?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 92 • 14 years ago

This patch is not the right approachh, for the reasons mentioned in comment #85.

Mats is working on a real fix.

	Marek Stępień [:marcoos, inactive]
	Comment 93 • 14 years ago

As remote XUL is going away (bug 546857), the <xul:description> hack probably won't work anymore.

	Matt Cosentino
	Comment 94 • 14 years ago

Yeah, I can confirm that the xul hack doesn't work anymore.  Is anyone working on this?

	Jesse Ruderman
	Comment 95 • 14 years ago

Renominating in light of comment 93.

	Kohei Yoshino
	Comment 96 • 14 years ago

This is something only Firefox doesn't support among modern browsers. (See the whiteboard.) The priority should be higher...

	muzzle
	Comment 97 • 14 years ago

"Duke Nukem Forever" gets a release date, but this bug is still open after five years?  Ouch!

	Thomas Bachem
	Comment 98 • 14 years ago

I agree, this is one of the biggest pains I got in daily web development...

	fantasai
	Comment 99 • 14 years ago

Guys, if you're not actively helping to fix this bug, *don't comment*.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

	fantasai
	Comment 100 • 14 years ago

Adding Tantek, since we need a spec here, and CSS3 UI seems like a more appropriate place for overflow control than CSS3 Text, despite the property name.

	Michael Tibben
	Comment 101 • 14 years ago

This issue should be considered a regression and be prioritised accordingly. 

The XUL workaround was very widely used, and now with the XUL avenue blocked, this feature has been lost.

Could someone at mozilla please bring this regression to the powers-that-be for consideration as a Firefox 4 blocker. I can really see this causing issues for many thousands of websites that would have implemented the XUL workaround.

	Paul Rouget [:paul]
	Comment 102 • 14 years ago

This bug is blocking the "Firefox 4 Web Product Tracking Bug" (bug 569993), but not blocking2.0.

Mats, roc, any update?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 103 • 14 years ago

It is way too late in the game to be adding new Web features to FF4, especially features that aren't nearly done yet.

	Kohei Yoshino
	Comment 104 • 14 years ago

Comment 92 reads:
> Mats is working on a real fix.

What's going on??

	Kyle Adams
	Comment 105 • 14 years ago

With FF4 wrapping up, is there a chance we might see a fix land in a post-FF4 early build?

	Tantek Çelik
	Comment 106 • 14 years ago

I've written a draft specification of text-overflow:ellipsis based on previous work, above comments, current implementation (claims) and incorporated it into a CSS3-UI editor's draft. I believe I've provided sufficient details for at least a rough implementation (including answers to many/most of RoC's spec questions above). Please feel free to send me feedback directly or leave it in comments here.

http://dev.w3.org/csswg/css3-ui/#text-overflow

I believe this specifies what is already interoperably implemented among WebKit, Opera, IE and thus will be taking it directly (back) to last call along with the rest of CSS3-UI.

	fantasai
	Comment 107 • 14 years ago

Thank you for moving the definition from css3-text to css3-ui. The definition there is, however, very vague (often uses examples instead of specific, normative requirements) and does not address many of the concerns we have (such as behavior in the presence of bidi). What is your intention to address these concerns? Do you want to address these issues in the current spec? Or leave the definition vague and underspecified for CSS3 and make it more precise in CSS4?

	steele
	Comment 108 • 14 years ago

“The ellipsis should be styled consistent with the text being ellipsed” doesn't specify the style when the ellipsed text has several styles, e.g. when “textABC” is ellipsed to “text…” and were it not for the insertion of the ellipsis A would be completely visible, B would be partially clipped, and C would not be visible, is the ellipsis given the style of A, B, C, or their common attributes?

	Tantek Çelik
	Comment 109 • 14 years ago

@fantasai - I greatly expanded the definition in css3-ui as compared to css3-text, please take another look.

> The definition there is, however, very vague (often uses examples instead of specific, normative requirements) and does not address many of the concerns we have (such as behavior in the presence of bidi).

Actually it does address exactly those concerns, and does so consistent with working group resolutions.

Please provide either test cases that illustrate what specific cases you think are vague and/or restate your concerns in the form of specific questions (e.g. "What happens when ... ").

> Do you want to address these issues in the current spec? Or leave the
definition vague and underspecified for CSS3 and make it more precise in CSS4?

In short, any behavior detail that is already interoperably implemented I'm willing to include in CSS3-UI. Anything that isn't gets punted to CSS4-UI.


@steele - that's a good question. To make sure I understand precisely what case you mean, could you provide a test case with HTML+CSS that exemplifies your question?

	j.j.
	Comment 110 • 14 years ago

Ellipsis is always black in current implementations.

	fantasai
	Comment 111 • 14 years ago

I suggest we move discussion of the spec details to www-style@w3.org where they belong, since this bug is about implementing it, not speccing it. Tantek, I will send my commentary there. steele has already pointed out one of the issues.

	charliemtk
	Comment 112 • 13 years ago

Any updates?  I find hard to believe that FF4 a modern browser doesn't support a basic text-ellipsis.  Literally all browsers (yes even IE) and FF is the only one not doing so...

It'd be appreciated.

	michael
	Comment 113 • 13 years ago

In my opinion this bug has to be solved immediatly since FF4 dropped XUL binding (https://bugzilla.mozilla.org/show_bug.cgi?id=546857).
Please implement it, perhaps like -moz-text-overflow for now if you have problems with missing specifications.

	michael
	Comment 114 • 13 years ago

At this moment I have to suggest using Google Chrome - or maybe IE - Browsers, because this single missing feature in FF4 can't be workarounded any more. 
Using a js-function to render it manually would be a poor solution in a (very big) table for example.

	Paolo Montrasio
	Comment 115 • 13 years ago

I agree that if ellipses is vital for a very important application of yours Firefox is not the browser you should be using.

What I expect from the dev team is an implementation of ellipses that is consistent with what the other browsers do should be good enough. They should create test cases for every scenario they think is not well specified, check what the other browsers do and code those behaviors into FF. W3C might even appreciate those test cases and use them to refine their spec.

What I don't understand is how a bug like this one can be still open (actually: new) after 5 years and 6 months. I bet this part of CSS is not in any ACID test.

	michael
	Comment 116 • 13 years ago

It is not vital for this application, but it looks ugly and all I can do is to add a known issue with "use another browser" or something like this as workaround description. 

I agree, a Bug opened for over 5 years is not acceptable! It seems that all the dev team can do is just discussing on standards and specifications.

An ugly solution would be still a solution!

	Gordon P. Hemsley [:GPHemsley]
	Comment 117 • 13 years ago

Once again, folks, this is not a place to complain about how a bug isn't getting fixed fast enough. No one responds well to comments such as those.

The age of the bug has nothing to do with it. Obviously, people in the know have concerns with specifications and how to implement them. An ugly solution is not, in fact, a solution at all, and would not be a good way to go.

If you have anything useful to offer (patches, testcases, etc.), then feel free to contribute them. Otherwise, please take your unconstructive comments elsewhere.

	michael
	Comment 118 • 13 years ago

(In reply to comment #117)
Sorry, I didn't want to bother someone, it's just hard for me to understand that this bug is not solved now since almost all other browsers out there have this feature, regardless if this was fully specified or not.

	Michael Tibben
	Comment 119 • 13 years ago

This may be useful to anyone who lands on the page and needs a solid workaround.

http://www.bramstein.com/projects/text-overflow/

	Steve Roussey (:sroussey)
	Comment 120 • 13 years ago

I should look at that. For Firebug, we had to create out own crop function, though it is based on a fixed character count, not the width of a container like the CSS property does.

	Brett Zamir
	Comment 121 • 13 years ago

Sorry to keep it off topic but I've added it to https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills . Non-jQuery version would be nice too. :)

	Brendan Eich [:brendan]
	Comment 122 • 13 years ago

New ETA? Spec in shape? Twittersphere wants to know.

/be

	Tantek Çelik
	Comment 123 • 13 years ago

Spec for text-overflow has been in sufficient shape to implement for some time:

http://dev.w3.org/csswg/css3-ui/#text-overflow

(status: that's an editor's draft update of what is currently a CR, so it'll go back for a quick last call and then back to CR)

Just looking at maybe adding a few figures for scrolling + text-overflow edgecases.

Please report any issues with the spec at www-style@w3.org (rather than this bug). Thanks. -t

	Mats Palmgren (inactive) Assignee
	Comment 124 • 13 years ago

The status is that I'm currently working on it.  The ETA is Firefox 6.

	jchapple
	Comment 125 • 13 years ago

(In reply to comment #124)
> The status is that I'm currently working on it.  The ETA is Firefox 6.

FF6? Is that a joke?

	Darren Kalck [:D-Kalck]
	Comment 126 • 13 years ago

Firefox 5 will come by the end of June, so I guess Firefox 6 will come by the end of the year.

	Zibi Braniecki [:zbraniecki][:gandalf]
	Comment 127 • 13 years ago

Firefox 6 will be released 6 weeks after Firefox 5 which will be released around June 21st.

	Aaron Kelley
	Comment 128 • 13 years ago

No...  The development cycle is 6 weeks but the release cycle is 18 weeks.  That puts Firefox 6 around late October.

	Daniel Holbert [:dholbert]
	Comment 129 • 13 years ago

Gandalf is correct - Firefox 6 is targeted for release 6 weeks after Firefox 5.

Aaron: there will be 18 weeks between when a branch splits off of mozilla central until that branch is released, but *not* 18 weeks *between releases*.  The plan is to start a new branch every 6 weeks and have a release ready every 6 weeks.

(Please let this be the last comment here about release cycles...? :))

	Patrick Walton (:pcwalton)
	Comment 130 • 13 years ago

In between Rust compiles I figured I'd take a stab at this. No guarantees I'll finish before Mats gets around to it, but I figured I'd post WIPs. Feedback would be much appreciated!

	Mats Palmgren (inactive) Assignee
	Comment 131 • 13 years ago

Thanks for trying to help, but I already have the style system part working.

	Mats Palmgren (inactive) Assignee
	Comment 137 • 13 years ago

text-overflow: clip | ellipsis | <string>

	Mats Palmgren (inactive) Assignee
	Comment 138 • 13 years ago

Move some text frame color stuff into nsLayoutUtils::GetTextColor()

	Mats Palmgren (inactive) Assignee
	Comment 139 • 13 years ago

Move nsDisplayText to nsDisplayList.h/cpp and add mLeftEdge/mRightEdge
members that suppress painting some characters during PaintText().

	Mats Palmgren (inactive) Assignee
	Comment 140 • 13 years ago

This implements both left and right markers.  Text is clipped at character
granularity at a marker. The marker itself is clipped at pixel granularity
with the other marker or at the block's edge.  The marker is placed at the
block's edge (as requested), using the block's color, font and background,
on the baseline of the line.  If the block's font doesn't have an ellipsis
character, three ASCII periods are used (I'm not doing any font checks for
text-overflow:<string>). Block-ish inlines, like images, inline-blocks and
replaced elements like <button> etc, are removed when they would be clipped
by a marker.  Relative positioned inlines are not counted as block-ish, they
are handled as any other inline - any text inside it is treated as text that
generate a marker when overflowing the containing block.  

Test builds:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla.com-5001c34b024f/

BUGS

1. Characters in (non-trivial) mixed-bidi cases are dropped in the
wrong order.  I do handle RTL text that's clipped at the right edge
by dropping characters from the end of that text run.  (Which seems
to be what Opera and Google Chrome does too.)

2. Text in a <textarea> appears pixel-clipped by the marker.  AFAICT,
I'm calculating the number of characters that fit correctly, but it
seems the background hasn't been repainted by the block?

3. text-shadow/decorations for the marker text isn't implemented yet.

4. When text inside an inline-block overflows its inline-block and the
overflowing text clips a marker, only the text is hidden; not the
whole inline-block as intended.

5. The separate path for painting text in a selection hasn't been
updated yet.  Markers would be displayed etc, but for clipped RTL text
the wrong part of the text would be painted in some cases.


QUESTIONS

Should a marker affect ScrollIntoView or a caret in any way?
ScrollIntoView: scroll a bit extra to come clear of a marker?
if a caret moves in under a marker should the marker be inhibited?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 141 • 13 years ago

Comment on attachment 529432 [details] [diff] [review]
part 4, layout changes

Review of attachment 529432 [details] [diff] [review]:

::: layout/generic/nsBlockFrame.cpp
@@ +101,5 @@
 static const int MIN_LINES_NEEDING_CURSOR = 20;
+static const PRUnichar kEllipsisChar[] = { 0x2026, 0x0 };
+static const nsDependentString kEllipsis(kEllipsisChar, 1);
+static const PRUnichar kASCIIPeriodsChar[] = { '.', '.', '.', 0x0 };
+static const nsDependentString kASCIIPeriods(kASCIIPeriodsChar, 3);

I don't think we should have static nsDependentStrings, since they require destructors to run.

@@ +6209,5 @@
+  // scroll port area.
+  nsDisplayTextOverflowMarker(nsDisplayListBuilder* aBuilder, nsIFrame* aFrame,
+                              const nsRect& aRect)
+    : nsDisplayItem(aBuilder, aFrame), mRect(aRect),
+      mString(kEllipsis), mAscent(nscoord_MAX) {

I don't really like this dummy item approach. I haven't figured out exactly why we need a dummy item yet, but if we do need one it should probably be its own display item type.

@@ +6261,5 @@
+  while (!cb->IsContainingBlock()) {
+    cb = cb->GetParent();
+  }
+  return cb;
+}

nsHTMLReflowState contains GetNearestContainingBlock, which is about the same as this. Please share them somehow.

@@ +6264,5 @@
+  return cb;
+}
+
+static bool
+IsClusteredItem(nsDisplayItem* aItem, nsIFrame* aBlock)

It's not really clear what IsClusteredItem means.

@@ +6650,5 @@
 
+  // Setup marker and clip rect for text-overflow processing.
+  nsAutoPtr<TextOverflowData> textOverflowData;
+  bool hasTextOverflow =
+    GetStyleTextReset()->mTextOverflow.mType != NS_STYLE_TEXT_OVERFLOW_CLIP &&

I think you might need to check the style of the primary frame for the block's content. E.g. if you have a table cell <td style="text-overflow:ellipsis">, the block will not have the text-overflow style set since it's not inherited. You worked around this for column-set frames with 'text-overflow:inherit' in ua.css, but I think it's probably better to work around it for all wrapped block frames here.

@@ +6653,5 @@
+  bool hasTextOverflow =
+    GetStyleTextReset()->mTextOverflow.mType != NS_STYLE_TEXT_OVERFLOW_CLIP &&
+    ::HasHiddenHorizontalOverflow(this) &&
+    !aBuilder->IsForEventDelivery();
+  if (hasTextOverflow) {

Please move as much of this setup code as you can to a separate method.

I also think TextOverflowData should probably move to a separate file if we can do that, to keep nsBlockFrame from growing much bigger.

::: layout/generic/nsFrame.cpp
@@ +1585,5 @@
+  nsIFrame* cb = aFrame;
+  do {
+    cb = cb->GetParent();
+  } while (!cb->IsContainingBlock());
+  return cb;

Please use the copy you're adding earlier in this patch!

@@ +1685,5 @@
+        }
+        // It's a text or inline frame in a 'text-overflow' containing block.
+        // Fall through to generate a display item (it'll be removed later
+        // but we need it to know if there is displayable text beyond an
+        // image, inline-block, etc that is on the block's clip edge).

Can you explain this situation further?

Are we dealing with a situation where, for example, there's an image on the line which extends beyond the clip edge, followed by text, and you want to drop the image but show a marker?

In that situation I think we probably shouldn't show a marker. I think we should only show a marker when an nsDisplayText intersects the clip edge. If we do it that way, you don't need this code.

::: layout/generic/nsTextFrameThebes.cpp
@@ +4987,5 @@
+  gfxPoint textBaselinePt(rtl ? gfxFloat(aPt.x + frameWidth) : framePt.x,
+                          GetSnappedBaselineY(ctx, aPt.y));
+  PRUint32 startOffset = provider.GetStart().GetSkippedOffset();
+  PRUint32 maxLength = ComputeTransformedLength(provider);
+  if (aLeftEdge > 0 || aRightEdge != 0) {

I'd like to move most of this code out to TextOverflowData to avoid complicating PaintText. Maybe PaintText could take an optional TextOverflowData*, and if that's not null then we call a method on the TextOverflowData to adjust our baseline point and character offset/length? Then nsDisplayText would have an mTextOverflowData pointer which is usually null but can be set when TextOverflowData processes the line.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 143 • 13 years ago

(In reply to comment #140)
> This implements both left and right markers.

Other browsers only display markers at one side of the block, determined by the block direction. Do you feel strongly that markers at both ends are desirable?

Allowing markers in both direction is OK by me, and would be nice for scrolling, but the "string" value would need to be extend to specify separate strings for "left" and "right" (e.g. you might want "<<<" and ">>>" or something like that), or else we would have to automatically mirror the string (see gfxUnicodeProperties::GetMirroredChar).

> The marker is placed at the block's edge (as requested),

As discussed in email, I think we should not align the marker with the block edge, but place it at the end of the text instead, as other browsers do.

> 1. Characters in (non-trivial) mixed-bidi cases are dropped in the
> wrong order.  I do handle RTL text that's clipped at the right edge
> by dropping characters from the end of that text run.  (Which seems
> to be what Opera and Google Chrome does too.)

Because all the other browsers have serious bugs that show they're not really moving elements around on the line, I think we should go with purely visual clipping: dropping text clusters beyond the clip edge/ellipsis edge.

> 2. Text in a <textarea> appears pixel-clipped by the marker.  AFAICT,
> I'm calculating the number of characters that fit correctly, but it
> seems the background hasn't been repainted by the block?

Not sure what you mean.

> 3. text-shadow/decorations for the marker text isn't implemented yet.

Other browsers don't apply text-decorations, which makes sense to me. Opera and Chrome do apply text-shadow, so we should too.

> 4. When text inside an inline-block overflows its inline-block and the
> overflowing text clips a marker, only the text is hidden; not the
> whole inline-block as intended.

Chrome and Opera don't seem to drop inline-blocks. Instead, they don't show an ellipsis if it would intersect an inline-block. IE does hide some inline-blocks sometimes... but not consistently :-(. This sucks!

Hmm. I think we actually shouldn't hide "large" inline-blocks, replaced elements, or images. Maybe it's better to never hide content other than text. We definitely don't want the marker to overlap content, though. In that case, we could use this policy:
-- Show a marker for the line if the line has text beyond the clipping edge of the block, AND the line has no CSS boxes, other than text and inline boxes, whose border-box would horizontally intersect the marker. Note that if we do it this way we would have to scan the frame tree, not the display item tree ... I think elements which don't paint anything (e.g. they have a width and height but no border, background or rendered children) should still affect whether a marker is displayed. I'm not 100% sure about that though.
-- When we show a marker, remove all glyph clusters whose trailing x-advance is beyond the leading x-origin of the marker if the trailing edge of the marker was aligned with the block clipping edge.
-- Then position the marker at the x-origin of the leading removed glyph cluster before the clip edge, or if there isn't one, align the trailing edge of the marker with the block clipping edge.

> Should a marker affect ScrollIntoView or a caret in any way?

I think we should not show the marker if the caret or the selection intersects the marker. (I.e. include a check for the caret or selection in the first step above.) But getting the invalidation for this right could be tricky; it will be easier when we have display-list-based invalidation. Maybe we should defer this to a followup patch.

> ScrollIntoView: scroll a bit extra to come clear of a marker?

Yes, I think for usability we should bring the content into further into view by the width of the marker. This shouldn't be too hard to do, but it should probably be a separate patch.

	Robert Lee
	Comment 144 • 13 years ago

This probably isn't the right place for this, but I don't know where else to post this. Apologies in advance.

Will it be possible to explicitly style the ellipsis using CSS? Example:

#mydiv {overflow: ellipsis;}

#mydiv:-moz-ellipsis {content: "....."; color: green;}

If so, it could help resolve browser parity issues and standards ambiguities with regards to styling (text-shadow, text-decoration, textual content, positioning, etc...) by enabling web developers to provide their own desired style overrides. Reasonable defaults would still need to be provided, obviously.

My suggestion above just uses a -moz-prefixed pseudo-selector for the ellipsis, which would basically work similarly to the ":after" pseudo-selector. I think such an extension to the standards would be appropriate, non-invasive and quite powerful.

	David Baron :dbaron:
	Comment 145 • 13 years ago

Comment on attachment 529429 [details] [diff] [review]
part 1, style system

I think you probably want 'text-overflow: inherit' everywhere in
ua.css and forms.css that we have unicode-bidi: inherit -- which means
you're missing 2 places in ua.css.  (We should probably reorganize
that at some point, but do NOT do it in this patch.)

In nsRuleNode.cpp, please set text->mTextOverflow.mString in all
three branches, not just the third:  in the first two, call
text->mTextOverflow.mString.Truncate();

r=dbaron with those changes

	David Baron :dbaron:
	Comment 146 • 13 years ago

However, I'm not convinced that NS_STYLE_HINT_VISUAL is sufficient -- shouldn't NS_STYLE_HINT_REFLOW be required?  Or does our implementation differ from the spec enough (why?) that it isn't?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 147 • 13 years ago

(In reply to comment #144)
> #mydiv:-moz-ellipsis {content: "....."; color: green;}

That's harder to implement, so I wouldn't bother unless there's a real need for it.

(In reply to comment #146)
> However, I'm not convinced that NS_STYLE_HINT_VISUAL is sufficient -- shouldn't
> NS_STYLE_HINT_REFLOW be required?  Or does our implementation differ from the
> spec enough (why?) that it isn't?

I don't think reflow is required. Our design here hinges on making the presence or absence of a marker not affect layout (or overflow).

	Mats Palmgren (inactive) Assignee
	Comment 148 • 13 years ago

(In reply to comment #141)
> +        // Fall through to generate a display item (it'll be removed later
> +        // but we need it to know if there is displayable text beyond an
> +        // image, inline-block, etc that is on the block's clip edge).
> 
> Are we dealing with a situation where, for example, there's an image on the
> line which extends beyond the clip edge, followed by text, and you want
> to drop the image but show a marker?

Yes, this code normally optimizes that situation by not creating an item.
I need the item to see if it's an "image at the end of the line" (no marker)
or "image at the end of the line followed by text" (marker).

> In that situation I think we probably shouldn't show a marker. I think we
> should only show a marker when an nsDisplayText intersects the clip edge.

See below for my proposal...


(In reply to comment #143)
> Other browsers only display markers at one side of the block...
> Do you feel strongly that markers at both ends are desirable?

Personally, I can see the value in having two markers, especially in
scroll views.  This is a spec issue though.  I don't feel strongly
whether the single value form should generate both markers, but I do
think the spec should have support for two markers in some form.

> or else we would have to automatically mirror the string
> (see gfxUnicodeProperties::GetMirroredChar).

I haven't tried it, but it doesn't seem very attractive to me.
Separate left/right properties would be much better in that case.
I'll look into how much work that would be.

> > 2. Text in a <textarea> appears pixel-clipped by the marker.  AFAICT,
> > I'm calculating the number of characters that fit correctly, but it
> > seems the background hasn't been repainted by the block?
> 
> Not sure what you mean.

See the <textarea> examples in "Test 2, form elements" using a test build.

> Other browsers don't apply text-decorations, which makes sense to me.

OK

> Opera and Chrome do apply text-shadow, so we should too.

Definitely, but we shouldn't block on that, IMO.

> Hmm. I think we actually shouldn't hide "large" inline-blocks, replaced
> elements, or images.

How about if we clip them normally (and not show a marker) if their visible
width is larger than the width of the marker?  That will look nice when
scrolling - as the inline-block is scrolled out of view it's removed when
the ellipsis would "connect" with the text before it; this avoids having
the marker hide text when it suddenly is shown again after the inline-block
disappears out of view.  It would also completely suppress "small" items
as they go over the clip edge in favor of showing a marker.

That means I would still need the text items that are otherwise not
generated.  I don't think that's big deal though, since it's limited to
text-overflow cases and I'm removing those items later.

	Mats Palmgren (inactive) Assignee
	Comment 149 • 13 years ago

> Are we dealing with a situation where, for example, there's an image on the
> line which extends beyond the clip edge, followed by text, and you want
> to drop the image but show a marker?

Actually, it's not just the example I mentioned above.  We need those items
for basic correctness (knowing if there is text outside the clip edge).

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 150 • 13 years ago

(In reply to comment #148)
> How about if we clip them normally (and not show a marker) if their visible
> width is larger than the width of the marker?  That will look nice when
> scrolling - as the inline-block is scrolled out of view it's removed when
> the ellipsis would "connect" with the text before it; this avoids having
> the marker hide text when it suddenly is shown again after the inline-block
> disappears out of view.  It would also completely suppress "small" items
> as they go over the clip edge in favor of showing a marker.

It might be a little bit better but it adds complexity for not much gain IMHO. Not many replaced elements and inline-blocks will be narrower than the ellipsis.

	Mats Palmgren (inactive) Assignee
	Comment 152 • 13 years ago

I have now implemented a text-aligned marker model to match the spec
and other UAs, instead of the block-aligned model in the first build.

The clipping behavior is now purely visual clipping.

I have now implemented whole-character clipping for text-decorations
and text-shadows (which was missing in the last build).

I changed the behavior to match the spec for the case where two
markers are needed but only one fits.

I'm not removing atomic inlines to make room for a marker as I did
earlier.  Except in one case: when an atomic inline is clipped on
the block's edge, if the *visible* part of it inside the view is less
than the marker width, then remove it.  This looks better visually
when scrolling over a line with mixed text and atomic elements -
as they "go out of view" the effect is that the marker shows up
before it would clip any text on the other side of the atomic element.

The marker is [pixel] clipped when there is insufficient space to
render it fully.  I clip the right marker on the right side (i.e. at
the right block edge), and the left marker on the left side.
FWIW, I actually implemented the opposite as well and compared them.
Clipping on the "outside" looks better when scrolling; as you scroll
and the marker bumps into an atomic element it "stops" there and that
feels like the marker "belongs with the text" as it goes out of view.
Clipping on the inside gave me the feeling that the marker "slides
under" the atomic element which felt weird.

I'm now inhibiting the markers when there's a caret in the block,
i.e. the behavior is text-overflow:clip.

BUGS

1. Text in a <textarea> appears pixel-clipped by the marker.
   (as described in comment 140)

2. text-shadow for the marker text isn't implemented yet.

3. Text shows up under the marker when there's a selection.
   With visual clipping this feels like less of a problem though
   (feature?) :-) since it doesn't move glyphs around as it did
   with RTL text in the last build.
   (hmm, is this what causes the <textarea> problem? does it take the
    selection paint path always?)


Builds for testing are available:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla.com-0f9891448a5d/

	Mats Palmgren (inactive) Assignee
	Comment 153 • 13 years ago

I removed all the 'text-overflow: inherit' I added in the last patch
and use the style of the primary frame instead, as roc suggested.
See TextOverflow::GetTextOverflowStyleFor() in the layout part for
details.

> In nsRuleNode.cpp, please set text->mTextOverflow.mString in all
> three branches, not just the third:  in the first two, call
> text->mTextOverflow.mString.Truncate();

Thanks!  I fixed the first branch as you suggested.  The 'inherit'
branch should be OK as is I think:

+    text->mTextOverflow = parentText->mTextOverflow;

as that will do memberwise assignment and thus copy the string from
'parentText', and that's what we want right?

	Mats Palmgren (inactive) Assignee
	Comment 154 • 13 years ago

I've add new files layout/generic/TextOverflow.h/cpp for the
bulk of the code that was in nsBlockFrame.

I moved the PaintText stuff into a separate method
nsTextFrame::MeasureCharClippedText()
I discovered one problem in it - when applying the char-snapping
on edges that are already snapped the result should be the same.
But BreakAndMeasureText returns an advance that doesn't seem to 
fulfill that.  I doesn't appear to be a rounding problem, but I'm
not sure.  I added an XXX comment in the code (with wallpaper):
  // XXX we need to ensure that the snapped values we return can be used
  // as input values and give the same result.  Subtracting 1 app unit seems
  // to fix it altough I was expecting that floor should be enough(?)
  // I tried TIGHT_INK_EXTENTS but that didn't make a difference...
  snappedStartEdge = NSToCoordFloor(advanceWidth) - 1;

I added a new display item nsDisplayVaryingRelativeToMovingFrame
for the dummy item needed in scroll frames.
I think I've addressed your other comments as well.

	David Baron :dbaron:
	Comment 155 • 13 years ago

(In reply to comment #153)
> I removed all the 'text-overflow: inherit' I added in the last patch
> and use the style of the primary frame instead, as roc suggested.
> See TextOverflow::GetTextOverflowStyleFor() in the layout part for
> details.

Why?  It seems quite unusual to do it that way.

> Thanks!  I fixed the first branch as you suggested.  The 'inherit'
> branch should be OK as is I think:
> 
> +    text->mTextOverflow = parentText->mTextOverflow;
> 
> as that will do memberwise assignment and thus copy the string from
> 'parentText', and that's what we want right?

yes

	Mats Palmgren (inactive) Assignee
	Comment 156 • 13 years ago

This adds support for having separate left/right text-overflow behavior.
It adds text-overflow-left/right properties and a two-value form:
text-overflow: <left-value> <right-value>

	Mats Palmgren (inactive) Assignee
	Comment 157 • 13 years ago

Separate left/right values was mostly prepared for already, but there
was one problem:  when one side has 'clip' we want that side to clip
normally by pixel, not clip whole characters.
I solved that by pretending the clip edge is at nscoord_MAX.
I'll look into if there's a less hacky way to solve this.

	Mats Palmgren (inactive) Assignee
	Comment 158 • 13 years ago

Builds that support text-overflow-left/right are available here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla.com-6760dd3d7115/

	Mats Palmgren (inactive) Assignee
	Comment 159 • 13 years ago

Aligning the marker with the text looks jittery while scrolling, especially
when many lines have markers.  This testcase illustrates the problem.

	Mats Palmgren (inactive) Assignee
	Comment 160 • 13 years ago

One possible solution would be to align at the block edge while scrolling,
then align with the end of the text after a small delay.
This patch implements this proposal and it looks much smoother while
scrolling.  The delay after the scrolling stops is still too long in this
build though (3-4 seconds)...

Builds:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla.com-7e5f03ee8393/

	Mats Palmgren (inactive) Assignee
	Comment 161 • 13 years ago

This patch fixes the delay problem by setting a shorter timeout (300-400ms)
in the expiration tracker in nsGfxScrollFrame when there's a possible
text-overflow marker in this scroll frame.  When I grab the scroll thumb
and scroll a bit and then release the button the marker snaps to the text
just about as I release the button (on a Linux desktop PC).

I would appreciate feedback on whether:
  A. scrolling feels smooth in Test 8
  B. aligning the marker to the text after scrolling stops
     feels fast enough

Builds:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla.com-e6724ff7cb71/
(still building, should be ready in an hour or so)

	Mats Palmgren (inactive) Assignee
	Comment 162 • 13 years ago

(In reply to comment #155)
> Why?  It seems quite unusual to do it that way.

See roc's comment 141.

I agree that GetTextOverflowStyleFor() feels a bit hacky, and likely slower.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 163 • 13 years ago

You should probably do what dbaron said in comment #145.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 164 • 13 years ago

Comment on attachment 529430 [details] [diff] [review]
part 2, nsLayoutUtils::GetTextColor()

Review of attachment 529430 [details] [diff] [review]:
-----------------------------------------------------------------

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 165 • 13 years ago

I think you should use namespace "css" instead of "layout".

Need comments for the methods of TextOverflow and the new methods of nsTextFrame. Also for the class nsCharClipDisplayItem.

Since we're still trying to figure out the behavior for some cases, let's split up the layout patch a bit more. The new nsDisplayList methods can go in one patch, another patch can have nsCharClipDisplayItem and the changes to existing display items that use it, another patch can have the nsTextFrameThebes changes to support clipping edges, another patch can add TextOverflow, and another patch can add the hooks from nsBlockFrame that use TextOverflow. One advantage of doing that is that if we need to disable text-overflow, we can just back out that last patch.

	Mats Palmgren (inactive) Assignee
	Comment 166 • 13 years ago

OK, will do.  FYI, there are a couple of bugs in the layout patch when
clipping decorations/shadows.  We should use GetVisualOverflowRect() when
analyzing and nsCharClipDisplayItem::Intersect is just plain wrong.
I'm looking into that, new patches coming soon.

	fantasai
	Comment 167 • 13 years ago

Mats, I really don't think you should be implementing separate -left/-right properties. I can't imagine a reason for them to cascade independently. (And "left"/"right" doesn't make any sense for vertical text.)