<wbr> tag; do you use it? Or use something else for breaking up long strings of text?

I was looking around for ways to break up long strings of text so they didn’t overflow and break the layout of a page. I started using the unicode zero space character &#8203, but it doesn’t render in opera 10+ (or IE5.5)–you get an ugly square box like this:


I already submitted a bug report when Opera 10.10 was out, but it looks like they haven’t gotten around to fixing it yet.

So, I looked around and eventually came up with something that seems to work in most browsers, and made a post about it:


Interestingly enough, <wbr> isn’t in any of the W3C (X)HTML specs, aside from HTML5. Another interesting finding was that IE8 ignores it completely in standards mode (but not quirks mode), while all previous versions support the <wbr> tag.

Is the <wbr> tag something you use? How about the zero space character?

To prevent long strings of unbroken text from playing havoc with your design layout, do you rely on the CSS overflow property, or the CSS3 word-break, or both, or something else?

Use it? This is the first I’ve heard of it!

Sounds like a good idea though - if and when it gets supported.

So far I’ve done this server-side when possible, and when not either let the page get horizontal scroll or otherwise mangle the design, or put the text into an overflow: scroll (a bit ugly).

I usually loathe to resort to non-standards tags to do things. I think I saw your post about this on the Opera forums and responded in the negative to it, but I’ve had some time to think on a better standards compliant answer; here’s what I’ve come up with.

The ‘real’ answer should probably be the unicode #8203; character - a zwsp (zero width space) - but as was noted on the opera forums this character has… problems. I don’t much care for relying on unicode characters as a solution anyways.

The best solution is to wrap it in another tag, but that can get ugly since you’d need a class on it… or do you?

One of the rarely used tags is DEL - deleted text. If we wrap our #8203; in DEL, we can skip using classes if we don’t plan on using DEL for anything else, then use a few CSS tricks to ‘hide it’ while still having it provide our breaks.



(de-entity the ampersand in the working copy, the forums seems to be screwing with that)

With this for CSS:

del {

The inline-block lets us set a width, the visibility:hidden hides it when IE 6 and 5.5 try to render the unknown character block, the overflow chops off should some browser ignore our font-size declaration and override the width (IE 5.01), the font-size fixes a line-height issue across all browsers except FF and the IE container width bug, we then set a width, and a negative margin to make it zero width for calculating flow.

It’s not as simple or clean as a WBR, but it works from IE 5.01 to IE8, as well as all modern browsers and at least it uses valid markup… and if you don’t care about versions of Firefox prior to 3.0, you can get rid of the two -moz properties for valid CSS as well.

Sometimes you gotta go with what works everywhere.

— EDIT —

DUH, I forgot about a quirk in the CSS specification - and it’s a fun one…

Inline-block level elements inherently break a word’s run-in. That means you don’t actually need the zero width space inside the DEL tag… and IE in quirks mode (5.x) treats all inline-level tags as word-breaks anyhow.

So all you need is:

using the above CSS… You can cut the CSS all the way down to :

del {

If you don’t care about it breaking in IE 5.01 (it still works in 5.5)… So if you are willing to drop FF 2.x/earlier, you could cut the CSS all the way down to:

del {

That’s a lot simpler. Too bad there’s no rarely used self closing inline-level tag we couldn’t sandbag with… but DEL does the job well enough, and it’s not like it’s content we need to worry about semantically being ‘deleted’. A simple empty DEL set to inline-block… could be far worse.

Though I might be tempted to use the larger version with the zwsp inside it so that it works when CSS is not present.

As far as I was aware WBR was deprecated from the old browser wars days (between IE and Netscape), it’s entirely proprietary. :slight_smile:

deathshadow60: Interesting approach. On the upside, it validates. On the downside, it’s not exactly semantically correct :frowning:

Actually, running with that idea a little further, you could probably use almost any inline tag (em, strong, a, span, var, cite, samp,…etc.)

Alex: <wbr> is found in every browser (even linux-only browsers) except for IE8 and Opera, according to all the testing I did. Meaning Chrome, Konqueror, FF, IE, Netscape…I was actually quite surprised to see how widely supported it actually was for being proprietary.

It’s in the HTML5 spec, so it looks like it may be officially supported from now on. However, changing the doctype for HTML5 does not appear to “reactivate” <wbr> in IE8 or Opera without using my suggested CSS fix.

Actually, I just came up with one better I think…

wbr { display:inline-block; }

Makes it work in IE8 standards mode and Opera 10.53 (tested in a XHTML 1.0 Strict doctype)

It’s there in the dom tree in both browsers, it’s just got nothing applied to it (interestingly the hooks for :after or :before are missing in IE)… Inline-block appears to give us our desired behavior…

Bingo, joker, JACKPOT.

I usually rail against using proprietary elements, but this one is just too useful to give up - much like zoom or -moz in the CSS, I might be willing to make an exception for this one.

That’s the fix I posted in my blog post. Perhaps I should’ve copied & pasted it here earlier :-/

Pretty much, had no idea you even had a blog, much less a post on the subject or a working solution…

From what you were saying in this thread it didn’t sound like you had it working.

I was under the impression the SHY was the current advocated method. Though obviously this is a slightly different question so it would need a different approach.

deathshadow60: yep, I linked to it in the first post in the thread.

Since this solution breaks validation, I was looking to see if any of the wizards here had better solutions that validated.

xhtmlcoder: ­ &shy adds a hyphen when it wraps things (zwsp and wbr do not). However, it does seem to be widely supported.

Who really cares if it fails the validation? Validation is just a tool, it’s not some sort of gold star. I would say if the element has a valid use and is widely supported then you should use it despite the inappropriate error as it has purpose. Just like how using proprietary code allows you to take advantage of opacity in Internet Explorer, it too fails validation but is purposeful for usage. I would say the HTML element is probably the most semantic option to use. :slight_smile:

Thyat’s because you are supposed to add a hyphen when you break a word in the middle. If you don’t then there is nothing to indicate that it is one word.

The other methods have the problem that they don’t add the required hyphen.

I see no problem with a hyphen being inserted into a word (in an appropriate place).
But in my experience the usual trouble makers are long URLs, which I definately would NOT want an added hyphen.

You don’t want ANY break in a long URL at all. A URL must be displayed all on the one line or it is broken when people try to copy it.

The obvious solution for long urls is the ones that forums use - they make it an active link and chop out the actual text in the middle when the url is too long. That way you can still right click to grab the full url and the url doesn’t break the container. Doing that means you can reduce the length of all urls so that they fit your container properly without needing breaks in them

How about things like serial numbers?

Or tabular data that you’d rather have wrap than get horizontal scrolling?

Or like the screenshot in my first post–I wouldn’t want to shorten the first column visually because it’s primary data.

Or, just user input…because we all know there are some jokers out there who will put long strings in just to see if they can break your layout.

With user input you would need to do server side processing anyway in order to be able to insert any type of break at all.

As for serial numbers - you definitely do not want a break in those regardless of how long they are.

Which one should be doing anyways since ALL user input is suspect and should be vigorously scrubbed.

You know, I could have sworn the second link in that first post pointed at a image as well, and not a blog post.

Right, hence the discussion about <wbr> and zwsp :slight_smile:

Maybe, maybe not. That’s just one specific example I could think of off the top of my head.