
CSS One-Liners - Brajeshwar
http://alistapart.com/blog/post/ten-css-one-liners-to-replace-native-apps/
======
adrusi
Adding the concept of paged layout to CSS is both cool and terrifying.
Separating content into pages is a very powerful ability that I can see being
quite useful, but it also adds a lot of complexity.

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.

~~~
robmcm
Are we full cycle yet? Is this the new HTML table layout, it took what, 14
years?

~~~
rimantas
Nothing in CSS can ever be "new HTML table layout." Is concept of separating
content from presentation so difficult to grasp?

~~~
jonahx
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...](http://meyerweb.com/eric/thoughts/2009/02/17/wanted-layout-
system/)

~~~
bshimmin
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).

~~~
jonahx
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/](http://css-tricks.com/centering-in-the-unknown/)

------
j4pe
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.

~~~
malandrew
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.

~~~
haakon-wium-lie
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.

------
return0
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.

~~~
matthewmacleod
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.

~~~
jahewson
I've seen this claim a lot, but nobody _ever_ links to the research. Does it
exist?

~~~
phpnode
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

~~~
thrill
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.

------
chrisdevereux
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"

------
bennettfeely
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.

------
not_a_test_user
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.

------
bshimmin
The "wrap-contrast" example in the draft Figures spec is pretty astonishing:
[http://figures.spec.whatwg.org/#wrap-
contrast](http://figures.spec.whatwg.org/#wrap-contrast)

I wonder how well that would actually work in practice!

~~~
goldenkey
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?

~~~
alanstearns
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)

~~~
goldenkey
I will keep this in mind. Thanks!

------
click170
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?

~~~
radq
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)

~~~
XaspR8d
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:

    
    
        font-feature-settings:"liga", "dlig", "onum";
    

(and its vendor variants) _liga_ is standard ligatures, _dlig_ is the
"discretionary" ligatures (less standard ones like ct), and _onum_ is old-
style numerals.

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://www.microsoft.com/typography/otspec/featurelist.htm)

[http://blog.fontdeck.com/post/15777165734/opentype-1](http://blog.fontdeck.com/post/15777165734/opentype-1)

[https://developer.mozilla.org/en-US/docs/Web/CSS/font-
featur...](https://developer.mozilla.org/en-US/docs/Web/CSS/font-feature-
settings)

------
ChrisAntaki
Interesting - hopefully these make it into Firefox & Chrome - time will tell,
but they seem like they could add value.

------
jqm
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.

~~~
ics
Just in the last few days I started reading through this:
[http://learn.shayhowe.com/advanced-html-
css/](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).

~~~
drifkin
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](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.

~~~
kuschku
Actually Chrome had most of these features and started removing them again.

------
kbart
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.

~~~
haakon-wium-lie
Check out Wikipedia, they use multi-column layout nicely for their references.

~~~
jmreid
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".

~~~
haakon-wium-lie
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.

------
Kiro
> 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?

~~~
Bockit
> 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.

~~~
RussianCow
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.

~~~
iSnow
The browser could distribute the white space between columns to avoid this.

~~~
haakon-wium-lie
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.

------
jeffehobbs
Alt title: CSS One-Liners (That Only Work In Opera)

------
hawleyal
Bad article title.

