Håkon Wium Lie is the father of CSS, the CTO of Opera, and a pioneer advocate for web standards. Earlier this year, we published his blog post, “CSS Regions Considered Harmful.” When Håkon speaks, whether we always agree or not, we listen. Today, Håkon introduces CSS Figures and argues their case.
Tablets and mobile devices require us to rethink web design. Moused scrollbars will be replaced by paged gestures, and figures will float in multi-column layouts. Can this be expressed in CSS?
Paged designs, floating figures, and multi-column layout are widely used on mobile devices today. For some examples, see Flipboard, the Our Choice ebook, or Facebook Paper. These are all native apps. If we want the web to win on these devices (we do), it’s vital that designers can build these kinds of presentations using web standards. If web standards cannot express this, authors will be justified in making native apps.
Over the past years, I’ve been editing two specifications that, when combined, provide this kind of functionality: CSS Multi-column Layout and CSS Figures. I believe they are important to make sure the web remains a compelling environment for content providers.
In this article, I will demonstrate how simple it is to write CSS code with these specs. I will do so through 10 one-liners. Real stylesheets will be slightly longer, but still compact, readable, and reusable. Here are some screenshots to give you a visual indication of what we are aiming for:
Building a page
The starting point for my code examples is an article with a title, text, and some images. In a traditional browser, the article will be shown in one column, with a scrollbar on the right. Using CSS Multi-column Layout, you can give the article two columns instead of one:
article { columns: 2 }
That’s a powerful one-liner, but we can do better; we can make the number of columns depend on the available space, so that a narrow screen will have one column, a wider screen will have two columns, etc. This is all it takes to specify that the optimal line length is 15em and for the number of columns to be calculated accordingly:
article { columns: 15em }
To me, this is where CSS code morphs into poetry: one succinct line of code scales from the narrowest phone to the widest TV, from the small print to text for the visually impaired. There is no JavaScript, media queries, or expensive authoring tool involved. There is simply one highly responsive line of code. That line is used to great effect to produce the screenshots above. And it works in current browsers (which is not yet the case for the following examples).
The screenshots above show paged presentations, as opposed to scrolled presentations. This is easily expressed with:
article { overflow: paged-x }
The above code says that the article should be laid out as pages, stacked along the x-axis (which, in English, is toward the right). Browsers that support this feature must provide an interface for navigating in these pages. For example, the user may reach the next page by making a swiping gesture or tilting the device. A visual indication of which page you are reading may also be provided, just like scrollbars provide a visual indication in scrolled environments. On a tablet or mobile phone, swiping to the next page or document will be easier than scrolling.
Images
Adding images to the article creates some challenges. Lines of text can easily be poured into several columns, but if figures are interspersed with text, the result will be uneven; because images are unbreakable, they will cause unused whitespace if they appear at a column break. To avoid this, traditional paper-based layouts place images at the top or bottom of columns, thereby allowing other text to fill the whitespace. This can naturally be expressed in CSS by adding top and bottom to the float property. For example:
img { float: bottom }
The bluish harbor images in the screenshots above have been floated to the bottom of the page with this one-liner. CSS is used to express something that HTML cannot say; it is impossible to know how much textual content will fit on a screen in advance of formatting. Therefore, an author cannot know where to insert the image in the source code in order for it to appear at the bottom of the column. Being able to float figures to the top and bottom (in addition to the already existing left and right) is a natural extension to the float property.
Spanning columns
Another trick from traditional layout is for figures to span several columns. Consider this newspaper clipping:
In the newspaper article, the image on the left spans two columns and is floated to the bottom of the columns. The code to achieve this in CSS is simple:
figure { float: bottom; column-span: 2 }
HTML5’s figure element is perfect for holding both an image and the caption underneath it:
<figure>
<img src=cats.jpg>
<figcaption>Isabel loves the fluffy felines</figcaption>
</figure>
The newspaper article also has a figure that spans three columns, and is floated to the top right corner. In a previous version of the CSS Figures specification, this was achieved by setting float: top-corner. However, after discussions with implementers, it became clear that they were able to float content to more places than just corners. Therefore, CSS Figures introduces new properties to express that content should be deferred to a later column, page, or line.
Deferring figures
To represent that the cat picture in the newspaper clipping should be placed at the top of the last column, spanning three columns, this code can be used:
figure { float: top; float-defer-column: last; column-span: 3 }
This code is slightly less intuitive (compared to the abandoned top-corner keyword), but it opens up a range of options. For example, you can float an element to the second column:
.byline { float: top; float-defer-column: 1 }
The above code defers the byline, “By Collette Jackson”, by one. That is, if the byline would naturally appear in the first column, it will instead appear in the second column (as is the case in the newspaper clipping). For this to work with HTML code, it is necessary for the byline to appear early in the article. For example, like this:
<article> <h1>New rescue center pampers Persians</h1> <p class=byline>By Collette Jackson</p> ... </article>
Deferring ads
Advertisements are another type of content which is best declared early in the source code and deferred for later presentation. Here’s some sample HTML code:
<article> <aside id=ad1 src=ad1.png> <aside id=ad2 src=ad2.png> <h1>New rescue center pampers Persians</h1> </article>
And here is the corresponding CSS code, with a one-liner for each advertisement:
#ad1 { float-defer-page: 1 }
#ad2 { float-defer-page: 3 }
As a result of this code, the ads would appear on page two and four. Again, this is impossible to achieve by placing ads inside the text flow, because page breaks will appear in different places on different devices.
I think both readers and advertisers will like a more page-oriented web. In paper magazines, ads rarely bother anyone. Likewise, I think ads will be less intrusive in paged, rather than scrolled, media.
Deferring pull quotes
The final example of content that can be deferred is pull quotes. A pull quote is a quote lifted from the article, and presented in larger type at some predetermined place on the page. In this example, the pull quote is shown midway down the second column:
Here’s the CSS code to express this in CSS:
.pullquote#first { float-defer-line: 50% }
Other types of content can also be positioned by deferring lines. For example, a photograph may be put above the fold of a newspaper by deferring a number of lines. This will also work on the foldable screens of the future.
Pull quotes, however, are an interesting use case that deserve some discussion. A pull quote has two functions. First, it presents to the reader an interesting line of text to gain attention. Second, the presentation of the article becomes visually more varied when the body text is broken up by the larger type. Typically, you want one pull quote on every page. On paper, where you know how many pages an article will take up, it is easy to supply the right number of pull quotes. On the web, however, content will be reformatted for all sorts of screens; some readers will see many small pages, other will see fewer larger pages. To ensure that each page has a pull quote, authors must provide a generous supply of pull quotes. Rather than showing the extraneous quotes at the end of the article (which would be a web browser’s instinct), they should be discarded; the content will anyway appear in the main article. This can be achieved with a one-liner:
.pullquote { float-policy: drop-tail }
In prose, the code reads: if the pull quote is at the tail-end of the article, it should not be displayed. The same one-liner would be used to extraneous images at the end of the article; authors will often want to have one image per page, but not more than one.
Exercises
The studious reader may want to consult the CSS Multi-column Layout and CSS Figures specifications. They have more use cases and more knobs to allow designers to describe the ideal presentation of figures on the web.
The easiest way to play with CSS Figures is to download Opera 12.16 and point it to this document, which generated the screenshots in Figure 1. Based on implementation experience, the specifications have changed and not all one-liners presented in this article will work. Also, Prince and AntennaHouse have partial support for CSS Figures—these are batch formatters that output PDF documents.
I’d love to hear from those who like the approach taken in this article, and those who don’t. Do you want this added to browsers? Let me know below, or request if from your favorite browser (Firefox, Chrome, Opera, IE). If you don’t like the features, how would you express the use cases that have been discussed?
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.
That stuff looks promising. But how would I define a new paragraph to be placed on the next column?
As far as I understand this, the text would just pour along all columns? But editors need to be able to determine where to end a column and where to start a new one.
Yes, you can set column breaks before/after elements. It wasn’t showcased in the article, but this will work in several shipping browsers:
p { break-after: column }The spec is here
I have to admit I love the power inherent in such simplicity, especially being device agnostic. Definitely a good spec recommendation assuming it will behave consistently across browsers.
Kudos for the final paragraph – a good argument pro multi-column web layouts.
Still, for app-competitive implementations, devs should be able to style the transitions when switching paged-x pages.
These techniques are really, really cool. I’m a tad skeptical about a “page-oriented web” being inherently superior or preferable, but maybe that’s because I’m young enough to have grown up with scrolling. I really dig the infinite canvas, especially when folks like Vox Media use it so beautifully. That said, yay for choices!
This makes more sense to me than CSS regions and the like…
I enjoyed reading your article on that too.
I have a preference for the infinite canvas as the default assumption on the Web instead of a “page”, though I do see many use cases for a paged approach.
How would some of these features work on an infinite canvas? Let’s say that I have a Web destination that is one screen wide and three screens tall on a device. Would this spec allow me to say that I want a pull quote to be placed on each screen?
@Paolo
Yes, page transition effects are important. I sketched a simple list of keywords here. Are there better ways to specify them?
@Randy
I think scrollbars will be with us for a long time and I’m not trying to eradicate them. But there should be ways to switch into paged designs, too, and the style sheet is the right place to encode this.
As for pullquotes in scrolled environments, I don’t think you need the float-defer-* properties as much as you do in paged environments; in a scrolled enviroment you can insert the pullquote where you’d like to see it (for example, between two paragraphs of your choice). In a paged environment that’s placement tend to be based on position on the screen, so there is more need. However, I could see a use case for saying: place the pullquote two lines above the bottom of the part of the document that is first visible to the reader. So, yes, perhaps.
I like the idea, however I would like to see more flexibility in the positioning of images. Thinking especially of responsive images, I’d like to have an image span 1 column when there’s only 2 columns on-screen (e.g. mobile), 2 columns on an iPad, 4 columns on desktop – devices and widths as examples only.
Do others see a use for this?
@Peter I do see the use, but doesn’t placing the above figure-related rules into media queries achive that for you?
@Håkon this looks a little limited compared to what is achievable right now with JS+CSS 3D transforms/transitions/animations. Couldn’t we get a pseudo selector to do things like
.my-pagedx-content ::page {
transition: all .3s;
}
.my-pagedx-content ::page:not(:visible) {
transform: translate3d(/*whatever*/);
}
I’d like to clarify that Flipboard’s multi-column, magazine article layout has been web based ever since launch in 2010. While the surrounding app itself is native, the part that expresses article layout is rendered in a web view.
While I agree, this is beautifully simple to implement these use-cases I am a bit disappointed about how specific this is. I am much more excited for CSS regions because it enables layouts like this but also solves so many other significant problems we face. These specs solve newspaper style layouts incredibly well but I doubt it will be able to make the leap to more complex magazine style layouts. When considering use cases outside of flowing text this becomes even more limiting. I don’t care for one-liners and would rather see more flexible properties that help us solve our own unique problems. At some point someone is going to want special styling on a column, or a column that breaks and starts again. This isn’t even going into the non-text based use cases for this, I can’t think of any while I can think of a few for regions.
I’m happy to see that this is still being worked on, and I’m excited about being able to use these some time in the future. I’ve found that for text heavy articles, pagination is a lot better than scrolling text, especially on handheld devices.
For wonks who want to keep up with the behind-the-scenes discussions, here’s the CSS Figures – intent to implement discussion: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Tosujr59Akg
Good lord! I nearly fell off my chair — I’m 99% sure I made that newspaper page. I’m a web developer now, and delighted to learn how to do it all over again.
I can certainly see some of the CSS here being useful, but I disagree with the underlying premise that paged layouts are the way things should go. I think looking at the paged layouts of Flipboard, Facebook Paper, etc and saying; “Those are popular, they won, we need to follow their lead” is incorrect. It feels to early still. I don’t think we’ve explored the layout possibilities for these devices enough yet to say there is one true way to go. I’m not sure that we should even be trying to find “the one” way.
@Håkon I’m just speculating based on my personal preference of scrolling layouts, but are you basing this on data about paged vs. scrolling?
I think the CSS shown here would be useful without saying that paged layouts are the way the Web should go on mobile devices. Why limit ourselves?
Nice article – thanks Håkon, it’s really good to add some new CSS knowledge to my repertoire!
I would love to see this implemented! It is great for mobile, but also better for long-form reading on wider devices. This allows you to put a bunch of words on the screen read for a few minutes, swipe/click once and have a whole new page.
Current scroll-based reading involves lots of wasted space in margins and larger text and leading to keep line-length readable, and then a lot of little scrolls, which can induce carpal tunnel. Even if you try to scroll once per “page” it is difficult to put the end of what you just read at the top of the screen.
I grew up on scroll too, but sometimes pages just make more sense.
Wow we went from web is not print to let’s make it identical to print in a few one liners… Down to killing scroll to make way for pages…
@Charles Ying,
Thank you for your clarification and reference. Indeed, it is impressive what can be achieved with JS/DOM/CSS. By exposing them in CSS, we would make it easier for others to achieve the same kind of layouts and performance would also improve, I believe. If web viewers supported the features described in the article, would it make your life simpler? Are there other issues that CSS also should address? (while we’re at it 🙂
@Scott Kellum
I’d be interested to hear more about your use cases — what is it that you’d like to do that cannot be done? There specifications offer more features than the article describes. For example, the CSS Overflow specification describes how to style fragments, so you can style individual columns. Column breaks are here. What are we missing?
@Mike Clark
Good lord, how wonderful to meet you! The newspaper clipping popped up when I searched for “column layout” or something, and I’ve used it in talks since then. Before using it in the article, I contacted the owners of Bristol Observer who were kind to give me permission to reproduce.
You will notice that the screenshots on this page resembles your design even more. (The code examples on that page are slightly out of sync with the spec, though.)
May I ask what kind of tools you used at to typeset the article?
@Peter Bowyer 1
The ‘column-span’ property accepts length values so it should be possible to express what you are asking for. For example, if you say:
img { column-span: 30vw }the image will span a third of the viewport width, rounded up to the nearest integer number of columns. Would that work?
@Tyler Gaw
I’m not trying to eradicate scrollbars from the web, but I’d like to add pages, multicol and floating figures to the repertoire of web designers. The Amazon Kindle App has been downloaded 50M+ times for Android, and Flipboard has been downloaded 100M+ times. So, I believe there is a desire for paged layouts — but not exclusively so.
Thanks for a solid introduction to this stuff Håkon. As a developer who’s proficient in CSS but also spends a lot of time writing JavaScript, I’m interested in how browsers will attempt to optimise repaints and reflows with such complex layouts, particularly with the deferred positioning and vertical float techniques that you mentioned.
Will it be an ‘easy’ (I use that word too lightly, I know) adaptation of how they work with existing floats, or is it too soon to know?
This is a really unique concept but it’s hard to imagine this working for more than a handful of use cases, and I don’t feel comfortable with the idea of using CSS to arbitrarily hide page elements the user has already gone through the trouble of loading along with the DOM based on their position in the document.
Great intro, and examples for better layouts and the CSS that creates them. Consider putting an example image with each idea/code example. Much of the tutorial is below the fold where the image isn’t visible.
@Joseph Gagliardi
You make a fair point: setting ‘float-policy: drop-tail’ may result in downloaded content not being displayed and this seems wasteful. Especially when images (and not merely some textual quotes) are involved.
Browsers today download lots of information that is never displayed. For example, the user may not scroll to the end of a document, but clicks on a link and moves away. One could argue that content should be downloaded only on demand, when the user scolls. Likewise, one could probably delay the downloading of images until it becomes clear that it will actually be displayed.
I believe this use case is important — are there better ways to address it?
@Crash Overdrive
I don’t think we should make the web identical to print. If you look at the Our Choice TED Talk you will see that it’s not like print, but it uses some layout features that are also used in print (like multi-column layout and floating figures). I’d like to add these techniques to the toolboxes of web designers.
@MaxWest
Yes, more images would be good. There are some more here and here.
@Tyler Sticka
I agree that scrolled formats also can be used creatively, and you point to two good examples. The PS4 Review uses some of the features I discuss: multiple columns, pullquotes. I also think it would work well in a paged design.
@Paul Eustice
At Opera, we have implemented many of these features, both in Presto and Webkit, and performance seems fine. I believe that balancing in multiple columns is the biggest cause of concern. My colleague, Morten Stenshorne, gave a talk on how he has implemented this at BlinkOn 2.0 i Zurich in May, and he described a two-pass algorithm which seemed reasonable. He has also been instrumental in working out how the float-defer-* properties works, so I trust they will be amazingly fast 🙂
Love the ideas, but I’m quite uncomfortable with the idea that ads should be listed first in the markup rather than being floated up somehow. This really doesn’t work in the resource limited mobile world, nor in the content scraping of pages (where we want the earliest content to matter, even in the presence of <aside>
Beautiful article. A small demo with each suggestion would make this infinitely more useful, especially to demonstrate the excellent point you make in your last paragraph. My fear with columns is that they won’t render in one column on mobile. Thanks!
Hasn’t the web moved away from paged interfaces in favor of so-called infinite scrolling?
Even if this type of layout is in high demand, it seems the lack of control over placement of figures in relation to textual content would seriously limit the applications of this model. Floating figures to an arbitrary column or page when you have no way to guarantee what portion of your copy will accompany them is a far cry from the absolute precision of the printed page.
@Marc Brooks
I don’t understand why you think listing ads upfront is more demanding than listing them inline? And screen scrapers, how would they be confused by this? If they intercept rendering operations, the ads would not appear until rendered, right? Or, if they read the HTML/CSS code, they would understand that the ads would be deferred, no?
@Brandon Gano
Infinite scrolling is in the toolbox, paged interfaces are not. Which one you prefer is a matter of preference, but I do think paged interfaces often make more sense on mobile devices. Would you scroll through “War and Peace”? 🙂
The column/page that content is floated to with the techniques described is not arbitrary — the style sheet specifies how far the figures may move. If you really need a figure to appear after some line of text, floating figures is not what you want to use. But most figures are not tied to a specific point in the text and they look better when moved to the top or bottom of the page.
@Phoenix Kiula
I agree that demos communicate these concepts better than words. The problem, in this case, is that the features described are not yet implemented. Therefore, writing demos that work in every browser is impossible. However, if you want to play, there are instructions on how to download a browser that renders the sample document. Try resizing the document in it — it renders nicely from wide to narrow, including one-column layout. The first screenshot shows the result.
This is really interesting and very easy to use. This pretty much covers how to replace a native app’s content positioning ability.
It is interesting to know that we got competing properties in web equal to the native implementation. But it got a long way to grow and implement across web platforms.
Håkon, thanks for writing this. Are there plans to allow percentages for column-width and column-gap in Multi-column Layout? The 2001 version of the working draft included them, and using percentages seems the most optimal to me for fine and durable control of responsive layouts.
Great artcle. This is usually a print issue but will there be a way to handle widows/orphans without getting spacy paragraphs and balance problems? I could also see this being an issue with users defined font sizes.
@陳 Jon Tan
I think percentage values make sense, and I don’t remember why they were removed. It has also been requested by others. However, because implementations do not support percentage values, I don’t expect percentage values going into the current CSS multicol specification.
@Håkon Wium Lie
I think this all solves a very specific problem very well. I used to work at Treesaver where we implemented something nearly identical to this. But what if I want to vertically center a figure within a column? What if I want that figure to float half-way into two columns? What if I want another piece of content like an aside or ad between two vertical fragments? What if I want a figure to hang outside the column box? I have been following this spec with lots of excitement over the years and am excited to see some of the fragment stuff here. More recently I get really excited about regions because it just handles overflowing content and leaves layout to flexbox, grid layout, or classic floats giving me control over whatever edge-case I might run into. Are there any use cases for columns outside of formatting articles?
I like this spec and I always like to see more cool features in CSS but by writing a scathing article on regions and then one promoting a spec that handles one of the use cases for regions well I felt I had to speak up. It seems as if you are trying to offer an alternative for regions with this article but failed to provide solutions to a few of my issues with article layout and all of my layout issues regarding navigation and module flow that regions solves. Ultimately I would like both columns and regions as they solve slightly different problems, but if I were to pick one it would be regions every time.
Hello Scott,
Thanks for providing use cases. Let’s see.
(1) To vertically center a figure within a column, you would write:
figure { float: top; float-defer-line: 50% }The first rule turns the element into a page float and moves it to the top of the column. The second rule pushes it halfways down the column
(2) To make a figure float half-way into two columns, you would write:
figure { float: top left; float-defer-line: 2; float-offset: 50% }The first rule floats the element to the top left, thereby giving it a direction along the line axis (left). The second rule pushes it down two lines. The third rule floats it in the opposite direction of where the ‘float’ property floated it — i.e. to the right.
It’s a good use case — I’ve added it as an example in the CSS Figures specification.
It would be interesting to see how you would express the same layouts using CSS Regions?
I’m not sure I understand your third use case. Could you point to a drawing, perhaps?
@Dekan
The ‘widows’ and ‘orphans’ properties, as defined in CSS 2 should be honored, even in paged/multicol environments. I often find that I set them both to “1” to ensure that all columns have the same height.
We will also need baseline grids to ensure that columns are balanced. This will avoid that a headline or figures upsets the rhythm of lines on a page.
Do these address your issues or do you see other needs?
@Aries Brune Tyson A
Yes, building interoperability takes time and patience. At some point, around 1999 perhaps, most people only saw fractured CSS implementations. However, there was an active community of designers and hackers who saw the goodness of open specifications and interoperable implementations. Zeldman was amongst them. And as the new millenium arrives, CSS gradually became usable for real web sites.
CSS FIgures have been used to create real books on paper. That’s good. But it’s far more important that we can use this functionality to create great onscreen user experiences. Then designers don’t have to make native apps or resort to complex scripting to use pages and columns on the web.
Just being able to float elements vertically will be incredibly powerful. With the added control it is going to be a renaissance for good old float. 🙂
@Håkon Wium Lie
Thanks for the responses. I have more thoughts but comments are probably not the right format.
@Håkon Wium Lie
Thanks for the great article! I’ve been eagerly watching the development of flexbox, columns, figures and shapes to complement what I’ve already spent a lot of time on: using web fonts well (performance, proportion, OpenType) in the context of responsive design. What I think is important however is to not ignore the context of figures in relation to the content itself. While I agree some flexibility is great in fitting a figure to a place in the layout, sometimes it’s important that it stay closer to the content to which it’s related. That can complicate the placement of these elements within the structure of the content itself. (though for ad placement I think it’s brilliant)
One interesting tweak that would work equally well in vertical scrolling layouts (like on a phone) would be deferring by percentage of the content itself: so rather than deferring by columns on a larger layout breakpoint (like a tablet) you might defer ads by percentage of the whole content (so they would be roughly spaced x% of the way through the article as you scroll downward through it)
Cheers,
Jason
@Håkon Wium Lie
It was back in, ooh, 2004/5? We were the last title in the building, which also housed two bigger newspapers, to work on Quark Xpress running on Macs. I’d arrived a few months earlier as the chief sub-editor at the Bristol Observer and set about getting the team trained up on thinking more rigorously about how they laid stuff out, and using some basic maths instead of the mark one eyeball to get it done. We needed to be able to push out a lot of neat-looking pages very quickly, so one of the first things I did was to introduce a strict horizontal and vertical grid to give us some structure. I wonder if having everything locked to the baseline grid might be what (subconsciously) caught your eye?
As you might imagine, I get on really well with CSS 🙂
And I’m absolutely delighted that you’re using this article in your talks and demonstrations; it’s a professional compliment of the highest order!
@Brandon Gano Infinite scrolling seems to me to have one very large issue; people don’t scroll infinitely.
It seems to me content, regardless of the medium of presentation, should have context. With infinite scrolling you’re breaking or modifying the context of your content to suit the presentation method. Paged results means there are finite and knowable expectations for your audience, natural places for them to break off and disengage. Without those, you’re depending on their attention span and available time. I’d be much less likely to abandon a 7 page article at page 5 (I’m almost done) than after 5 pages of an unknown quantity.
If your content truly is infinite (or close enough to pass), then I think there’s a discoverability issue that a scrollbar isn’t well equipped to handle.
What’s the support of “float: top”?
@Kevin Mack
There are four implemenations of ‘float: top’: Opera 12.16, Prince, AntennaHouse, and an unreleased implementation in Webkit (done by Opera). Opera 10.16 is freely available and you can get test/evaluation versions of Prince and AntennaHouse
@Jason Pamental
I agree that text and figures sometimes need to be presented in strict order. This we can do already — it’s how
and![]()
tags work today. We can also float images sideways (with ‘float: left/right’). However, in paged environments, we also want to float things to the top and bottom to make better use of the available space.
I believe the use case you describe is already supported by the specification. If you say ‘float: top; float-defer-line: 50%’, the figure will end up halfway down the column. Is this what you’d like?
@Mike Clark
That’s a great story, thanks for telling it. The article was published on 26 May 2004 — the full clipping is here
@Henrik Helmers
Thanks for your support. Floats have had rough days due to uneven implementations and interaction with margin collapsing. However, they are very powerful and pleasant to the eye when used — and implemented — correctly.
@Håkon Wium Lie
Great article Håkon! You made one statement that left me scratching my head:
“Likewise, I think ads will be less intrusive in paged, rather than scrolled, media.”
I’ve read various sports related articles that force visitors to click through 16 pages to read an entire article. Often times, the advertisements are on every fifth page or so and they take up the whole page. The ads in this paged scenario are much more intrusive to me! This is also a really bad use of pagination in my opinion.
Can you elaborate on your belief that ads will be less intrusive in paged media?
I love these CSS tricks and will definitely play with them next time I work on our internal newsletter. However I do have some questions about the deferring and pullquote techniques.
How will assistive technology devices such as screen readers interpret the code? Typically, they read from the document and ignore the presentation layer. Using the examples above, does this mean a screen reader would be front loaded with all of the ads and pullquotes?
And when a user tabs on their keyboard through a document, will they have to go through all of the ads first? Should developers include links to skip each of these?
Hi Håkon,
This is all great and I already have several use cases where I would use all these properties. Unfortunately, the columns property alone shows some severe problems even with the most basic setup:
if a column breaks between ‘p’, you may end up with the margin-bottom of the ‘p’ at the top of the next column (ugly).
If a column breaks after a heading, you got the ‘h’ at the bottom and the related text at the top of the next column (confusing).
Images in the flow may be sliced and spread across columns.
Getting a two columns layout vertically balanced is a chance game.
Those are the first things that pops when I remember my trials.
Can we expect improvements on this side?
And how? More sophisticated UA rendering? More css properties?
Thanks for this great article.
For someone who knows only the basics of CSS, this was a great read. As others have commented, having such power in such simple statements is fantastic, and the flexibility across devices and browsers is surely what the web needs to move towards. A great read, thank you!