Tuesday, April 7th, 2009

Text-Overflow for Firefox via jQuery

Category: Firefox, jQuery, Plugins

>Devon Govett is a fan of the new CSS3 property text-overflow:

There are a few CSS features that Microsoft pioneered and has had available to developers in Internet Explorer for a long time now. One of those features is the text-overflow property, which is now in CSS3 and has implementations in Safari, and Opera. Firefox still does not support this feature, but I have heard that it will in Firefox 3.1.

Here is a rundown of what the property does. When text overflows an element’s box, the text-overflow property helps leave a visual hint to the user that there is more text. When a value of ellipsis is used, three dots will be shown before the text is clipped by overflow: hidden.

Lorem ipsum dolor sit amet, c…

I wanted to be able to use this feature in all browsers, so I wrote a small jQuery plugin in order to support Firefox. To use, just call ellipsis() on a jQuery object. For example:

$("span").ellipsis();

Check out the plug-in, and also a demo of it in action.

Posted by Ben Galbraith at 9:03 am
26 Comments

+++--
3.3 rating from 33 votes

26 Comments »

Comments feed TrackBack URI

The firefox bug on this feature:

https://bugzilla.mozilla.org/show_bug.cgi?id=312156

I tried a while back to get this implemented, but the problem is that the draft specification does not correspond with what browsers do, and that none of the browsers implement something that can be considered “correct”. IE’s behavior is the most sane, but even it has some corner cases in which the behavior is clearly broken. I sent a suggested spec wording to www-style but didn’t get any feedback, and haven’t bothered to try to move it along since.

My guess is someone will have to put up the code, so firefox has this as well, and once that happens standardization will follow by itself. Developing this feature on gecko myself is a bit daunting though.

Comment by Joeri — April 7, 2009

This is actually a very useful CSS feature. It’s sad that Firefox is the only major browser not supporting this… And damaging to Firefox’s image.

But maybe Firefox will support this soon, if enough of us developers vote for it:
https://bugzilla.mozilla.org/show_bug.cgi?id=312156

Comment by andysky — April 7, 2009

Because of the use of $.browser.mozilla in the plugin, this won’t work with jQuery 1.3.2+.

Comment by MichaelThompson — April 7, 2009

@MichaelThompson: this is why feature detection never gets you all the way there. There’s no way to detect this feature from javascript, as it is a purely visual feature that doesn’t affect the DOM state in any way.

Comment by Joeri — April 7, 2009

CJK Support?

Comment by coolnalu — April 7, 2009

@andysky,

This is actually a very useful CSS feature. It’s sad that Firefox is the only major browser not supporting this… And damaging to Firefox’s image.

Let’s be realistic. The only people whose image of Firefox is damaged by this are web developers who have particularly strong CSS demands. That’s a very tiny minority, even of Firefox’s user base.

@MichaelThompson:

Because of the use of $.browser.mozilla in the plugin, this won’t work with jQuery 1.3.2+.

It’s not terribly difficult to replace jQuery’s browser detection with your own.

For instance:
var isGecko = (!!window.Array.every || !!window.Iterator || !!window.getComputedStyle) && !!document.doctype && !window.opera && (!!window.devicePixelRatio && !!window.getMatchedCSSRules);

First group is features Gecko has introduced; second and fourth avoid confusion with some Safari versions; third is obvious.

Comment by eyelidlessness — April 7, 2009

Oops, that last parenthesized group was meant to be !(!!window.devicePixelRatio && !!window.getMatchedCSSRules);

Comment by eyelidlessness — April 7, 2009

Nice plugin; however, it doesn’t seem to account for variance in font-size or font-weight…

Comment by neuf — April 7, 2009

@eyelidlessness: this is a usability issue. Take a grid with fixed width columns, then put amounts in those columns, and then have the column clip those numbers between two digits. There’s no way to tell whether you’re looking at the correct amount or just the first digits of it. You have to include decimal separators just to give an indication, and even then for most users it still won’t be obvious. The same problem exists for names.

Comment by Joeri — April 7, 2009

We just keep coming to back to browser sniffing, don’t we? Please don’t do that. Here’s a proper test that works just fine:


...
var s = document.documentElement.style;
if (!('textOverflow' in s || 'OTextOverflow' in s)) {
// implement workaround
}
...

Comment by kangax — April 7, 2009

@eyelidlessness:
The only people whose image of Firefox is damaged by this are web developers who have particularly strong CSS demands. That’s a very tiny minority, even of Firefox’s user base.

You didn’t get my point — Websites which look fine in IE (by webmasters who didn’t test on Firefox) with the text-overflow CSS property, won’t display properly on Firefox — this damages Firefox’s image for even a *new user* who’s trying this browser and visits such a site.

Comment by andysky — April 7, 2009

To further reinforce my point, now imagine that that user then tries Google Chrome and the site displays perfectly. Which browser will this user, in the end, choose?

See what I mean?

Comment by andysky — April 7, 2009

@kangax
Nice … !! :P

Comment by ThomasHansen — April 8, 2009

Thanks @kangax! I have integrated your test into the plugin in replacement of $.browser.mozilla. The new plugin is available at http://bit.ly/SRLg9.

I am working on some of the other issues!
Devon

Comment by devongovett — April 8, 2009

I can’t help wondering why this post contains hearsay about FF3.1 supporting text-overlow:ellipsis; I mean, it takes a few seconds to find the bug report so just link to it otherwise there’s no point to mislead the readers.

Comment by p01 — April 8, 2009

@Joeri,

I’m not sure what part of my comment you’re responding to, if any, but I’ll bite. I’m not convinced it’s a usability issue. An ellipsis is pretty well understood by most people to indicate truncation. And in any case, its use should be paired with functionality to make the rest of the text available, either in tooltip form or in some form of DHTML expansion functionality (using your example, it should only be applied if Javascript is available, and paired with the ability to resize columns).

@andysky,

You didn’t get my point — Websites which look fine in IE (by webmasters who didn’t test on Firefox) with the text-overflow CSS property, won’t display properly on Firefox — this damages Firefox’s image for even a *new user* who’s trying this browser and visits such a site.

To some small degree, perhaps, but with obviously cut off text, the ellipsis is primarily a style concern. I doubt it will leave a lasting impression for most users.

To further reinforce my point, now imagine that that user then tries Google Chrome and the site displays perfectly. Which browser will this user, in the end, choose?

See what I mean?

In the case where the difference is an ellipsis or no ellipsis? I doubt it would affect browser choice. But if it does, so be it. That’s part of the benefit of browser choice. And if it drives a user to Chrome or Safari, I’m glad. WebKit is stronger than Gecko anyway, and I’d prefer Chrome and Safari replace Firefox in the market for the foreseeable future. If it drives a user to IE? Oh well. It’s a drop in the bucket compared to IE’s market share trend.

It’s such a tiny, insignificant issue. I really doubt most users even notice. I mean, for instance, even as a UI developer with strong design skills, I don’t know how long Gmail had lost its text-overflow goodness (in Safari, I don’t know whether it’s still there in other browsers) before I noticed. And granted, I was disappointed to see it go, but only from an aesthetic perspective. Gmail is no less usable, and I can’t imagine switching browsers to get some ellipsis action. And I run multiple browsers! Getting a regular user to switch browsers is very difficult, and this is really unlikely to be the straw that breaks that back.

Comment by eyelidlessness — April 8, 2009

@eyelidlessness: you seemed to imply that the absence of text-overflow support in the browser was not a problem. I was pointing out that if you don’t have it, there’s a case to be made that it’s a usability issue. I’ll admit that it’s not a large one.

Gmail probably removed it because of RTL issues, which were pretty severe on opera when I tried it (opera 9.5).

I’m not a big fan of implementing this in javascript, especially in grids, because aside from the performance issues when resizing this also makes it difficult to copy/paste the grid in its entirety to excel. There are quite a few users that actually do that last bit.

Comment by Joeri — April 8, 2009

Is someone keeping a list of the dozen or so features (xmlhttp, getElementFromPoint, Iframes, innerHTML, etc. etc) that IE implemented, oh, a decade ago? Can I say it? … thank god the geniuses at Microsoft knew how to build web applications, or we’d still be using and watching our browsers crash :)

Comment by nataxia — April 8, 2009

seems <layer> got snipped…

Comment by nataxia — April 8, 2009

@Joeri: I understand what you mean now, and I agree that in some cases lacking text-overflow can cause usability issues. Like so many other CSS incompatibilities, I think it’s important to design around that.

As far as implementing it in Javascript preventing proper copy/paste into Excel, I think it depends on the implementation. Sure, you may get ellipsises here and there, but it’s simple enough to just find/replace those.

And yes, I think the style should be implemented in Gecko. But as far as importance goes, while I’d love to see it, I don’t think its absence is harming uptake for Firefox at all.

Comment by eyelidlessness — April 8, 2009

@nataxia: IE has definitely introduced a lot of great features. But they’ve simultaneously rested on their laurels while resisting interoperability with other browsers that have also implemented or introduced great features. Overall, IE went from the best browser to the worst (with any noteworthy marketshare, anyway) in just a few years, because Microsoft dropped development. That didn’t have to happen, but it did. And this is why IE is regarded so poorly by developers.

Wake me up when IE is comparable in terms of capability and performance with, hell, Firefox 2.

Comment by eyelidlessness — April 8, 2009

IE8 loads ajaxian.com in 5 seconds, FF3 takes 8 seconds. IE always had quite good general browsing performance, even if its javascript performance was sub-par, and with version 8 they again focused on general browsing improvements. It really is quite snappy.

IE8 also implements the entirety of CSS 2.1, which no other browser out there does. I like the attitude of trying to get the basics right before implementing experimental functionality like canvas or css transformations.

Comment by Joeri — April 9, 2009

@eyelidlessness I’m not sure you understand what I’m saying. There are a number of web application developers that have been doing this since JS first showed up in a browser (NS, which should get props where props are due). Seriously, since day 1. Those of us who saw the future. You may recall that around 1998/1999 full blown desktop-like applications, better than the stuff you are seeing even nowadays, was being built these people. In IE4, then IE5. Fantastically good applications (mine still work in IE8 without modification, BTW, backwards-compatibility demonstrating yet another example of the brilliance at MS — you try to keep your software BC for 15 years). Unfortunately, the other offerings (essentially NS4) were attrociously bad. Really. Complete and total garbage which those of us with masochistic tendencies managed to get working, sort of, hackily, with what just sang in IE. Around this time the hubub was really bubbling about how bad MS was. How *stupid* they are. How *bad* their software is. About 6 years were wasted bashing MS — which, simultaneously, stunted the growth of web based applications, with all the talk of how *bad* their browser was. When in fact it was *visionay*, a *fact* backed up by *history*. And maybe all that MS bashing was for the good, ultimately. But the point is this: all other browser makers have spent 10 years rebuilding the functionality that IE had, functionality that is *essential* to the functioning of the interwebs — xmlhttp, iframes, and several others. They have, in fact, simply wasted our time. So it is nice that they are finally useful. But what a wait…

Comment by nataxia — April 9, 2009

@nataxia – thanks for posting that, and I agree. I work on some legacy apps that were built in the 90s, targeted at IE4/NS4, and still work in IE8. … I support the development of standards 100%. But at the same time, recognize that a lot of the “innovations” coming out now are just a repeat of what you could do in IE5.5.

Comment by WillPeavy — April 10, 2009

How would this work if the bounding box was multi line?

Comment by turph — August 7, 2009

text-overflow ellipsis does not work on Firefox. So i found this plugin for ellipsis to work in Firefox.
Below one works but very slow when there are more than 100 div’s.

if (navigator.userAgent.indexOf(“Firefox”) != -1) {
$(“.yui-content div[class*='ellipsis']“).ellipsis();
}

Any idea to increase performance there are more div’s

Comment by ddsuresh — July 2, 2010

Leave a comment

You must be logged in to post a comment.