CSS One-Liners(alistapart.com)
alistapart.com
CSS One-Liners
http://alistapart.com/blog/post/ten-css-one-liners-to-replace-native-apps/
14 comments
I agree that paged layout are both cool and terrifying. Scrolled layout are much simpler for the formatter as there always is more space to use. Splitting content into pages, known as pagination, can be hard when there are unbreakable chunks in the content. In most cases you can split tables nicely (if they are real tables and not typographical devices), but images should never be split.
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.
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.
Are we full cycle yet? Is this the new HTML table layout, it took what, 14 years?
Nothing in CSS can ever be "new HTML table layout."
Is concept of separating content from presentation so difficult to grasp?
What is difficult to grasp is how a technology devoted to "presentation" failed so utterly to provide a decent layout mechanism consistent with its philosophy of separating of content from presentation. The absurdist kicker of this fiasco is that the existing semantic <table>, off limits for use as presentation, actually did the job ok.
[1] http://meyerweb.com/eric/thoughts/2009/02/17/wanted-layout-s...
[1] http://meyerweb.com/eric/thoughts/2009/02/17/wanted-layout-s...
I'm not sure they really "did the job ok", though I suppose it's easy to look back fondly on table layouts with rose-tinted spectacles, no doubt influenced by a decade of messing about with floated layouts.
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).
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).
They could be ugly and complex because of nesting, no doubt, but they at least provided a few fundamental layout concepts missing from CSS: easy vertical centering, and as you mentioned -- columns and rows.
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 [1].
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.
[1] just as a for example: http://css-tricks.com/centering-in-the-unknown/
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 [1].
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.
[1] just as a for example: http://css-tricks.com/centering-in-the-unknown/
Any app will require excess nested boxes to take care of most complex layouts. Plus the element tag names are presentation effecting, despite not being in the style sheet. (Element names are just corresponding to browser native CSS stylesheets) We aren't there yet so don't act all high and mighty pal
Is the concept that abstractions leak so difficult to grasp?
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.
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.
It amazes me a little, and says something about Håkon's perspective, that all of his examples are newspaper pages.
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.
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.
Don't be sad, doing paged layouts is quite an interesting challenge in CSS. Native apps use the routinely and newspapers is just one well-known example. See the spec for more examples. Also, the challenge here is not to replicate newspapers, but to make the content responsive on screens of all sizes.
This was exactly the reaction I had as well. It's demonstrative of someone so hopelessly stuck in the past and unable to the potential of an electronic medium. Wh we continue to anchor web technologies to print idioms is beyond me. I'm not saying there are no classically useful concepts from print. Robert Bringhurst's Elements of Typographic style does a great job of educating one on the value and thinking of techniques from the print world. There are timeless principles that are directly transferrable to the present unchanged, but there are principles whose entire raison d'etre is tied to constraints and properties exclusive of print. Issues that are no longer necessarily applicable on the web.
We obviously have different points of view: I find that the best presentations on mobile devices often borrow more from paged designs than from scrolled designs. As such, I believe that being able to paginate content on dynamic screens is important for the future of CSS and the web.
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.
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.
Is there a reason we should stick with the newspapery multiple-column layouts? My impression is that they are a relic of the printing-presses era of newspapers and are difficult to read anyway (word-breaking is often, it's hard to trace back to previous reading spots compared to scrolling etc). That layout may look familiar on the eye, but that doesn't make it good.
I'm pretty sure we should retain them, although they are not required as often.
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.
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.
Yes, i understand that, however one can constrain the width text of the text so that one doesn't have to , for example, move the head to read from side to side.
However, columns are 2 dimensional, meaning that skimming back and forth between them requires more complex spatial processing than scrolling up-down.
However, columns are 2 dimensional, meaning that skimming back and forth between them requires more complex spatial processing than scrolling up-down.
How is information density important on the web? Scrollable pixels are essentially free, as opposed to paper.
Yes, this can reduce the requirement for density, but it can be really annoying—as I described above—that I end up with a massive screen with loads of white space, having to scroll to view more content that could be comfortably presented.
I've seen this claim a lot, but nobody ever links to the research. Does it exist?
Yep, there's some information and citations here:
http://www.usability.gov/get-involved/blog/2006/08/line-leng...
http://www.usability.gov/get-involved/blog/2006/08/line-leng...
It's trivial to do an experiment yourself, copy a load of text from a wikipedia article into a text file then open it in your browser, full screen. Depending on your display size you'll probably find it hard to read when line width exceeds roughly 90 chars
Personally, I have absolutely no problem reading wide screen text - all I need is about an em of white space on each side. Wish more sites offered that.
There has been studies telling that people tend to read faster with multi-columns [1].
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.
[1] http://graphicdesign.stackexchange.com/questions/3553/why-do...
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.
[1] http://graphicdesign.stackexchange.com/questions/3553/why-do...
Yes.
It is one of the requirements of super speed reading: http://en.wikipedia.org/wiki/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.
It is one of the requirements of super speed reading: http://en.wikipedia.org/wiki/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.
I wonder if this article would still have made it onto the front page if the title was "10 css one-liners to slightly improve the layout of webpages"
The web platform is certainly giving developers more and more control over typography, which is great, but has always been an uphill battle when working with different screen sizes, browser limitations, and well, CSS itself.
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.
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.
That's very cool but I can't help thinking "Why would you want to do that?". Columns are awful to read on a webpage.
The "wrap-contrast" example in the draft Figures spec is pretty astonishing: http://figures.spec.whatwg.org/#wrap-contrast
I wonder how well that would actually work in practice!
I wonder how well that would actually work in practice!
Wrap-contrast is a superb idea. This document is purely a spec though right? The image in the linked page was just a mockup or is there beta code for these features?
You can use shape-outside: <image> in recent builds of Chrome and WebKit to wrap around an image's alpha channel. It only applies to left and right floats - affecting multiple columns is a bit further in the future
http://dev.w3.org/csswg/css-shapes/#shapes-from-image
http://dev.w3.org/csswg/css-shapes/#shapes-from-image
I will keep this in mind. Thanks!
It seems that whenever there is an S followed by a T in the content on that page, they form some kind of curious little symbol. I haven't seen that before, is anyone else seeing that?
Is this some kind of encoding problem on my end?
I don't see it on my end but I'm guessing it is a ligature:
http://en.wikipedia.org/wiki/Typographic_ligature
http://en.wikipedia.org/wiki/Typographic_ligature
I don't see it either, but I do see all the fi's becoming fi ligatures. The CSS is specifically enabling it with the line:
EDIT: Ligatures sure are weird in monospace though. I'd personally disable it for code samples...
http://www.microsoft.com/typography/otspec/featurelist.htm
http://blog.fontdeck.com/post/15777165734/opentype-1
https://developer.mozilla.org/en-US/docs/Web/CSS/font-featur...
font-feature-settings:"liga", "dlig", "onum";
EDIT: Ligatures sure are weird in monospace though. I'd personally disable it for code samples...
http://www.microsoft.com/typography/otspec/featurelist.htm
http://blog.fontdeck.com/post/15777165734/opentype-1
https://developer.mozilla.org/en-US/docs/Web/CSS/font-featur...
Interesting - hopefully these make it into Firefox & Chrome - time will tell, but they seem like they could add value.
Does anyone know of a good book on modern CSS?
I keep seeing new features I was unaware of and would like to find a comprehensive guide.
I keep seeing new features I was unaware of and would like to find a comprehensive guide.
Just in the last few days I started reading through this: http://learn.shayhowe.com/advanced-html-css/
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).
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 looks like there's partial support in other browsers too (I think it's still vendor prefixed). I see columns in Chrome using the example page:
http://www.wiumlie.no/2014/css-figures/koster/prefix.html
It seems like some of the more advanced features like spanning multiple columns hasn't made its way to Chrome yet.
http://www.wiumlie.no/2014/css-figures/koster/prefix.html
It seems like some of the more advanced features like spanning multiple columns hasn't made its way to Chrome yet.
Actually Chrome had most of these features and started removing them again.
"Keep in mind that the feature..Opera"
Thanks, I just quickly skimmed the article stopping at the code samples and didn't catch that.
Thanks, I just quickly skimmed the article stopping at the code samples and didn't catch that.
CSS constantly is moving forward. Reference books are for scrubs when you have the internet.
https://developer.mozilla.org/en-US/docs/Web/CSS
https://developer.mozilla.org/en-US/docs/Web/CSS
Multi-column text on a desktop? Stop. Now. Please.. I's sad to see that more and more websites are phones/tablets orientated and are often hardly usable on a desktop PC. I'm not against a uniformity of the web pages across various devices, but I'm yet to see an acceptable, mature solution.
My screen - like probably a significant portion of screens out there - is wide, 16:10 or 16:9. So without multi-column layout, I have three layout possibilities: Long lines (hard to read), large font (wasting screen real estate) or some form of fixed-width central column with auto margin (also wasting real estate).
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.
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.
Check out Wikipedia, they use multi-column layout nicely for their references.
For the section that isn't actual body copy and isn't for reading as one article?
That's not a good example of where multi-column works "nicely".
That's not a good example of where multi-column works "nicely".
It's a way of using multicol to save screenspace. For Wikipedia references, this works well even in scrolled environments. It would not work so well for body text du to columns then being longer than the height of the screen. For longer articles, pagination is required.
> There is no [...] media queries [...] involved. There is simply one highly responsive line of code.
The Koster archipelago example must be using media queries or am I missing something?
The Koster archipelago example must be using media queries or am I missing something?
> 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
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.
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.
Wouldn't this leave a bunch of white space on one side if the screen width is not an exact multiple of that size? That doesn't seem like a good solution to me.
The browser could distribute the white space between columns to avoid this.
Yes, that's how the spec is written: the style sheet specifies an optimal line length, but it will be adjusted somewhat to fill the whitespace.
No media queries are used, the HTML/CSS source of the document is linked to further down in the article.
Alt title: CSS One-Liners (That Only Work In Opera)
Bad article title.
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.