Comment by adrusi | Hacker News Reader

Comment by adrusi | Hacker News Reader

Adding the concept of paged layout to CSS is both cool and terrifying. Separating content into pages is a very powerful ability that I can see being quite useful, but it also adds a lot of complexity.

What do I do if my table gets split between two pages? What about my fancy border around the whole table, can I have it render a full border around each split segment of the table or will it just obnoxiously slice the border at the page break? Where will it decide to split the table, will my multi-line row get split down the middle? Moreover, how do all these properties affect the existing intricate layout mechanisms present in CSS?

I feel like these specifications will create fundamental conflicts in the way CSS handles layout, which will probably be resolved by forbiding the combinations of certain layout models. But that goes against the philosophy of CSS: composability.

CSS complects the ideas of UI layout and text flow with a surprisingly expressive language as a result, but those ideas are not truly compatible and eventually inconsitencies like this will arise. These systems push CSS past its practical limit.

I agree that paged layout are both cool and terrifying. Scrolled layout are much simpler for the formatter as there always is more space to use. Splitting content into pages, known as pagination, can be hard when there are unbreakable chunks in the content. In most cases you can split tables nicely (if they are real tables and not typographical devices), but images should never be split.

Still, I think it's worth it. A nicely laid out page is a pleasure to read, and I've never heard of only who have scrolled through "War and Peace" -- the act of turning a page seems more graceful. And when you are reading for child on your lap, turning the page to see if there's an interesting drawing of a rabbit becomes an event.

Surely, scrollbars will not go away, but we should be able to support pages one the web, too. Web pages, for real.

Are we full cycle yet? Is this the new HTML table layout, it took what, 14 years?

Nothing in CSS can ever be "new HTML table layout." Is concept of separating content from presentation so difficult to grasp?

Any app will require excess nested boxes to take care of most complex layouts. Plus the element tag names are presentation effecting, despite not being in the style sheet. (Element names are just corresponding to browser native CSS stylesheets) We aren't there yet so don't act all high and mighty pal

What is difficult to grasp is how a technology devoted to "presentation" failed so utterly to provide a decent layout mechanism consistent with its philosophy of separating of content from presentation. The absurdist kicker of this fiasco is that the existing semantic <table>, off limits for use as presentation, actually did the job ok.

[1] http://meyerweb.com/eric/thoughts/2009/02/17/wanted-layout-s...

I'm not sure they really "did the job ok", though I suppose it's easy to look back fondly on table layouts with rose-tinted spectacles, no doubt influenced by a decade of messing about with floated layouts.

As I recall, complex nested table layouts were horrendous to work with and could be very fragile. Perhaps their one great strength was that they were pretty consistent and had a very limited vernacular - once you understood the purpose of the elements TABLE, TR, TD, and perhaps THEAD and TBODY, and the attributes COLSPAN and ROWSPAN, well, that was it. Conceptually it was pretty easy to understand for anyone who'd used anything with rows and columns (eg. Excel).

They could be ugly and complex because of nesting, no doubt, but they at least provided a few fundamental layout concepts missing from CSS: easy vertical centering, and as you mentioned -- columns and rows.

The great strengths you mention, consistency and conceptual simplicity, are absolutely paramount, and the fact is that the limited vernacular allowed you to accomplish 90+% of your layout needs, perhaps more -- all the simple things that have inspired and required hundreds of tutorials and hacks to accomplish in "pure" CSS [1].

Of course eventually we were given display:table, but even that was not as good as good-ol-table, because of the child-width-not-expanding-to-fill-parent issue mentioned in the article I linked to.

[1] just as a for example: http://css-tricks.com/centering-in-the-unknown/

Is the concept that abstractions leak so difficult to grasp?

At some point, the abstraction of "separate content and presentation" gets too complicated. Then you need to use a table for something that's not data (ohhh, the horror!) or spend a weekend trying to do with CSS what a table can do instantly and simply.

Reply on news.ycombinator.com