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.
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.
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).
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 .
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.
 just as a for example: http://css-tricks.com/centering-in-the-unknown/
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.
This looks like the makings of a high quality spec from 2004. Granted, CSS should natively support responsive columns, but it's a solved problem. Does he really think that Figure support is what limits web from competing with native? The problem with presentation of web apps has always been that we use a language designed for describing newspaper layouts to structure a dynamic, morphing interface. And its creator wants more succinct descriptors for recreating the above-the-fold of the New York times at variable widths.
It's almost saddening when the creator of something is no longer the guy driving it forward.
Pages and columns have been basic building blocks in typography since the Romans started cutting scrolls into pages. This is not why browsers should support them. We should do so because they help us make better, more beautiful, user experiences on mobile devices.
The problem is that beyond a certain width it becomes infeasible for the eye to correctly jump back to the start of a line. There's some research on this, but I can't find it at the moment.
Smaller screens obviate the need for this, some of the time. But I've seen a lot of layouts which just compensate using white space - that fits with current design trends, but tends to mean I have a 27-inch monitor with a strip of content down the middle. It looks clean and minimal, but I suspect columnar text will come back into vogue at some point, and offer greater information density.
However, columns are 2 dimensional, meaning that skimming back and forth between them requires more complex spatial processing than scrolling up-down.
I need to find the link, but I saw a study concluding that it is mostly useful if you are a fast-reader. Slow-reader tend to be more at ease with one column. So it might depend on the persons reading.
It is one of the requirements of super speed reading:
Basically you could train your peripheral vision to read too, not just your fovea. You also train your brain to put them in a buffer and make sense of it. Imagine a cone around the point you focus your vision. Instead of just one word you could read 20 or 30 at the same time. Your brain makes sense of it very fast(with short lines).
Your brain could read multiple lines at the same time and make sense of it, because it is ordered. With long lines the words under another word have no relationship at all, so the buffer has to be enormous, in practice you can't read multiple lines at the same time if they are long.
I could read super fast only(eight times faster than everybody else) if the content is formatted.
For me is so frustrating I created my own tools just for reading.
This has been know for a long time, in the typographers and designers world, formats like pdf have used this since their inception.
But programmers are a different beast. Web pages were functional but ugly and only now they are getting the functionality of pdf-latex twenty years ago.
The float property was one of the most confusing CSS properties before "CSS Figures". This article introduces lots of new and strange (...float-policy?) properties and lots to learn, that's for sure.
I wonder how well that would actually work in practice!
font-feature-settings:"liga", "dlig", "onum";
EDIT: Ligatures sure are weird in monospace though. I'd personally disable it for code samples...
I keep seeing new features I was unaware of and would like to find a comprehensive guide.
Edit: Keep in mind that the features discussed in the parent link are not usable today beyond Opera (of which the author is the company's CTO).
It seems like some of the more advanced features like spanning multiple columns hasn't made its way to Chrome yet.
Thanks, I just quickly skimmed the article stopping at the code samples and didn't catch that.
With multi-column text layout I (think I) read faster. It is much easier for me to remember where on the screen a certain passage was in case I have the desire to re-read at a later point in the text (say, because I am not sure if I understood correctly). Plus, for long texts it is much easier to jump to an earlier part of the text when it is still visible than to scroll back.
So I wouldn't flat-out refuse that Good may come of this. I don't see the application of multi-column text on a phone screen given its size but tablets seem to have reached sufficient size and resolution. Multi-column text still breaks the way I usually read on the web, but I feel it might be worth getting used to.
That's not a good example of where multi-column works "nicely".
The Koster archipelago example must be using media queries or am I missing something?
It looks like the columns property can take a size value, which the browser will use to work out how many columns it can fit.