These are very real problems with current web technologies but Adobe's solutions seem a little strange. Content flow and region styling are both something that should be made easy to do in html and would make it easier to design great looking websites. But, the syntax they propose is weird. They put all the text in one div that is presumably hidden by default before being inserted into other divs that you leave empty in your source.
I feel like some sort of pure CSS solution would be better than requiring empty divs in the HTML, this further mixes content and presentation. (not that HTML/CSS does a perfect job of maintaining that separation at the moment, but I believe this proposal would be quite a departure.)
For what it's worth, we're actively discussing this proposal in the CSS WG. There are several of us who would prefer an approach (anonymous ::slot pseudos or some such) which would allow for Zen Garden-like change of region styling without requiring the content to change.
I think it's an interesting solution. I think that CSS-only styling would be more difficult thanks to a lack of regions. This is more an "automated" way to get the browser to lay out the text within your content DIVs.
The good thing is, you can craft a layout and put in some placeholders that get filled with your content. The bad thing is, you probably could have done this yourself by hand rather than by using a CSS extension. The ugly thing is waiting for full browser support (border-radius STILL requires -webkit and -moz!) for these solutions.
If all you want is region layout, try http://robinmessage.github.com/regionjs/ I didn't follow the CSS format of the Adobe proposal, but that code will layout columns nicely.
By knowing the content you could style the regions of each page individually. This would, however, require something like a <style> element on the page to customize the regions or a stylesheet per page.
Or by javascript. But I see this as a more challenging approach than CSS. (Breaking a paragraph across 2 DIV elements would be a challenge.
I can see what you mean, but I can also see why Adobe chose this path. A pure CSS solution may offer the ability to simply define an array of boxes for the content to flow through. On the other hand the css box model requires html elements in the hierarchy to attach to, in order to manage the cascading aspect of css.
I agree, it is a sticky problem. Really, it does make sense to have the content areas defined by divs (though what to do if one of them ends up empty?) And once you've done that, where is the content supposed to go? I suppose then it makes sense for it to be in a separate hidden div... What happens to styles put on that div? Will the content div be represented in the DOM? I feel like it makes for some sticky questions.
Before this proposal, you might have attempted to implement these features server side; deciding what parts of which text should end up in each div. It's just unclear to me that having this hidden div is the best way to bring your text up to the browser.
Still, if by using that, you're implying a pseudo class or something like #container:first-column and so on, there's risk of having a mismatch with regards to the number of columns defined on the parent.
Am I the only one that doesn't want two column layout to come back, especially on tablets? Two column layout is a relic of a single page layout -- something that seems a bit pointless when you no longer need to be constrained by the page.
I'm not sure what you mean by saying that "Two column layout is a relic of a single page layout". Columns have a long history (newspapers come to mind) that does not seem to be tied to single page layout.
The most important thing that columns preserve is readable line lengths. If you want to maintain good, readable line lengths on the web, you are going to end up with a relatively thin column and a lot of scrolling. Multiple columns allow us to more efficiently use the visible on screen space while maintaining readability. That seems pretty valuable to me.
Agreed. The column and optimal line length conventions of print weren't arrived at through whimsy, but rather a centuries of experimentation in improving readability. Obviously screen is a very different medium, with it's own unique considerations but optimal line length is just as important a readability issue as ever.
> The most important thing that columns preserve is readable line lengths.
A single column can give you that.
Multiple columns seem to me to be fundamentally incompatible with (vertical) scrolling. Yes, they make perfect sense when your pages are fixed-size, and the entire page is visible at once, but when you have a single page of potentially unlimited height, where do you break one column and go on to the next?
A possible solution implementable by a client:
Have the second column be position: fixed; until you scroll to the end of the 1st column - only then start scrolling the 2nd column (and so on to the 3rd column).
I find multiple columns in pdfs very annoying to read as you have to scroll down to the bottom of the page, then back up to start the 2nd column, then scroll down to reach the end of the 2nd column.
I believe scrolling is not ideal. You van break your text on viewport-height and then put as many columns on the screen as possible. This drastically reduces the amount of scrolling required.
I've tried that but it comes out feeling kind of weird. Also, most people don't have a pointing device that allows for horizontal scrolling. But it is totally workable.
This is definitely more ambitious, but basic multi-column text flow is already defined in the multi-column layout module: http://www.w3.org/TR/css3-multicol/
CSS columns as defined by that module have been supported by Firefox and WebKit for some time.
I feel like some sort of pure CSS solution would be better than requiring empty divs in the HTML, this further mixes content and presentation. (not that HTML/CSS does a perfect job of maintaining that separation at the moment, but I believe this proposal would be quite a departure.)