How to connect content in columns?

[Wedgy]

I will try to articulate this question and hopefully get MWinter's input:

Taking your elegant example of a two-column spread:

http://www.mlwinter.pwp.blueyonder.c...wo-column.html

I think back to two simple and useful features from long-standing word-processing and layout programs, namely, on the MAC years ago you could simply attach the end of one column or box of text, to the beginning of another. The basic result is that a large chunk of text/small graphics flowed from one box to the other. If you adjusted the sizes of one or both boxes/columns, the text simply and automatically placed the appropriate amount in each box/column. Why can't I do that in HTML?

The idea would be that the total page length (with header and footer) would be decided based upon the content split between the two columns/boxes. If you changed the width of the total window, then in a semi-liquid layout, you would see the page shorten or lengthen as content space was stretched horizontally. The basic amount of content would stay about equally split between boxes/columns.

From this base, it would be great to drop a graphic, about the same width as one column/box, but right in the center of the page, and have the text flow around it on either side. This should be simple, but I have not seen any examples at all of how it could be done.

Note that the graphic would be at least the width of just one column, and it would be outside the area of the columns, but penetrating into both.
Just like the little thumbnails shown in Word when you go to format an image, and you should be able to easily choose a style of the flow-around, based upon the visible area/shape of the graphic (if it had transparent parts.)

Hope that wasn't too wordy.

--------
by the way, you probably know this, but at certain widths between 600 and 900 pixels, the two columns unpredictably jump from side-by-side to sequential, leaving an empty space on the right. very odd. Is that some kind of floating-point divide by zero error in IE?

[Wedgy]

Christmas is nearly here. I wonder if mwinter is working in Santa's shop?

[mwinter]

I will try to articulate this question and hopefully get MWinter's input:

Sorry. I didn't see this thread until you posted your follow-up.

Taking your elegant example of a two-column spread:

http://www.mlwinter.pwp.blueyonder.c...wo-column.html

I only just noticed how overpowering that blue background is. Oh well...

I think back to two simple and useful features from long-standing word-processing and layout programs, namely, on the MAC years ago you could simply attach the end of one column or box of text, to the beginning of another. The basic result is that a large chunk of text/small graphics flowed from one box to the other. If you adjusted the sizes of one or both boxes/columns, the text simply and automatically placed the appropriate amount in each box/column. Why can't I do that in HTML?

The column effect is presentational, which is beyond the remit of HTML.

You obviously aren't the first person to want a layout like this, but currently there's no way to achieve it. There is a multi-column layout proposal in CSS 3, but it isn't scheduled to reach Last Call until 2007, and probably won't reach Recommendation until after 2010.

From this base, it would be great to drop a graphic, about the same width as one column/box, but right in the center of the page, and have the text flow around it on either side. This should be simple, but I have not seen any examples at all of how it could be done.

This would also be possible with the proposal, but nothing concrete has been defined yet. See Floating in and between columns.

by the way, you probably know this, but at certain widths between 600 and 900 pixels, the two columns unpredictably jump from side-by-side to sequential, leaving an empty space on the right. very odd. Is that some kind of floating-point divide by zero error in IE?

It's more likely to be a rounding error. It occurs in Firefox as well, but I didn't realise the extent.

At around 711 pixels[1], the columns should stop shrinking. It doesn't do them any good to carry on getting smaller. This then means that the combined width of the columns, their borders, padding, and margins will exceed the viewport width and the columns will reflow. Before the min-width property is applied, the combined width shouldn't exceed 98.8%, but clearly it does for some values. This could be avoided by increasing the margin for error.

As I mentioned in the thread where I first posted that URL, the effect can be polished using media queries, but support is lacking in major browsers (except Opera). It could even be possible for IE to show the same results as better browsers, though I'd have to know why it crashed (it hasn't previously when emulating min-width) before demonstrating that.

Mike


[1] Viewport width: 20x ÷ 45 × 100, where x is the default font size in pixels (16 on this machine).

[Wedgy]

You obviously aren't the first person to want a layout like this, but currently there's no way to achieve it. There is a multi-column layout proposal in CSS 3, but it isn't scheduled to reach Last Call until 2007, and probably won't reach Recommendation until after 2010.

oUCH.
I wonder if in this case it can be achieved in Flash or Python or something,
since it can't be really complicated or "new" code. The idea has been around for 20 years, and has been found in just about every Page Layout program sold. That should be plenty of time for all the bugs to be out, and tons of open-source code available in dozens of languages for stand-alone (non-web).

It seems fantastic (in the negative sense) that no one has implemented this in Javascript or at least faked it.

[mwinter]

I wonder if in this case it can be achieved in Flash or Python or something

Java should certainly be able to, and I'd guess that Flash could.

It seems fantastic (in the negative sense) that no one has implemented this in Javascript or at least faked it.

However, you seem to think that it's relatively trivial. As far as I can see, it's not feasible with client-side scripting.

Several things need to be calculated. Depending on whether the column widths or number of columns is predefined, the order of these calculations will need to changed. I'll take the former as an example.

It's obviously necessary to know how many columns we can fit inside an element (set column numbers would mean calculating the column width), so the first necessary bit of data is how wide is the element? Browsers that properly support the W3C DOM 2 Style module can return that information using the getComputedStyle method. Other browsers can use proprietary properties like clientWidth. If neither is available, the text will just have to be displayed normally (similarly with later calculations).

Next, the number of columns, using the formula:

total width ≥ column width × columns + column spacing × (columns − 1)
    columns = floor((total width − column width) ÷ (column width + column spacing) + 1)

In order to get complete lines in each column, knowing the line height is important. Again, the getComputedStyle method can get this directly. Other browsers will need to jump through hoops, but it's also possible for some of them as well.

It's at this stage where things become rather more difficult. To split the text between the columns as evenly as possible, the number of lines in the text needs to be known (at the calculated column width). The only way I can think of doing that is to compute the height of block level element - similar to the width, previously - fixed to the column width. Dividing this height by the computed line height will yield the number of lines. Next, these lines need to be distributed between the columns, so the total number of lines is divided by the number of columns, rounding the result up to the nearest whole number. The problem is then working out where, in the text, the column breaks will appear.

When working with a GUI toolkit, or directly with the operating system, a complete set of font metric and line wrapping functions should be provided. None of that exists for client-side scripts. The nearest thing would be to use our fixed-width, block-level element again. Words would be added one-by-one until the computed height is greater than the line height (signalling that the word just added created a second line), or until you've reached the required number of lines. However, this method would be incredibly inefficient. Granted, the operating system is likely to compute line lengths for variable-width type faces on a character basis, summing the extent of each character, but at least that will be implemented in highly optimised, native code. I wouldn't predict anything near that performance for a script.

A further complication is changing the font size after rendering. An applet would provide its own controls for such an operation, so triggering a change could simultaneously repaint the columns. However, a script won't receive a similar notification. Another is that resizing the viewport would also require recalculating, and repainting, the columns.

Mike

[Wedgy]

Excellent introduction to the problem posed.

I will need some time to mull this over and grasp the difficulties raised.

Thank you for your responses again.