
CSS is unnecessary given a layout language - mrkibo
http://pchiusano.github.io/2014-07-02/css-is-unnecessary.html
======
ender7
Graphical layout is one of the most underestimated challenges in computer
science. Programmers instinctively look at the problem and thing "oh, this is
logical, I'll just whip up some basic principles and layout primitives and
I'll have this solved in no time!"

No, you won't. Designing a layout framework is really, _really_ hard.
Designing one that is simultaneously expressive enough to handle all of the
crazy corner cases that pop up on a daily basis AND simple enough to allow
"normal people" to actually use and extend it is quite difficult. For example,
the Android layout system is suitably expressive but totally mystifying to
anyone who hasn't spent a year reading the source for
View/ViewGroup/FrameLayout/ViewRootImpl.

The OP's suggestion that there is some singular, beautiful, composable layout
system that we could drop in to replace CSS is, frankly, a pipe dream. Or
rather, I would be far more convinced if he actually pointed to a spec or pre-
existing system that we might base our new system off of [1].

I see only three real possibilities going forward, in order of increasing
likelihood:

1\. Someone does indeed come up with the One True Layout System (very
unlikely).

2\. We finally shove bytecode-level runtimes into a browser and let a thousand
flowers bloom (even odds).

3\. We keep incrementally improving CSS, adding support for various layout
relationships that people need (probably).

[1] Elm's system looks neat, but it's not there yet.

~~~
yawaramin
1\. Someone _has_ come up with the One True Layout System. It's just that most
people like to pretend TeX doesn't exist or, when they grok the box-and-glue
layout model, try to reinvent it from scratch.

~~~
Everlag
Someone yell at me if I'm wrong, but isn't TeX designed for paged content?

That means while TeX might work amazingly for paginated content, single page
apps, or really any non-paginated content, is very much a screwdriver where a
hammer should be used scenario.

~~~
drifkin
Overall it is, but when the above commenter mentions box-and-glue, they're
talking about the building blocks of the line breaking algorithm TeX uses (you
can read about it in this paper:
[http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/ab...](http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/abstract)
). The box-and-glue system is a way of expressing a layout as an optimization
problem (in the paper, they talk mostly about determining line breaks within a
paragraph, but the idea of minimizing badness can be extended to determining
page breaks as well). A bigger concern for me is the performance of laying out
any reasonably complex page — the performance we get from rendering a
reasonably complex webpage today is generally much better than rendering a
reasonably complex LaTeX document.

I've come across a feature request for Firefox where someone proposed to use
the Knuth Plass line breaking algorithm just for text layout, but they didn't
get very much traction:
[https://bugzilla.mozilla.org/show_bug.cgi?id=630181](https://bugzilla.mozilla.org/show_bug.cgi?id=630181)

~~~
colanderman
Are there any CSS replacement proposals that are based on linear programming
[1]? There are a lot of things you cannot solve with just LP (e.g. rearranging
floats on a page) but it's a pretty good -- and simple -- abstraction for
laying out boxes relative to each other.

Solving LP is fast, _especially_ when many of your constraints are equality
constraints (as would be when specifying tables).

[1]
[http://en.wikipedia.org/wiki/Linear_programming](http://en.wikipedia.org/wiki/Linear_programming)

~~~
drifkin
I think Cassowary [1] is what you're talking about (particularly section 1.2
where they talk about some modifications to make their system very fast for
incremental updates). Apple has based their constraint-based layout system,
Autolayout [2], on Cassowary. There's also a project that incorporates
Cassowary constraints into a CSS-like declarative syntax called GSS [3].

[1]
[https://www.cs.washington.edu/research/constraints/cassowary...](https://www.cs.washington.edu/research/constraints/cassowary/cassowary-
tr.pdf)

[2]
[https://developer.apple.com/library/ios/documentation/userex...](https://developer.apple.com/library/ios/documentation/userexperience/conceptual/AutolayoutPG/Introduction/Introduction.html)

[3] [http://gridstylesheets.org/](http://gridstylesheets.org/)

~~~
colanderman
Great links, thanks!

------
grey-area
CSS is broken.

I've just been watching a colleague learning HTML/CSS for the first time. HTML
was easy and she has a very good handle on that, producing some nice HTML5
markup by hand very quickly. CSS has been a nightmare - mostly not because of
selectors or values (that comes later), but because of basic layout issues
caused by the nasty hacky layout model of CSS - in particular the concepts of
floats, block and inline and unpredictable element sizes due to the box model.

But I disagree that CSS should thus become a general purpose programming
language - the separation of concerns in HTML into content/style/controller is
very useful and would be terrible to throw away, just because our current
styling language is so lacking.

The problem with CSS is layout - properties, selectors and values could do
with some work of course, but they're mostly passable if a bit underpowered.
Layout is insane and it's down to assumptions made at the creation of CSS - a
very simplistic doc model assuming some basic structure of heads, text and a
few pics flowing in a linear fashion down a page - like a technical paper or
simple book layout. Flexbox looks equally unintuitive if a bit more powerful.

It is a hard problem, but there has to be a better way than the current
agglomeration of hacks upon hacks - something akin to the HTML5 movement for
styling - remove or deprecate most of the overcomplex spec and refine what is
actually in use. _Grids are key here_ \- they've been used in graphic design
for centuries, and they are a fundamental part of organising information which
is entirely missing from the CSS spec and should be the basis of layout, not
an afterthought.

~~~
unclebucknasty
Indeed CSS is broken. But, if you tried to make that case several years ago
during the Great War on Table-based Layout, you'd have been absolutely
persecuted. Oh how we wrangled with the utter pain that is CSS layout, only to
appease the tableless zealots. I can remember wrestling for hours with simple
layouts that just wouldn't cooperate cross-browser. Meanwhile, I could achieve
those layouts in mere minutes with tables. Not only that, the resulting table-
based design HTML was an intuitive read.

The reason was as you say: Grids are key.

How many people would now honestly say that we are better off for CSS-layout
vs. tables? But, it's amazing how an entire industry lurched in one direction
so quickly, based on ideology. The pressure to use the "right" approach was
immense. The whole thing had a very "Emperor's New Clothes" feel to it.
Everybody seemed to agree that CSS layout was completely awesome, while I beat
my head against the wall trying to make it work. Now, we all see that so many
were actually suffering in silence.

> _the separation of concerns in HTML into content /style/controller is very
> useful_

This is a belief that I question to some extent and I've wondered whether it's
a core assumption that sounds great and thus goes unchallenged, but fails to
make the cut in the practical world. In particular, how much do we really need
to separate content from _layout_? Styling is one thing, but layout tends to
be intrinsically tied to the content. You can change the appearance of content
without modifying its meaning, but changing its organization or layout can
render it absolute nonsense. Thus, if CSS were all about colors, fonts, etc.,
it would actually be a somewhat reasonable approach to separating reasonably
separable concerns.

But, as most now agree, it's CSS's horrible attempt at managing layout that
makes it so painfully bad. And, I really wonder if the core problem is just
that there's no real benefit to trying to separate layout (vs simply style)
from content in the first place. What we're really saying in attempting to do
so is that we want to be able to create a document wherein we have a bunch of
unstructured content that we want to insert in an essentially random fashion,
then create a second document that rearranges the content.

It's an unnecessary abstraction that seldom provides an ROI. How often do we
later want the content to stay exactly the same, but simply want to change
where it appears on the page? And, if we do, is it really easier to change the
layout in an external document (CSS or otherwise) than it is to modify the
document?

I have yet to hear a proposal that makes more sense than the old-table based
design. The purists said that tables are strictly for presenting tabular data.
Fine. So, let's create a new tag called "grid" for layout and give it the same
layout flexibility as the tables of old.

~~~
grey-area
_Styling is one thing, but layout tends to be intrinsically tied to the
content._

This is an interesting distinction - thanks. As you say there are issues with
separating layout and content, because the two can be hard to separate
effectively. I _think_ it is worth the effort though, and sometimes pays off
(for example reflowing content for a mobile device). An interesting thought
though that we should separate style and content, not layout and content.

As to tables, I think there were two issues mixed up in that religious war -
the nasty markup of table/tr/rd, sliced images etc polluting every website
when it was intended for data, and grid layouts (which it made easier).
Unfortunately grid layouts were thrown on to the auto-de-fé along with sliced
images and table markup, and then promptly reinvented (with much pain) by
entire frameworks designed to make up for the shortcomings of CSS.

There have been very recent attempts to add grids to CSS, and hopefully
they'll come to something (see link above from buovjaga) - I do think they're
far more intuitive and most importantly impose a sensible structure on people
attempting to lay out information.

~~~
dsego
Untying styling from layout is what OOCSS does. All styling is written only
with classes. This makes it easy to reuse styles. All other selectors,
especially nested, are avoided, since they rely on a certain layout and can't
be reused.

[http://www.smashingmagazine.com/2011/12/12/an-
introduction-t...](http://www.smashingmagazine.com/2011/12/12/an-introduction-
to-object-oriented-css-oocss/)

------
owenversteeg
Most "problems" with CSS (with the exception of vertical centering and a few
others) are caused by the fact that people can't be bothered to learn CSS.

It's funny: if a programmer is told to write CSS but doesn't know how, he'll
copy-and-paste from Stack Overflow, get a shit result, and say that CSS sucks.
If a programmer is told to write Elm but doesn't know how, he'll learn the
language, write some decent Elm, and be happy. Now, who do you think will have
the better time - the person that actually learned his tools or the person
that copy-pasted CSS from Stack Overflow?

Even if you assume that CSS is as horrible as the author would have you
believe, the 'solution' of Elm is preposterous. As another commenter [0] said:
it outputs a crazy amount of divs, all the styles are inline, you lose the CSS
ecosystem, and you lose performance. Even the demos of Elm for layout are
completely broken.

[0] [http://pchiusano.github.io/2014-07-02/css-is-
unnecessary.htm...](http://pchiusano.github.io/2014-07-02/css-is-
unnecessary.html#comment-1466610097)

~~~
Raphmedia
That.

I actually learned CSS in a school. My teachers were real front-end
developers.

I can honestly say that I never had any problem with CSS and that I never
found it to be broken. The only issues that I think of come from trying to fix
things for the old IE browsers, which are broken.

CSS itself? Mastered it in 3 months if not less.

Come on, people. You can't give me both "You are paid less because CSS is easy
to learn!" and "CSS is so hard! I can't use it! We should create something new
to remplace it!".

~~~
scotty79
You seem new to this. Just keep centering variable height content vertically
in variable height containers on different browseres until you get what's
broken with CSS.

You can also try to pick up a newspaper (multicolumn) and try to replicate its
layout so it behaves well with dynamic content.

~~~
Raphmedia
Both of those things are easy.

Doing both of those things in IE6 is hard.

To me, IE6 is broken, CSS isn't.

~~~
scotty79
Ie6 is ancient history now. Ie9 is the new ie6.

~~~
Raphmedia
In a way, yes. IE6 isn't something that I have to support anymore.

However, most clients actually pay an extra to have us support IE7 - 8. On
responsive websites. With plenty of customization and fancy graphics.

------
taeric
I'm not really sure I understand what the point of this message is. The point
of separation between CSS and HTML is not that "designers" are idiots. Nor is
it that developers are poor designers. The idea is strictly to keep the data
separate from any other concern. This is broken all of the time by all sorts
of grid based elements and such. But the idea does seem decent, if a touch
naive.

That is, to Spolsky's credit, the point of HTML being completely layout free
is supposed to be the compelling feature. And it roughly works for basic
documents. I'm actually convinced it could work decently for more complicated
layouts if absolute positioning were more understood by developers and
designers.

Are there better ways to go? Certainly. I'm particularly fond of the way that
LaTeX gets things done. Though, that is far from a "safe" environment. (For
example, you should probably never just up and run a .tex document on your
computer without first scanning it yourself.) Also, it is worth noting that
efforts are usually made to separate style from content there. (Not sure what
the overall verdict is on those at the moment. But they do exist.)

At the end of the day, though, the dream is still a language where you can
edit one file to change the way something looks on render, and another to
change what it contains. Any language that lets you do both in one place will
result in you doing both in one place. Such that it becomes very problematic
to change the look of something without changing what is in it. And vice
versa.

Right?

~~~
rbehrends
> That is, to Spolsky's credit, the point of HTML being completely layout free
> is supposed to be the compelling feature.

Except that it isn't. If you want to do anything entirely non-trivial, you
have to annotate your HTML with classes and ids, and then hook into this using
a complicated declarative language. But, at this point, there is no
abstraction gain from

    
    
      <div class="floating_figure">...</div>
    

over

    
    
      floating_figure(...)
    

Functions are fine abstractions and nothing stops you from providing different
implementations for different situations, and these implementations can again
use abstractions to deal with a variety of output devices. Nothing here
requires you to define layout specifics as part of the document [1].

Moreover, not all the world is just plain sequential text. There are
mathematical formulas and syntax diagrams, for example. math.stackexchange.com
falls back to Javascript (via MathJax) in order to display formulas; and Lout
provides an excellent example of how one can specify the spatial relationships
of syntax diagrams [2] while still abstracting over the implementation details
(Lout is another functional layout/typesetting language).

[1] Of course, in practice, the world is never so clean, and you can rarely
ignore layout constraints entirely; anyone who has ever written a paper
containing a non-trivial mathematical formula knows that.

[2] [http://i.imgur.com/huD07xc.png](http://i.imgur.com/huD07xc.png)

~~~
rimantas

      > But, at this point, there is no abstraction gain from
      > <div class="floating_figure">...</div>
      > over floating_figure(...)
    

There is no abstraction gain, because you are using a presentational class
name. It should not be "floating_figure", "big_red_text" or anything of the
kind. What it could probably be is "feynman_diagram" or something simmilar
describing what's so special about this particular element, not the looks or
placement of it. And then it is up to your CSS to decide should it be floated,
fixed, or hidden altogateher.

~~~
baddox
The idea of semantic class names is reasonable, but even that ends up needing
to be ridiculously contrived with things like "feynman-diagram-wrapper."

~~~
pornel
There's proposal for ::outer pseudo-element to eliminate all such wrappers.

------
Lerc
I don't think the problem is that CSS is an unnecessary approach to the
problem of layout. It is more that it is a _poor_ approach to the problem of
layout.

A layout language is unnecessary given a bytcode VM a chunk of memory, code,
and an output. The balance is in capability, performance, and understanding.

I have done a lot of CSS wrangling which has given me plenty of time to
consider what 'a better way' could be. I doubt I'm alone in that respect.

CSS has three parts. Properties, selectors, and values. When someone is
talking about how awesome CSS is they have usually done something clever with
selectors. When someone is ranting about getting CSS to work right, they are
usually trying to figure out what set of values to put into properties.

The properties themselves are insane. The legacy of incremental development
and serving many masters. The options for values are limited. attr() would
help my own usage a great deal but Firefox doesn't support it (see here
someone complaining in 2011 that they've fallen behind Internet Explorer on
this
[https://bugzilla.mozilla.org/show_bug.cgi?id=435426#c3](https://bugzilla.mozilla.org/show_bug.cgi?id=435426#c3)).

Actually Properties, values and Selectors are all limited. Selectors are just
the least weakest link. Properties could do with a complete _breaking_
overhall (ie. If a document is in doubleplusgoodCSS mode it only supports the
new style properties). property values should be the results of expressions in
a pure functional language. Selectors should be another expression system with
operators and member-check functions, the selector system is close to what it
needs to be already. Just a mechanism for user defined groupings (such as
attributeContainsPrimeNumberAsHex("class")) and combinators.

~~~
MrBuddyCasino
I fully agree with your distinction of selectors, properties and values - not
all parts of CSS are bad. When you say "property values should be the results
of expressions in a pure functional language" \- which I think is a great idea
- do you mean to use them to compute layout as well?

~~~
Lerc
When I posted that comment My view was that layout would still be primarily
driven by higher level style properties, but after I posted I though about it
some more and I realized if done properly you could probably the css value
language could theoretically do it all. If it were to generate values for the
complete layout, bypassing the higher level layer, effectively telling the
display engine that everything was absolutely positioned and in the right
place already.

I don't think I would advocate for that to be the standard way to implement
layout, but it should be at least possible.

Similarly I think the system should be capable of specifying a table where
each cell has a background colour corresponding to its position in a
Mandelbrot set. I don't think people should be doing that normally either, but
I certainly think it should be something that is capable.

------
pcwalton
In Servo we've been able to get a lot of parallelism out of the basic building
blocks of CSS. Any replacement would have to have a good story here. "Just
write your layout in JS" is _not_ good enough and would be a large performance
regression.

~~~
goldenkey
Constraints based system is the way to go. And yes, it should be native
replacement for CSS- a DOM property called constraints instead of style.
Unfortunately, JS has to be used for now. [1] As for parallelism, we still
have web workers for the solving of constraints computations.

[http://gridstylesheets.org](http://gridstylesheets.org) [1]

~~~
pcwalton
> As for parallelism, we still have web workers for the solving of constraints
> computations.

I am confident that the lack of shared memory, along with the heavyweight
nature of web workers, means that any attempt to use web workers to perform
parallel layout will be slower than sequential.

~~~
goldenkey
You are correct. A native solution with a dedicated thread would be amazing.

------
jameshart
I'm struck by the contrast between the conventional wisdom that content and
layout should be kept separate, and the recent highlighting of Mike Bostock's
work at the New York Times on articles like
[http://www.nytimes.com/interactive/2014/07/03/world/middleea...](http://www.nytimes.com/interactive/2014/07/03/world/middleeast/syria-
iraq-isis-rogue-state-along-two-rivers.html)

I've always been dubious about how well that mantra applies to web
applications, but conventional wisdom certainly has it that content and layout
separation works most strongly for documents; but Mike's work shows that
layout can be a powerful component of messaging.

Producing pieces like the ISIS layout requires a much richer concept of
separating the layers that go into the final presentation; paragraphs of text
associated with geographical regions, times, and news events are the content
items - not simple divs with classes, but rich objects. Choosing then how to
lay those out is clearly far beyond the capabilities of CSS. And while in
theory the layout logic to display a scrollable strip map with location
markers could be reused for another story, in truth that layout is part of
this article, not a generic 'stylesheet' that would be shared by a number of
documents containing similar objects.

We need tools that facilitate creation of procedural layouts. CSS has its
place in specifying typographic conventions, but it's a hindrance to making
more interesting content-led layouts.

------
saraid216
Does anyone think it'd be a good idea for browsers to support more than one
toolset? Right now it's just HTML+CSS+JS, no matter what languages people
build on top of that assembly.

Elm seems like a neat idea, but based on Paul's post, I dislike the fact that
it compiles down to CSS. It seems a disingenuous way to present the language.
I'd much rather a browser was simply told this was an application/elm or
something and ran with that properly.

~~~
georgemcbay
"Does anyone think it'd be a good idea for browsers to support more than one
toolset?"

Some people do. I do. But it seems to be a minority opinion; most web
developers seem to live in this weird cognitively dissonant state where the
HTML DOM+CSS is always the right tool for the job because it theoretically
allows for platform-independent layout to "any" browser while then spending
most of their time dealing with getting their layouts to actually work on
about a handful of real-world browsers which all treat the same layout code
differently (in ways from subtle to large); resulting in piles of frameworks,
pre-processing systems and general hackery to get everything working, mostly,
most of the time.

If there were a second toolset that were more rationally designed to solve the
real-world problems of modern web apps, giving you layout via binding similar
to what you see in Adobe Flex, WPF, Qt/QML, etc (not advocating any of those
as the specific answer, just stating that I think they are all individually
more sane than HTML/CSS/JS for app/UI layout) and just accepted the fact that
the vast majority of websites are designed to be laid-out in a fairly
constrained way (while still allowing for responsive layout for different
sizes/dpis) I think web technology would be a lot less terrible.

And just to get it out of the way, there are some good hacky solutions that
help the problem I described, like React.js, Angular, Dart, etc, but they are
all built on a shaky foundation which always manages to show through because
we're stuck with HTML/CSS/JS.

~~~
taf2
I used to believe using something like the tools you outlined would be easier
until back in 2004 I spent 6 months porting my naitive windows application to
apple. I scrapped the whole thing and started rebuilding on the predecessor to
xulrunner, rebuilding mozilla and using XUL was great until I started to need
graphing and different fluid layouts that I realized HTML is so much better
for cross platform as more people are spending more hours every day making it
better on more platforms and devices and it really is write once run
everywhere once you move your native app to the server - at the end of the day
you are going to spend countless hours tweaking for the different target OSs
anyway - the web with HTML / CSS / JS are better at this than any other native
solution...

[update] we ported our native c++ components to xpcom interfaces and rebuilt
the frontend in 4 months allowing us to launch our product simo health - later
purchased by RevolutionHealth 4 months later... I still as recently as 3
months ago receive emails from past customers asking for updates.

------
thisrod
The way we got here is interesting. In 1995, if you'd wanted to implement one
of today's websites, you might have written a Tcl/Tk script that users could
download and run. Tk solved pretty well all the problems people are talking
about here in the 90s; it even had a safe mode for running untrusted scripts.
But users in the 90s would have regarded as crazy any suggestion that they
download and run random Tcl scripts from every site they visited! Lots of them
turned off the early versions of Javascript, which couldn't do much apart from
formatting tweaks.

Is the killer feature of CSS and Javascript simply that they undermined the
frog's security assumptions so gradually that it stayed in the pot until it
boiled?

~~~
ebiester
TK finally got native looking skins in what, 8.5? Perhaps a set of attractive
defaults combined with a cross platform package management system and we could
have been talking.

That said, the web was easy for users. That makes all the difference.

------
ChrisGaudreau
I actually like CSS as it is now, and it's getting better ( _cough_ ,
flexbox). Am I the only one who finds CSS incredibly hard to master, though?
I've been writing CSS for years and I still feel like a newbie sometimes, and
feel like I'm just tinkering with random attributes until it looks right.

~~~
drcode
Suppose you want to create the largest possible square div inside the
rectangle of another div. Any layout language that can't let me satisfy such a
simple and obvious layout constraint is a travesty.

CSS will not let you do this, even with flexbox.

~~~
girvo
GSS will though! [http://gridstylesheets.org/](http://gridstylesheets.org/)

~~~
drcode
Does GSS work with Reactjs? If so, I might give it a try.

~~~
mercer
If GSS doesn't touch the markup, I think it would.

------
scotty79
I'd say we still have one language too few.

At the beginning html had content, layout and styling. CSS pretty cleanely
excised all the styling from HTML. But it took out large part of layout
functionality but lots remained. Best way to follow would be to extract layout
stuff from HTML (so it can do what it does best, semantically annotate the
content) and from CSS (so it can do what it does best, all the pretty colors,
decorations and animations) and put it in new language that can define layout
elements and bind styling and content to those elements.

------
tdj
A layout engine works on a different level of abstraction, putting layout
features in CSS will be awkward. CSS is fine for typographic features and
selectors, but layout is all about relationships.

Actually, one really impressive engine for web layout engine is Treesaver:
[https://github.com/Treesaver/treesaver](https://github.com/Treesaver/treesaver)

It's meant to provide primitives that are familiar to people from graphic
design working on paginated content, like columns, grids, floating containers.
Like Latex, it's also has the least-bad-layout strategy, but here, this runs
on the client in Javascript, so that it adapts to the screen size.

I had just stopped working on a startup based on this technology.
Operationally, it was proving extremely difficult adding effects that people
are taking for granted in InDesign to work in a responsive manner on top of
CSS and a 20kLoC Javascript layout engine. It took around a year of
development just to get to the level of layout automation sophistication
comparable to what a junior layout designer would produce.

------
dustingetz
So what does it look like to define a layout in elm?

~~~
jasonlfunk
This is what he is saying is better than CSS? I don't think so.

[http://elm-lang.org/edit/examples/Intermediate/Form.elm](http://elm-
lang.org/edit/examples/Intermediate/Form.elm)

~~~
mag487
That code is doing a lot more than just layout and styling.

------
johnpmayer
I think if you strip down this article, it's saying that something could be as
powerful as CSS with fewer primitives given more composability.

------
wavefunction
I like Mr. Victor a lot but I'm not sure I agree. I think the way CSS is
implemented either doesn't jive with the paradigms many programmers use to
approach problems or perhaps it is just laziness?

I meet a lot of programmers who are generally pretty smart and capable
completely throw up their hands when it comes to laying out HTML via CSS. It's
just rectangles being displayed on rectangles. It's nothing complex like
displaying three or >3 dimensional information on a manifold. I am confident I
could layout anything anyone threw at me, and CSS is just something I've
picked up over the years.

~~~
lobster_johnson
It's not that it's difficult, really, but the tools are incredibly
underpowered. For example:

* How do you vertically center an arbitrary element inside another where you don't know the height of any of them? Answer: The only reliable way is via "display: table-cell". It has several annoying limitations.

* How do you ensure that several horizontally adjacent boxes fill the width of the container and are all of equal height, regardless of their contents? Answer: Table again, but it's not always possible without JS because of how height percentages are calculated. (Also, all browsers including Chrome implement "height: 100%" differently.)

* How, given N elements arranged horizontally next to each other, do you ensure that they (1) fill the width of the container, (2) if they become too narrow (ie. min-width), any element(s) that don't fit will wrap below? (Note: Rule #1 must apply; when one element doesn't fit, the preceding "line" must expand to fit the full width of the container.) Answer: Not possible in CSS alone.

* How do you ensure that an element (eg., an image) of arbitrary width is always has the same height as it's width? (For example, imagine a grid which should expand to fit the window, and all cells should be quadratic.) Answer: With images, possible with an unintuitive "height: 0; padding-bottom: 100%" hack, not for other elements without JS.

* How do you center an absolutely positioned element of arbitrary width and height (think tooltip or speech balloon)? Answer: JS.

* How do absolutely position an element without specifying a width, so that the width becomes the minimum needed to display all of its contents up to a max-width? For example, a box saying "Hello" should take up the space required by that word and no more. Answer: Not possible in CSS alone, although you would have thought that "display: inline-block" would work. Firefox actually does it, Chrome/WebKit don't.

* How do you have an absolute element be the same width as another element? For example, a drop down menu should be at least the width of its menu item, and an autocomplete box should at least be the width of its input box. Answer: JS.

* How do ensure a label is vertically centered on the same text baseline as an adjacent textarea? Answer: Textareas are considered blocks, not text, so you cannot without computing the baseline and using padding or negative margins, and that is imprecise.

These are just a few basic real-world layout challenges. They should not be
challenges, they should be simple to implement, but CSS doesn't help; it gets
in the way more than it aids. In some cases, inconsistent browser
implementations result in wildly different rendering. The result is JavaScript
to fill the holes, and sometimes just to say "screw this, I will do in code".

~~~
bennettfeely
1\. Flexbox, through the align-items property.

2\. Flexbox, setting flex: 1; to the boxes. Can be done vertically or
horizontally.

3\. Flexbox, setting flex: 1; to boxes. Setting a min-width to a flex-item
takes precedence so it will be honored.

4\. You got me. I remember hearing talk about an aspect-ratio property. I'm
not sure if the object-fit/object-position properties get the job done. The
hacks will have to continue for now.

5\. left: -50%; and margin-left: 25%; will work. See:
[http://codepen.io/bennettfeely/pen/LktDi](http://codepen.io/bennettfeely/pen/LktDi)

6\. width: content-width;? I don't know how the browser support is there,
however. It may be possible.

7\. Same width as what element? The parent? Set position: relative; to the
parent and top: 0; right: 0; to the child.

8\. That seems like a real edge case and maybe a bug. I'm not sure.

I hope that I got at least a few of those right but CSS and browsers are
consistently getting faster and more powerful and the answer to tricky layouts
is increasingly not "just use JS". Flexbox is now supported by all the
browsers and solves a whole lot of layout problems that designers/developers
have wrestled with.

~~~
lobster_johnson
Flexbox would solve a lot of these, but it's not supported by enough browsers
to be usable, afaik. Are people using it in production?

Re #5, I managed to leave out the important part. I mentioned tooltip because
I was going to write: ...where the element is placed _above_ another arbitrary
element. This is impossible, and raises problems such as escaping "overflow:
hidden" and what if the position goes beyond the viewport.

6: In theory, but it is apparently not supported by all browsers.

7: Not the parent, but an arbitrary element. For example, let's say I have an
input field. I want to show an autocompletion dropdown box. The box should be
at least the width of the input field. It must be absolutely positioned. The
parent container of the input field may have "overflow: hidden", too.

(Overflow handling is really a broken concept that screws up a lot of CSS,
because there is no way to escape it. Z-index is another awful one.)

Last pet-peeve: Floats depend on their order in the DOM. A float-right element
must be placed before any non-float element in order to position itself
vertically to be aligned with the parent box.

------
AdrianRossouw
That's basically what I consider [1] famo.us to be.

Instead of using css for the layout/positioning, just use javascript directly.

and then build a [2] proper scene graph in javascript.

[1] - [http://famo.us/](http://famo.us/) [2] - [http://adnanwahab.com/Render-
Tree-Visualization/](http://adnanwahab.com/Render-Tree-Visualization/)

~~~
vidarh
Not seen famo.us before... Pretty much none of the demos work properly on my
phone with the stock Android browser and 4.3.. And the amount of flickering in
the browser even on my laptop was annoying. Looks to me like they have a long
way to go.

------
api
The problem with the web is more fundamental: it is trying to simultaneously
be two different things. One of these things -- document markup and hypertext
linking -- it does pretty well. The other -- a GUI framework for remotely
accessed applications -- it does _horribly_.

------
Shog9
Haven't looked at Elm. It may be the cat's pajamas.

But reading this article, I'm immediately reminded of all the marketing
surrounding XAML a few years back. Not particularly enamored with the results
there.

Poorly-done, abstraction actively _gets in the way_ of combination. At some
point, everyone has to agree on the same abstraction if they're gonna work
together; _enough_ of CSS has been widely implemented to allow folks to build
on that, while plenty of other, richer, more powerful abstractions predate it,
but were never widely agreed upon.

------
zaroth
I'd say we're getting pretty good mileage out of what we've got? CSS dominates
layout for a large portion of overall screen time.

Are native app developers crying for CSS? Not exactly.

The browser window itself is a big layout impediment on the desktop. On
mobile, hopefully the browser will just get out of the way, and give the app a
decent way to install an icon, and some more "permanent" state.

------
asurty
My concern with people rolling their own layout engines is that they are
reinventing the wheel (for the most part). Diverging from standards means
learning how to do something I already knew how to do.

Extending CSS with things such as LESS and SASS means I don't have to relearn
everything. I just have to learn about the new features that actually bring
something to the table.

------
strictfp
Html used to have style embedded into it (blink, table, align, font etc).

The idea of separating the style into a css file was born in a time when
server side scripts were generating the html (hence the programmers), and the
frontenders didn't want to ask for code changes nor code themselves. So they
figured that if you could separate the content from the style, they could make
changes without talking to programmers.

This didn't always go so well. As you all know, css quite often require
wrapping divs and other content tweaks to do its wonders.

Eventually the frontenders gave up and took over responsibility for all the
markup, only requiring a CRUD backend.

So now we have separation for no apparent reason. Some argue that it's a great
benefit to be able to swap styles by swapping csses, but how often is this
really used? And having parallell structures in your code is a known to be
costly developer-wise.

If I look at how Bootstrap tries to close that gap by fixing the style of
different elements and factor in the fact that all frontenders know how to
code and own all the markup I think to myself: why not go back to the old
system?

Html5 has already started this trend by giving explicit names to tags instead
of calling them "div", "span" or "object". Btw, why have div and span in the
contents, the only difference between them is style, right?

I think it's time to consider html a rendering artifact and let style be
embedded.

------
jv22222
Am I the only one who actually likes CSS?

I tend to find can do pretty much any design that I've been tasked with
without using graphics.

For example: [http://justinvincent.com/page/2043/anatomy-of-a-native-
feeli...](http://justinvincent.com/page/2043/anatomy-of-a-native-feeling-
html5-ios-app)

But I will admit it has taken 17 years to get to that place.

~~~
gurkendoktor
Building eye candy with CSS is lots of fun, and I enjoy it more than in other
systems (e.g. UIKit). It's text layout that is ridiculously hard.

E.g. add a second button "calculate totals" under "done", but ensure that they
always have the same height if one contains a line break. Maybe it's possible
with flexboxes, but no client will let me target IE 10+.

------
anuraj
Browsers use DOM whether you like it or not. The rendering engines are built
on eventing model. CSS is what they understand now. We can think of changing
that, but given the history of browsers and HTML standard, I am not very
optimistic that such changes can be pushed through easily in a reasonable
amount of time.

------
al2o3cr
"It’s true that in using a language like Elm for layout, one loses the ability
to cut and paste random CSS found on Stack Overflow in cargo-cult fashion
without understanding what it does. I consider this limitation a feature."

Wow, elitist much?

~~~
mercurial
It could have been worded better, but if you consider that people will do this
copy-paste out of frustration with the inability of CSS to come up with a
reliable, easy to use way of doing layout, which Elm solves, then it's not
entirely unreasonable.

------
norswap
I'm not sure using a general-purpose language is the way to go, they do that
for Mac/iOS development and it's 1000 times worse than CSS. Now, perhaps the
FRP nature of Elm would alleviate the pain, I don't really know.

------
IvanK_net
We have a very fast internet nowadays, so we can include our own CSS engine
(written in javascript) inside our webpages. It will rasterize the content
into Canvas, it will look the same in all browsers.

------
Keats
Is anyone using Flexbox in production?

I'm wondering how it works in practice, caniuse indicates that it can support
all major recent browsers and not having to use a grid library would be nice.

------
miguelrochefort
The solution is simple. Let the computer understand the intent of the user
(why he needs an interface), and generate a custom interface that exactly fits
his needs.

There is no reason to hardcode design. Design should be dynamic, and that goes
beyond "responsive" design.

Heck, even a simple card-oriented UI where every model has a manually designed
layout would beat whatever we have now.

Unless you're implementing a system that generates UI dynamically based on the
data to display, you don't need to touch any low-level GUI code dealing with
margins, colors, animations, sizes, etc.

All of this is quite obvious and intuitive. I'm sure it's been tried many
times before. Why is it not what we use today?

~~~
larzang
Because the ui of a website or program is not just an interface, it's also
(and quite often primarily) presentation. Visual presentation is a justifiably
complex field with a rich history that has taught us that how you present
information is often just as important as the information itself. All those
colors, animations, etc are an integral part of expressing authorial intent
that goes far beyond simple branding.

Arguing that computer ux should solely be driven by the needs of interface
without concern for presentation is like arguing that all print media should
look like unillustrated pages from a research paper.

~~~
miguelrochefort
I don't get what you mean.

What's the purpose of a presentation, and why can't it just be generated?

If colors and animations convey meaning, there's no reason not to include them
in the generated UI.

I have used many aggregators that let me use features from a handful of
services, and never have I missed the diversity of presentations of all the
base services.

> Arguing that computer ux should solely be driven by the needs of interface
> without concern for presentation is like arguing that all print media should
> look like unillustrated pages from a research paper.

Unless I don't understand your definition of presentation correctly, and
ignoring the absurd idea of avoiding illustrations in a research paper, I
don't see a problem with this.

------
westiseast
It strikes me that CSS is pretty good, but the mess of hacks that the OP
complains of are the result of crappy browser implementations, not crappy CSS?

------
tkubacki
CSS seems too complex (and is) because you can't EASILY set boundry for rules
in inner elems. This problem is solved by ShadowDOM.

It's easier to think in CSS when top level css is only top layout plus theme
color setting. Try PolymerJS.

------
Rapzid
I really like the point about designers learning to program. It got me
thinking that eventually many/most professionals may need a basic grasp of
programming. Then it dawned on me; why not teach EVERYONE basic programming in
school?!

~~~
sjtrny
What about accounting? Most professionals need a basic grasp of accounting.

~~~
ThomPete
Accounting is not a language, programming is. You can create anything with
programming.

Thats why it should be taught.

Edit: Care to elaborate why that comment should be downvoted?

~~~
Throwaway0812
I think you're being downvoted because life isn't just about creating
something. Basic accounting is an important tool for any adult living in this
world. I would argue the knowledge of managing finances is more important than
programming, because it applies to everyone, regardless of your career path.

Debt, loans, mortgages, interest, investments, retirement plans, etc. These
are important things for everyone to understand. When I look around, I think a
lot of people would be better off if they had a better understanding of
finances, but I rarely look at people and think their lack of programming
know-how is holding them back.

~~~
ThomPete
I have run successful companies and been fine without ever knowing basic
accounting.

We are not talking about what is most important we are talking about what is
most useful powerful for someone who today is in school and need to have some
skills for the future.

Are you seriously telling me that if you had to choose for your kid you would
tell them to learn accounting and not programming?

~~~
Throwaway0812
You're missing the point, we're not talking about career paths here, no one is
advising anyone to become an accountant over a programmer. We're talking about
an introduction to these subjects.

If you had one week to sit down with every person in this world, I think that
time would be better spent discussing finances, investments and retirement,
instead of an introduction to variables, if/then statements, and loops.

~~~
ThomPete
I am not missing the point since I was the one making it.

It doesn't matter what you think would be better what matters is whether
programming contrary to accounting can be seen as a language or not and is the
reason why it should be taught.

Just putting some arbitrary other field in there is what is missing the point
whether that is accounting, CPR, sports, history and so on.

You can put anything in but programming is different since it potentially can
contain all the other fields in it's ability to simulate them all.

------
adamconroy
Quick. Everybody get out their 'web standards' sticks and lets all beat this
guy up. The web must be done with standards, otherwise someone might not be
able to use some web pages on some device at some point in time, and that is
not acceptable.

------
owenversteeg
TL;DR Neither this blog post, the Elm website or Elm's example sites have a
good example of something laid out well with Elm (all break horribly badly
when resized.) Also, If people actually learned CSS, they would have a much
easier time.

Firstly, I find it hilarious that when I opened this blog post dissing CSS the
author's 'responsive' design was completely and utterly fucked. I opened the
page at 50% width and 100% height on a laptop, and I was confronted with a
bunch of unrelated text taking up literally the entire fold. By resizing my
browser I found out that the hideous thing taking up my entire browser window
was what would be the sidebar if I expanded my browser further. I then go to
the Elm website and am presented with a site that's not responsive at all, and
I take a look at some "example sites" built with Elm and I get this[0] site,
which breaks in a ridiculous fashion when resized. Hell, if you're designing a
layout language and you can't even point to one example where it works I'll
really start to question it.

Secondly, I think that the vast majority of 'problems' people have with CSS
would be solved if people just learnt it as they would a programming language.
All the time I hear "CSS is so frustrating!" from people that write code in
other languages just fine but don't know CSS. Well, just learn it! Most people
don't care about learning CSS, and only copy-and-paste from Stack Overflow.
You wouldn't copy-and-paste every single line of code from Stack Overflow for
your C++ application, so why do you do it with CSS? I actually took the time
to learn CSS a while ago, and it's been much easier to write it since. I have
only had one problem in the past few years with CSS specifically: vertical
centering and browser inconsistencies. I'd say having only two major problems
for a language that's been designed around browser politics is excellent.

[0] [http://library.elm-lang.org/](http://library.elm-lang.org/)

~~~
_pmf_
> Firstly, I find it hilarious that when I opened this blog post dissing CSS
> the author's 'responsive' design was completely and utterly fucked.

That kind of proves his point, though. If the foundational layout language for
the web requires more than basic effort to create a responsive design,
something with it is fundamentally rotten to the core.

~~~
owenversteeg
> If the foundational layout language for the web requires more than basic
> effort to create a responsive design, something with it is fundamentally
> rotten to the core.

CSS is a language. Like Haskell, C++, or Ruby, if you only put "basic effort"
into learning it when you try to write some it will be absolute shit.

~~~
_pmf_
> CSS is a language. Like Haskell, C++, or Ruby, if you only put "basic
> effort" into learning it when you try to write some it will be absolute
> shit.

CSS is not a general purpose programming language. A domain specific language
is a failure if the most basic features of the domain cannot expressed with
minimum complexity.

THERE'S NO WAY TO CENTER THINGS VERTICALLY WITHOUT FALLING BACK ON HACKS, FOR
GOD'S SAKE!

~~~
owenversteeg
Sure, it's not a general purpose language. As a result, writing decent CSS is
easier than, writing, say, decent Haskell. But people have to put _some_
effort into learning it or they'll get crap.

I agree with you entirely re:vertically centering things, but that's one of a
very small number of major flaws in CSS.

------
varkson
Yawn, just a typical engineer who can't understand CSS. Go back to the
dinosaur languages like C and Haskell and leave the web to the smart guys.

