A set of CSS features proposed by Adobe that enable sophisticated text layout …

The Web is a powerful publishing platform, but HTML still has some weaknesses as a medium for presenting written content. Browser vendors and other stakeholders are working to remedy those weaknesses by improving the Web's native support for print-quality typography and text layouts.

Adobe is making significant contributions to that effort. A new set of CSS features for advanced text layouts that Adobe developed and proposed for standardization last year are beginning to gain traction. The company's CSS Regions proposal defines a system for creating magazine-style text layouts in Web content.

The feature allows Web developers to specify that a single body of text should flow through certain regions of the page. For example, you could create several div elements in a specific arrangement and have the overflow text fill those consecutively. Another feature proposed by Adobe, called CSS Exclusions, makes it possible to have inline text automatically wrap and flow to conform with a specific shape.

In the months since Adobe introduced those features and proposed them for standardization, they have gained the support of several browser vendors. Adobe discussed the status of the feature in a recent blog post. Preliminary implementations of CSS Regions based on the standard draft are now included in WebKit and Internet Explorer 10. The standard is still a work in progress, but the effort so far is promising.

HTML5 bullets

The growing support for Adobe's CSS Regions proposal caught our eye this week, but there are several other noteworthy items to round out our HTML5 roundup.

Adobe recently had an internal WebKit hackathon, where developers worked to improve the open source HTML rendering engine. A blog entry about the event describes some of their work on features like CSS blending and nth-letter support. They also added several features to WebKit's developer tools.

Firefox 13 landed in the Aurora channel with a number of improvements. The most significant change is that support for SPDY, Google's faster HTTP alternative, is now enabled by default.

Mozilla's Chris Lord wrote a status report about architecture of Firefox Mobile in which he explains how some of the recent changes made to the browser's rendering model have resulted in performance gains.

A new project called True Native allows Cordova (PhoneGap) developers to build native iOS applications with JavaScript or CoffeeScript.

Wait wait, what happened to CSS3 columns (or whatever that feature was called) that was suppose to allow you to do exactly what Adobe is doing with regions? Personally I don't care which one becomes a standard as long as it's done well and does indeed become a standard but I'm just curious what happened to that.

Plain old* CSS hyphenation works much more quickly in webkit + gecko; it's coming in IE10 too. Hyphenator's a good stopgap if you really need an IE solution now, however. Sticking hyphens:auto into your user stylesheet works quite nicely, by the way :-).

Wait wait, what happened to CSS3 columns (or whatever that feature was called) that was suppose to allow you to do exactly what Adobe is doing with regions? Personally I don't care which one becomes a standard as long as it's done well and does indeed become a standard but I'm just curious what happened to that.

That's also coming; but it's much simpler and less capable. I'm guessing they'll both be around; they're probably amenable to implementations with most bits shared and complement each other nicely: columns for simple scenarios; regions for the more complex cases.

There also needs to be better support for auto-generating stuff like a table of contents, section headings, etc. for a document.

There is a conceptual HTML5 table-of-contents algorithm. However, it's implementable in javascript, and as document content structure tends to be fairly static, CSS's dynamic adaptability isn't as necessary.

not sold thats text layout like that is needed for the web. its a nice advantage for paper which has physical boundaries and limits.

While the needs for online documentation are different to physical paper publishing, there's a lot of overlap. I'd like to see a merger of eBook and web standards. That would make things a lot more consistent, and allow common tools that would enable easy porting between online and paper publishing.

Unfortunately, since ebook standards are mostly implemented in low-cost dedicated devices (i.e.: little money for support services), they will always lag behind the web, which can roll out new standards and rely on browsers pushing out free updates to support them relatively quickly. There are millions of Kindles and ePub readers out there that will never see another update (Amazon is actually pretty good, but the last update for the K2 was over a year ago, we won't be seeing another), so they're stuck with what they have. ePub 3 came out 6 months ago and there's still no decent software reader for it even on a PC (there is Azardi, but it's an odd implementation, and iBooks has some support, but it's only partial). Cheap hardware ePub 3 readers are a year away at least.

Even when devices do appear to support it, publishing material that uses a new ebook standard would mean targetting only that sector of the market that's purchased a new device which can handle it, and publishers are having a hard enough time handling the different standards as it is.

Cheap dedicated readers were crucial to developing mass-market acceptance of ebooks, but are also a massive legacy anchor holding back the development of more advanced standards. This will remain true until tablets fall in price enough to supplant them (the Fire and nook are getting there, but still cost more than twice as much as an entry-level eInk reader).

I'm just glad this isn't something Adobe came up with that you'll need to use their specialized (and klunky) tools to develop and a plugin to view. Yes, Adobe, WORK WITH OTHERS to create (and adopt) STANDARDS!

not sold thats text layout like that is needed for the web. its a nice advantage for paper which has physical boundaries and limits.

ebooks/ e-textbooks might have better value there, but i haven't worked in that realm.

do it and you need to work on hyphenation possibilities too as apparent in the image.

Open your eyes and look ! There are websites all over that use multi-column layouts - the only difference currently is that most are using "hacks" to achieve the visual effect. This leaves the code less clean. Looks "pretty" on the front side tho.

emn13 wrote:

Lone Shepherd wrote:

There also needs to be better support for auto-generating stuff like a table of contents, section headings, etc. for a document.

There is a conceptual HTML5 table-of-contents algorithm. However, it's implementable in javascript, and as document content structure tends to be fairly static, CSS's dynamic adaptability isn't as necessary.

Honestly - this is something that would be much better handled thru JS or on the back-end via PHP or .NET or watever floats your boat. ToC becomes more a domain of scripting (read function) than layout and style. Why beat the dead horse trying to do this thru CSS when JS (or alt) would do it so much easier ?

There also needs to be better support for auto-generating stuff like a table of contents, section headings, etc. for a document.

There is a conceptual HTML5 table-of-contents algorithm. However, it's implementable in javascript, and as document content structure tends to be fairly static, CSS's dynamic adaptability isn't as necessary.

Honestly - this is something that would be much better handled thru JS or on the back-end via PHP or .NET or watever floats your boat. ToC becomes more a domain of scripting (read function) than layout and style. Why beat the dead horse trying to do this thru CSS when JS (or alt) would do it so much easier ?

So you agree that a complex CSS extension isn't necessary?

As an aside, obviously there are downsides to a javascript solution: performance; side-effects; needing to worry about timings (when to do the transform), lack of decent html generation/interpretation functionality, performance, poor testability... I could imagine a more limited scripting language would be more ideally suited to this - a kind of friendlier XSLT2 say, but javascript is what we've got.

If this means I can create more interesting websites in Adobe InDesign, I'm thrilled. It certainly looks like that's what they're pushing for. I hate using Dreamweaver. I'd rather have a page layout program that can output multiple formats for different devices/print. I'm not a coder, and the less coding that's necessary, the better.

Wait wait, what happened to CSS3 columns (or whatever that feature was called) that was suppose to allow you to do exactly what Adobe is doing with regions? Personally I don't care which one becomes a standard as long as it's done well and does indeed become a standard but I'm just curious what happened to that.