A List Apart

51 Reader Comments

I’m planning on a longer response a bit later, but I want to start with this question: do you consider Web Components harmful? It seems to me that many of your arguments against Regions also apply to Web Components.

Most of your arguments look to be just about samples that do not make correct use of the css-regions properties. Those are not real websites or real layouts, it’s just some engineer showing a property works. We all agree most engineers suck at UI, right?

For example, when you say the regions-sizes-and-divisions cannot be made dependent on the actual content, it’s false; you can decide to have auto-sized regions and prevent from breaking somewhere using the “break-inside: avoid”, as well as forcing a break anywhere using “break-after: /*to next*/ region” and “break-before: /*to next*/ region”.

You can also make the number of regions and their layout vary with media queries, it’s inaccurate to say anything else. When the number of regions isn’t known in advance it -means- that you can generate the region anchors using “overflow: fragments” already.

That being said, I’ve to agree people at Adobe tend to overuse CSS Regions in places where CSS Regions do not belong, and where multicolumns and exclusion would do a better job. This is a fact, but this is normal, everyone will consider its “specification babies” before considering alternatives.

Yet there are a very broad range of valid use cases that no other combination of CSS Specifications and Proposals can solve without a named flow concept, even your very own proposals.

I agree with the major points of your article. From this perspective, it makes CSS regions feel like they are a big step backwards in the battle to separate presentation and content and some of it seems eerily similar to the pre-div era.

I’m curious though, what are the major advantages to CSS regions? This article seems to focus on one specific area where it seems obvious that another tool such as multi-column could do a better job. I appreciate that this article is able to layout some big concerns but I don’t know many designers or developers who are using well-written, concern-separated, code who would jump on the region bandwagon if it really does add so many lines of code to our stylesheets and break responsive layouts.

I feel that there is some story not being told here about the CSS regions - perhaps there is a more proper way to use them?

I love the Multi-Column Layout proposal as well, seems simple, clean, and keeps my styles and content out of each other’s way.

Thanks for your comments. Indeed, media queries can be used with CSS Regions—I refer to this when saying: “If one were to support one layout on small screens, and more columns on wider screens, the code size for using CSS Regions would grow quickly.”

It’s also true that regions breaks can be set. Do you think this solves the problems? I challenge you to write a compelling CSS Regions example that addresses the problems that I pointed out!

I think your article is a fine summary of the arguments you’ve made on the www-style list about CSS Regions over the past few years. It may surprise you that we have been listening and have made changes to CSS Regions based on your feedback (though I have mentioned this before). Some of your points above aren’t quite current, as the proposal has evolved along the way. I think the main point is #1 - all the rest are either inaccurate or the problem really points back to #1.

On Problem #2, you seem unaware that we’ve been talking about responsive layout with CSS Regions ever since Chris Coyier found a neat way of combining quite different desktop and mobile layouts in the same markup. Razvan Caliman has shown quite a fewexamples of responsive UI using Regions as well. Regions can be used extremely well in responsive layouts. I agree that a standard multicolumn layout is still best done with multicolumn, though.

On Problem #3, you made that point quite a while back, and I made changes to the example to address your concern about ten months ago. Region 3 is tall enough so that you never see Regions 2 and 4 on the same screen (the layout adapts to screen size). But as François notes, this is an engineer’s example. I’m no designer :)

On Problem #4, we’ve gone back and forth over code examples quite a lot. There are some who find float layout intuitive and simple (including the extensions to floats that you’re proposing) and others who have moved on from float layout to Flexbox and who are hotly anticipating Grid Layout. CSS Regions is built to take advantage of any layout system we devise for CSS. There are really just two properties to keep in mind, expressing *what* (flow-into) goes *where* (flow-from).

On Problem #5, you’re critiquing a tutorial layout meant to introduce the concepts of named flows. I think Mike is a great technical writer, but he may be even less of a designer than I am. I’d much rather see your critique of CSS Regions designs from actual designers. You seem to be unaware that regions can automatically size to fit the named flow content, and that region breaks (or even a separate named flow declaration) can control what goes into a pullquote. All of the examples I linked to above have stylesheets that are completely reusable.

“Problem #2: regions are not responsive” -
Regions are responsive! Designers can use percentage sized regions and define different layouts for their content using media queries, among other techniques. Regions are all about designer control. Naturally, you get responsiveness for free using CSS Multicol because it makes most of the decisions for you. These two features are not at odds. They complement each other nicely. Regions is for complete design control. Multi-column is for quick, simple use cases.

“Problem #3: confusing text flow” -
With great power comes great responsibility. Of course it’s possible to misuse any powerful feature. That doesn’t mean we should keep great power out of the hands of talented designers. Imagine if you told print designers they could only make evenly sized, adjacent columns. Boring!

“Problem #4: verbosity” -
Naturally, CSS Regions are more verbose than CSS Multicol because they are much more expressive, generic, and powerful. CSS Multicol makes most of the decisions for designers, so obviously there isn’t much left for the designer to specify. These features target different audiences. If you need simple columns, definitely use CSS Multicol. If you need a rich, magazine-like design, use CSS Regions.

Let’s look at real-world magazine design. With a quick Google Image Search for “magazine design”, it’s obvious that CSS Multicol is insufficient for almost every layout:
https://www.google.com/search?q=magazine+design&tbm=isch

I’d say CSS Regions covers the 80% of use cases. CSS Multicol covers the 20% of simpler use cases.

Personally, I’m really excited to see real magazine layout coming to the web with CSS Regions. It’s about time!

On #2, indeed, one can provide two different presentations and swap one for another using media queries. That’s a very powerful mechanism. But it leads to verbose code, and I’d argue that it’s better when the mechanism itself scales. Lots of people will use Regions to create multicol layouts, just like the good people at WebPlatform did. I’m happy you see there is a better alternative. What kind of code will Adobe’s tools generate?

On #3, you set the height of the grid to “110vh;”. This makes the grid taller than the screen, which solves some problems, but create others. For example, if you try to reuse that style sheet for a short article, you would end up with white space, no? Is there an implementation that renders your first example as you would like to see it?

On #4, verbosity, you seem to be saying that using Grid or Flexbox will create more compact code? Could you encode the example at hand using your favored technique? I challenge you to write it in three lines :-)

On #5, I don’t think the problem is (nor have I criticized) the design used in WebPlatform’s article. I fear that the problems are much deeper than something that can be fixed by a designer. For example, how would you encode the pullquote example in a way that does not lead to overlapping text or blank areas when the text changes?

It’s fun to code up use cases, including magazine layouts. Could you point me to, say 5, of the images that come up in your search that cannot be encoded in multicol?

As for media queries: yes they can be used to switch between different designs. But many designers will forget that not all have as big screen as they do. And, will the customer pay for web designers to do double work? I fear that many devices will be left in the dark unless we find mechanisms that automatically scale. CSS Multicol layout does this beautifully, CSS Regions do not.

Håkon, on #2, take a look at the examples I linked to. In Razvan’s examples you get very responsive UI capabilities using one CSS Region. This one region is defined by an element, so the solution runs up against your problem #1. I think for these cases the tradeoff between functionality and separation of concerns is worth it.

This is why my initial response was to ask about Web Components. In an HTML Template you can define presentational boxes in markup. This also violates SoC, but again I think the tradeoff is worth the compromise.

I think this post will go down in history as the one that introduced the concepts of Figures to the general dev public. Amazing stuff, I’d never even heard of it. I only wish you had highlighted Figures more in the article, because it addresses many of Regions’ use cases in (what is to my eye) a more elegant, reusable form. I can’t wait for:

http://caniuse.com/css-figures

:)

In practice, I must say I’ve found multicol to be incredibly fiddly and error prone. I love the idea in principle, but there are currently so many glitches, gotchas, and rounding errors that I will continue to avoid it for the foreseeable future for production code. I agree with the basic premise that making multicol better should be as high a priority as regions. It seems to have drifted slightly off the development map, with longstanding bugs stagnating.

From this article, I really like multicol. It seems to be a far more scalable and elegant solution. I only really have one problem with it, and I suspect that it is the one the regions are trying to solve.

Let’s say you have semantic text, a long article or something, but you want to “break up” the monotony of the text with something else. Sometimes that’s necessary (like an aside, or some “useful factoids”), and other times it’s forced (like an ad). Either way, you’re trying to really pull two things apart that are semantically the same and shove in something unrelated precisely because it’s unrelated. On different devices, this unrelated thing may or may not be a good thing to display at a particular place, or at all. This has been a weakness in CSS from the start, and I believe that until that’s addressed, things that hurt the semantic nature of HTML will keep appearing.

It seems that Adobe is pushing features that are (a) so complex you will need an authoring tool to use these features and (b) so unfriendly to style sheet reuse so that you need an authoring tool each time you make a change. It makes sense. For them, not for the rest of us.

There is an overall sentiment here that, whether or not it is justified, using the examples in the CSS Regions proposal is not a good idea. The problem being that it leaves open the question “could someone else write better code using the same CSS specification?” It would’ve been better to write all of your own examples so that it is understood that you are only critiquing the CSS specification instead of critiquing someone’s coding skills.

This article flipped my idea of CSS Regions. I first got into them when I watched a Safari demo at WWDC, but now I’ve lost all of my enthusiasm for that specification.

Hello Sunny, I agree that being able to mix in some semi-related, or unrelated content is useful. The <aside> element in HTML5 can be used for this, and the content of the <aside> element can be moved to other columns and pages using functionality described in CSS Figures. For example, you can say:

aside { float: top: column-span: 2; float-defer-page: 1 }

This will display the <aside> element at the top of the first two columns, one page forward. The specification is still in development, but initial implementations are promising and I hope this will become part of the web. It addresses many of the use cases people try to use CSS Regions for.

Hello Cary, Perhaps it is possible to write better examples for CSS Regions. I wouldn’t know how to do it, but I have challenged those who promote the CSS regions specification to publish better examples that do not exhibit the problems discussed in the article—see my comment to Alan above.

At problem #5, the first thing that the author of the quoted article says right after the image you copied here is “In this case, the region’s height is specified as auto, which makes it expand vertically to accommodate the content that flows into it. This can be useful when designing ‘flexbox’-based layouts in which a more flexible column shrinks to accommodate neighboring content such as the pull-quote.”

Given this, I don’t quite follow the argument about translation, downloadable fonts and magnifiers.

Hello Cataling, it’s true that the size of the region will change to accomodate a longer or shorter pullquote. However, the surrounding regions will not respond to these changes. So, if you put in a longer text, the pullquote will grow and overlap the text that follows. And if you shorten the pullquote, you will have too much white space between the pull quote and the text that follows. So, the style sheet only looks right when you have a pullquote that is exactly three lines long. This makes style sheet reuse impractical.

Håkon, you’re saying that if you use absolute positioning, bad things can happen. That has nothing to do with regions. Regions can be positioned with whatever layout mechanism you want. So to fix the problem you’re perceiving just position the regions using grid, flex, table, float or even static layout.

You said:
“So, if you put in a longer text, the pullquote will grow and overlap the text that follows. And if you shorten the pullquote, you will have too much white space between the pull quote and the text that follows. So, the style sheet only looks right when you have a pullquote that is exactly three lines long. This makes style sheet reuse impractical.”

I’m sorry but didn’t Alan mention the property that prevents that? Here’s a link to an example: http://adobe.github.com/web-platform/samples/css-regions/basic/region-autosize.html
The pull-quote will always stay inside its region.

Also, why would u want to position the layout absolutely?? You can position the regions any way you want, and as one of them re-sizes the others will “move” to fit into the space all the time.

As for the user wanting to scale/zoom the page in without the content of a region overflowing it, that is basic CSS 101: just use relative units to size the regions, instead of pixels, use `em`s, and the regions will scale up as the text does.

Håkon, interesting read. Thank you. I agree with the proposition that regions are not very webby and there are better ways to build layouts. I say this in the context of building a traditional website.

However, I don’t think you are considering every use case.

Regions are very relevant when using CSS to mark up media that needs to be a bit more “strict” in how it should render.

Think about rendering invoices to PDF.

Let’s say you want to render a physical documents by first marking up the content in HTML, styling it with CSS, and then printing that output to PDF.

You need a way to mark the boundaries of each page, where content should end (avoid page breaks, section breaks etc.). You also need a way to let one text flow from one page to another, and maybe a next one. With regions you can be very precise.

Browser technology is used in many other contexts than just websites. Interactive installations in museums, your GPS and the Playstation 4 all use underlying engines like Webkit for their rendering.

Think about an interactive installation in a national history museum. The makers will know that the TV it’s going to be on is 1920x1080. They can be very precise with regions to define how text should flow from one screen to another.

The use cases I describe are different than traditional web use but for me they are a case for CSS regions to exist. Maybe we need a better form to do it (i.e. use CSS3 grid layout do define flow of regions instead of relying on empty HTML divs) but I wouldn’t be so quick to dismiss regions altogether.

Håkon, you’re saying that if you use absolute positioning, bad things can happen. That has nothing to do with regions. Regions can be positioned with whatever layout mechanism you want. So to fix the problem you’re perceiving just position the regions using grid, flex, table, float or even static layout.

When promoting regions, you say: use it with anything you like! And when people do, like the WebPlatform article, you say: this has nothing to do with Regions! Rather than enabling pain and suffering, and then try to distance yourself from it, I’d not enable it in the first place.

You are also saying that just using grids or something will fix all the problems I have described. But in my article, I point out problems with your first example in the specifiation—an example that doesn’t use abspos at all. After having studied the code a bit more, I also realize that the style sheet will leave much white space when applied to short articles. So, even the first example in the specification exposes several of the problems I’m pointing out. With no abspos to blame.

We disagree on the best way to author examples for specifications. The example in the regions spec can be fixed to eliminate the problem you note. But then the example becomes more about creating an adaptive grid layout than the named flow concepts it’s meant to convey. To my mind, there’s already too much grid in the example as it is :)

Hello Alan, if you think the problems reported for the first example in the specification can be fixed, I think you should published a revised version. Not in the spec necessarily—a URL in this forum will also be welcome.

Thank you for publishing a test document—I like seeing code. In the example, your green region on the left behave just like normal elements: they appear in the source order and expand by pushing subsequent elements downwards. That’s good, but you don’t need to use regions to achieve this—normal HTML will do just fine.

What I had hoped to see in your example was a way to do pull-quotes as you think they should be done (as opposed to how the WebPlatform does it). The pull-quote must appear at a certain place in the text (for example, 5em from the top of the column). And when the pull-quote expands, the pull-quote should push other content aside. I know how I would achieve this in multi-column layout:

I agree that we need to think of how we can use web formats outside of browsers. Creating PDF invoices from HTML documents is a good example and one I am familiar with. At YesLogic, we send all our invoices as PDF documents generated from HTML and CSS, using Prince. When doing so, we write CSS code like this:

I don’t think this is just a temporary solution while something better is developed, I think this is a great solution that works here and now. And I don’t see how the markup or resulting code would be improved by CSS Regions.

I’d be interested in seeing how you would use regions to create invoices.

I got involved with Prince when Bert Bos and I wrote a book on CSS. We wanted to see if CSS was good enough for paper-based publishing. We ended up sending a Prince-generated PDF file to the printer. Here’s more about the effortt:

First I want to thank you for your thoughtful answers on every comment in this article.

Prince is exactly what we ended up using in the end to get what we wanted to do (document generation via HTML & CSS, not limited to invoices) working. I am happy to hear that you are involved with Prince this since that leads me to conclude that within Opera you are definitely pushing for better CSS paged media support.

In a 24Ways article last december, I commented on Prince being great, but in essence an expensive (yet worth it for our business case) polyfill for bad paged media support across browsers.

Now how did I get to using regions to print documents? First I tried wkhtmltopdf but the result was pretty bad. Then I tried to “hack” together a way to get the HTML/CSS content correctly on pages using a combination of A4-sized divs, Chrome’s PDF generation (print to PDF) and CSS regions . One of my thoughts was that I could then somehow point the print to PDF function to print one “A4 wrapper div” per page. I went as far as researching how to make custom virtual printers (cups pdf) but with little success since it’s a mysterious and badly documented world. Maybe I just didn’t find the right resources.

When I discovered how much effort I had to expend to make document generation “maybe” work on “one specific server” we were relieved to find Prince and settled on that.

So one might conclude that my use case is pretty exotic/experimental and not grounded in reality. It should be solved by better CSS paged media support in the future i.e. what gets “polyfilled” by Prince should become the native behavior of print/print to PDF.

The other use case then, specific layouts for interactive installations: arguably you can build good layouts using absolute positioning on the page. CSS regions can be helpful in some cases but really in most article/editorial design style cases you should probably use a combination of CSS columns and if it ever gets some traction, CSS grid.

The point of that example (which wasn’t created by me, by the way) was to show that you can make regions more flexible and thus prevent their content from breaking when u don’t want it to break.

The main reason this article is controversial and the main reason you consider Regions harmful is because you are judging them based on a couple of examples that, to be honest, are not really good and that convey a not-so-true image of what Regions are supposed to do.

I believe that you know that CSS Regions are not a layout feature, and so I personally would not expect myself to be capable of using them to create a fully flexible and responsive layout like the one from the Web Platform. CSS Regions are useful when they are used the right way, and the right way does not mean using them to replace any layout feature like Multi-Columns.

I personally use CSS Columns in a lot of places, but sometimes they are just not enough. Sometimes I need more control over fragments of a layout, and Columns do not give me that control, but regions do.

Regions are meant to be used in conjunction with layout features, they are not meant to replace any feature, whether that feature is Multi-Columns or any other layout feature.

I strongly disagree that the Regions specification should be considered harmful based on a couple of examples where Regions may have been misused.

Reading your article makes one believe that Regions are there to compete with Columns, but they are not.

If the example I’m using is not good, it should be possible to improve it, no? I’d rather look at an improved example than hearing, repeatedly, that regions are wonderful. Please show me how pull-quotes should be expressed!

Personally? I would definitely use CSS Figures (if they were implemented) to do this, and not CSS Regions, because using a Region to contain the pull-quote has no benefit, since Regions are meant to change the flow of content, and the pull-quote is not really “flowing” anywhere, so there’s no benefit in defining it inside a Region. So I completely agree with your reasoning for the solution of the above layout, and I’m really intrigued by a lot of properties in the Figures spec, they look very very promising!

With that said, I want to clarify my point. My point is not to completely dismiss CSS Regions altogether because they can’t solve this layout problem. They can’t solve it because, from what I understand now, they are not even meant to solve these problems. They do one thing: change the flow of content across containers, and so using them to *define* a layout is not really the best idea.

I suppose that when CSS Regions are used in conjunction with other layout features such as Grids, for example, then they could prove more useful as a fragmentation tool, not a layout tool?

I have seen some interesting examples of use cases for Regions, and I have even used them in a demo of my own that would otherwise not be possible without CSS Regions, and the level of control they gave me over the layout was really great.

I would change my opinion maybe about where I stand if CSS Figures and Columns would offer the same and better control over a layout.

The layout I was talking about can be found here:
http://sarasoueidan.com/blog/css-regions-with-shapes-for-readability/

Is there a way defined in the CSS Multi-Column spec that allows me to create those three regions/columns with custom shapes like I did?

P.S. This is *not* a challenge!! I’m just a curious web developer, and I’m really interested in knowing if there’s a better way to do this.

It’s fair to say that each spec should be evaluated on its own merits, but to make a good use of CSS Regions, one would need some sort of page template logic to partition pages into regions in the stylesheet and eliminate the need for dummy div elements (scripting could do that as well). EPUB Adaptive Layout spec has declarative features for that. You can see the demo at http://sorotokin.com/adaptive/ (demo files are fully declarative, but the engine is implemented in JavaScript).

The fundamental difference between CSS Regions / Adaptive Layout approach vs. multicol and figures is that the former make a page appearance a primary point of design (partition the page first and pour content in partitions) and the latter rely on page appearance being synthesized automatically (push the content to various places as you go). I think the former approach is a big win from a design point of view, especially for complex designs where visual conflicts are likely to occur and not easy to resolve.

CSS Figures has three implementations:
http://people.opera.com/howcome/2013/tests/figures/coverage.html
The implementations have provided useful feedback and the specification is being developed.
Your example is very artistic! I don’t think I would want multicol layout to be stretched into creating these sort of designs. I’m not even sure it make sense to have the columns reflow—perhaps this part of the spectrum should be left for SVG and other formats where lines are pre-formatted.

So the answer is “No” then, CSS Columns does not give me that kind of control over individual columns.

“Your example is very artistic!”
- it’s one of many use cases for CSS Regions that cannot be provided by Columns. It’s not about whether a design is artistic or not, it’s about the level of control we, developers and designers, can get over our layout. I may want to style each column by giving them different heights and width, for example, and CSS Columns would still not be able to give me that.

“I don’t think I would want multicol layout to be stretched into creating these sort of designs.”
- fair enough! maybe then leave that to CSS Regions? :)

“perhaps this part of the spectrum should be left for SVG and other formats where lines are pre-formatted.”
- OR leave that to CSS Regions. I think that using SVG to create such a simple layout would be a lot more complex than using Regions, at least for someone like me.

I don’t believe this has to be an either-or situation. CSS Regions clearly provide us with a lot more control over fragments of a layout that no other feature does. I’m not saying they should replace Multi-Columns, because, again, this is not an either-or situation. They should both be able to coexist.

I agree problem #1 is the most substantial issue, but think there’s an important trade-off. Yes, the dummy div region markup is presentational & un-semantic, but the <article> source content is not. In the WebPlatform example, the embedded pull-quote content behaves as a logical semantic subset of the article. But perhaps just as often on the web, you see semantically extraneous content such as ads, links to other stories, or “share-this” boxes injected within the content tree to achieve a presentational effect local to some rectangle, typically a float. I once wrote an aggregator that had to distinguish the two cases, so may be a little extra sensitive to the issue. Consider the likelihood that regions may make it easier overall to maintain cleaner semantic content separate from presentation. BTW, I wrote the WebPlatform doc, so found the discussion here a good source of suggestions to improve on it. Alan is right, I’m no designer, but still changed the doc to clarify that absolute positioning is pretty retrograde & hypothetical here. Thanks

One of the things which puzzles me about both figures and regions approaches is whether they support footnotes (and ideally footnote continuations) and side notes (such as section titles in the outside margin. This also doesn’t seem to be covered in the fragmentation manager. Ideally you’d want two linked flows in which text can break in either flow, and where for side notes, they are in different “columns” but aligned with each other and affect each other’s flow breaks.

Am I missing something? What would seem to be needed is a figure “float” property that allows you to specify a target box by name and the ability to say if the depth in the target is aligned with the depth in the source (for side notes) and for footnotes, the ability inset the footnotes in the bottom of the column or multi column area.

Is this out of scope? It seems at least as important as floating figures and it’s possible a well thought out approach might co-ordinate (if not unify) the two approaches.

Footnotes and sidenotes are, indeed, important. The functionality is described in this specification:
http://books.spec.whatwg.org/
The section on named areas (which is what you would use for sidenoted) is fairly new—It would be interesting to hear if it covers your use cases.

I see your point about injected ads etc—we certainly want to keep these away from the text flow itself. In CSS Figures, this is handled by being able to defer a float to a later column or page. So, for example, you can have an <aside> element at the beginning of the article, but delay its presentation until (say) the last column on the second page:

aside {
float: top; /* float me to the top of the column */
float-defer-column: last; /* the last column, that is */
float-defer-page: 1; /* one page after the first */
}

Pull-quotes can also be handled this way—by using the float-offset property it can be pushed down from the top:

blockquote {
float: top; /* float me to the top of the column */
float-offset: 5em; /* push me down 5em in the opposite direction*/
float-defer-column: 1; /* show me in the second column */
}

I didn’t mean to say that columns cannot be combined with exclusions; they certainly can:
http://figures.spec.whatwg.org/#wrapping
However, personally I would not try reproducing your example in columns or any other CSS—I think too much of the message is in your shapes and if your users are on a small screen, it will be hard to convey this important part. So, personally, I’d probably use SVG.

I think your spec and examples are great—you are actually expressing boxes in CSS and I wish that the CSS WG had started out with your design instead of basing it on HTML elements.

I also agree with your high-level characterization of the two approaches. I think the page-oriented approach makes sense when a known-size paper or screen is the target—you can then make efforts to perfect the presentation. I believe the item-oriented approach (to give it a name) makes more sense when you don’t know the size of the output; the formatter can more easily synthesize the presentation to the size of the user’s device.

As an example, when making page templates, you would have different page templates for two-column and three-column designs, no? And then you would have (the option of having) different templates based on whether there was one, two, or three images on the page? The combinatorial explosion quickly kicks in, and only the most resourceful sites will write page templates for all circumstances. The item-oriented approach, however, relies on each item knowing, roughly, where it wants to be no matter what kind of screen it is on. And media queries can be used to cover cases when you want/need an phase change.

Well, in many respects CSS Regions spec is actually a descendant of Adaptive Layout (or more precisely, they are both descendants of something called “PGT”: https://code.google.com/p/epub-revision/source/detail?r=2026 is I think the earliest public spec). Early in CSS Region discussions it was decided that anonymous box creation is a more generic issue and should be handled separately. Unfortunately, not much moved on that issue since then. From the document mark-up design perspective, anonymous box generation on pages is required. However, the truth is, web browsers are not paginated layout engines (or at least they are fairly poor at that), but application engines. Having a facility like CSS Regions helps immensely in building web apps for publishing irrespective of the need for artificial container elements. Web apps would want them anyway, as real elements, unlike anonymous boxes, are scriptable (and this is, I suspect, the reason why there is no sustained interest in anonymous box creation).

Columns in page design: no need for separate templates, Adaptive Layout merely uses CSS Multicolumn, so you just specify the desired column width. You’d only need a separate template if your “columns” are complex shapes (like what Sara’s example has).

Many images/sidebars on a page: while it’s possible to create a single complex template that resolves the conflicts, but that is in general not what a designer would do. A designer (in real world) would actually create a design for page partitioned for each desired permutation. If there is no design where all available content can fit, that content will be deferred for the next page. This is the only sane way to produce complex designs en masse - otherwise too much testing for various screen and font sizes is needed (exactly because of the combinatorial explosion that you mentioned). A complex template may be used in some cases (e.g. for technical manuals, when a lot of documents are expected to use it), but it becomes almost like software and requires skills similar to software engineering.

Again, the single most important point is that the overall page appearance must be a primary object of design, not merely a result of some computation with a multitude of parameters and conflict-resolution rules. In high-end designs found in magazines and textbooks, the conflicts between various page elements cannot be resolved based on a set of rules, because these conflicts are aesthetic, not geometrical in nature.

Hello Peter, I agree with most of your observations. And I’m happy hear that your think muliticol elements can be combined with page templates. The Regions demos I have seen have most often failed to e.g. recompute the number of columns on narrow screens. I’m happy to see that you do this in your demos (referred to in your first message).
As for high-end designs, they will probably be hand-made—or at least hand-adjusted—for the forseeable future. But it’s not realistic that all content is hand-adjusted for all screens—we would probably have to educate more typographers than anything else. It’s important to be able to create scalable, responsive designs in few lines of code. This, I believe, is achieved here:

http://people.opera.com/howcome/2013/10-figures/

Regarding apps vs. documents, I think the app-makers have other goals and priorities, and CSS Regions doesn’t actually solve their real issues.

Thanks for the context about CSS Figures. It looks very enticing, and I hope it offers a way to unify CSS’s many visual models. (The name seems unclear, though, much like calling it “CSS Asides”.) I’m not sure if your example of a deferred float addresses the problem I brought up. Embedding extraneous content within an <article> is un-semantic, regardless of whether it’s declared at the start or if it interrupts the middle. Maybe the solution would be a multi-column wrapper so that the extraneous <aside> content can float somewhere within the layout of a peer <article> element. But that seems to bake in additional semantic layers in order to influence the presentation, whose visual model is strongly biased towards nested rectangles. I see it as part of the same trade-off, where either way presentational artifacts appear within the markup.

In a paper magazine, when a full-page ad interrupts an article, is the ad inside the article, or not? I don’t know if there is a correct answer to the question, and I’m not sure it matters. But, as you suggest, the multicol properties can be set on an ancestor to <article>, for example <body>. And, if you prefer, <article> and <aside class=ad> could be siblings inside the <body> element.

It was interesting to hear how you came to use Prince. A free non-commercial version of Prince is available from www.princexml.com, but the software costs money if you want to use it commercially. Browsers have revenue from searches and such, while HTML-to-PDF-via-CSS batch formatters don’t have that option :-(

Anyway, I hope that browsers will improve their support for paged media. I’ve been pushing for browsers not just to do better printing, but also to paginate web pages on-screen. For example, on tablets it often makes more sense to swipe to the next page instead of trying to control an unruly scrollbar. Rhetorical question: when did you last read a novel with a scrollbar? Opera 12.x has some support for this, you can read more about it here:

You lost my trust right after problem #3 and after re-read the whole article I found it filled with more prejudice than persuasiveness, I would assume you could do better job supporting the “considered harmful” argument, but it did.