Re: [css3-tables] Optimize per column whitespace due to line wrapping

I am rushing (multi-tasking), so I might be mistaken, but I think I am
correct. I mainly wanted to get this issue documented. I am not pushing
for any changes.

"timeless" <timeless@gmail.com> wrote:
> there is lots of text here to eat space from the each of these
> words<br> is a potential wrap point which makes the table
> considerably<br> expensive if the table wrap algorithm isn't
> greedy.</td></tr></tbody></table></body></html>

But after current layout, that row has excess whitespace that can be
consumed by reducing the column width WITHOUT causing any cascading.

> the alternative approaches result in the columns jumping as you
> shrink/expand the window, which seems suboptimal.

Afaics, if the already (after standard layout) known whitespace is
consumed, there will be no jumping around. It merely shifts the column
contents position horizontally.  The only wrapping changes will be in
those columns that are made wider as a result, which afaics will cause no
wrapping cascade in the other columns.  It could move the vertical
position of rows below it, but that will cause no inline wrapping changes
to those rows.

> but generally multipass algorithms are very expensive (tending toward
> O(n^2) or O(n^3) and giving people indigestion).

Afaics, this is complexity O(1), because there is no cascade and because
the whitespace computation is done any way for the line wrapping.  It is
only a matter of storing the minimum value for a column and then adjust
the column horizontal positions.

Re-wrapping of the table cells for those columns that got wider is running
the layout twice, which is O(1) with respect to running once.

> there's also the minor detail that changing the behavior now would
> probably break existing content.

Afaics, no it won't break anything.  It will improve the optimization of
the whitespace only.  Such tables can make no assumptions about their
proportional widths with respect to wrapping.

Received on Monday, 3 January 2011 00:40:12 UTC