ColumnText component

This time, I’ve concocted a widget that I’ve wanted to do for the longest time, but somehow always left it for later.

ColumnText is a widget that simply splits long passages of text into several columns. This way, you can utilize all the width you have on the screen, but maintain readability with short lines of text. In addition to text, the widget handles CSS-stylized XHTML content (which was unnecessarily hard to accomplish, to tell you the truth).

I have made the component as an example of two useful GWT2-features serving dedicated resources to different browsers:
deferred binding
conditional CSS
. A turn-by-turn guide of the choices I have made with the source code is being written into
, hopefully helping anyone interested in this feature to provide optimized widgetsets to each and everyone.

Anyways, a live demo is at
, sources are available at
(under Apache 2.0, naturally). Both .jar and
example application
are also available.

Just wondering, does it revert from JavaScript calculations to pure CSS3 columns where applicable (like newest WebKits and Geckos)?

It doesn’t, but that would be a great feature indeed. I’ll look into whether it can be achieved gracefully.

I’m wondering whether unsupported CSS styles are shown in the DOM or not. So, if i set the “columns” (or the -moz/-webkit counterparts) style, and the browser doesn’t support it, does the element still have that CSS style, or can I depend on the browser removing it?

The unsupported CSS should not be a problem, but if you aim for GWT 2.0 (Vaadin 6.3 is just around the corner), you can actually do better: it supports conditional CSS. You could actually customize the clientside widget and styles completely. AND it would make a great example on how to do that!

It’s still very nice as-is, BTW :slight_smile:

Best Regards,

Sounds like a challenge; I accept!

Fortunately for you, I mostly work on my components from home, so I can’t even nag you for help :wink:

The widget has now been updated to 1.0.0, and depending on your browser’s abilities, you will either get a CSS3-version that uses the column-amount CSS attribute, or a version that does all that work with JavaScript.

It also now acts as an example of how to do deferred binding and conditional CSS in GWT2. And, talking about GWT2, the 1.0.0 version works only with Vaadin 6.3 and upwards.

Here is a quick bug report. Tried the demo in Safari 4. When I resize the demo with default settings, a part of a heading jumps strangely from column to another. See the screenshots below.

Joonas, no bug there. If you look closely, you’ll realize there’s two different sets of text on top of each other. A little spacing between them would harm, Henrik, I got fooled at first too that the header got mixed up somehow.

Great work, Henrik, and thanks for taking my suggestion about CSS3 columns seriously. I hope it wasn’t too much trouble :slight_smile:

Oh man… This was confusing demo :)

One feature request/idea: setSpacing(int spacingBetweenTheColumnsInPx)

In any case - great component.

I must admit, I was a bit baffled by your screenshot too, wondering how in the world the text jumped like that. But, as Jouni already diagnosed, it’s just a matter of spacing. This is weird, since I see plenty of spacing.

But I thank you both for this observation, and I’m very sorry for the confusion. I’ll make a bit of spacing immediately.

I’m glad you suggested it, since it really made sense. Since some browsers can do it already, let them do it. It’s bound to be much more efficient than doing it the laborious way.

Actually, it was a surprising amount of trouble (but the good kind of requires-some-thinking-trouble). But I mostly blame GWT’s confusing documentation on this matter. I’m trying to make things a bit more clear with the companion piece I’m currently writing. The end result tells a distinct tale that GWT wasn’t really made for single-widget widgetsets, since there are a lot (too many, imo) of various files involved.

But, you’ll have to wait for the text to be ready to get a more thorough explanation on the matter :slight_smile:

Great idea, I’ll make sure that will come into version 1.1.0.

The article is now up at

I intended it to be up at my wiki, but the editor just seemed to disagree too much with me how I wanted to write the piece, so I switched to my trusty blog instead.

An excellent article!

I’m pretty sure (and indeed, I am fervently praying) that I’ll never need to code down to that level of browser-specific code generation - I suspect it’s more of a core-widgetset thing - but it’s good to know that it’s possible.



I may soothe your fears: It’s not as much a question of
, but rather one of
. In my case, the JavaScript splitting of colums would’ve worked with all browsers equally well, so there was no
. I just
to provide two implementations.

Admittedly, this was done more as an exercise, intrigued by Marc and Jouni above, but I do like knowing that my little precious now allows some browser to do their stuff in-engine.