When the committee responsible for CSS started working in the late 1990s, it seems to have lacked any members who knew anything about layout. Certainly, the browser was a new challenge, but automatic layout engines had existed for decades by that point. TeX, for example. While it is a beast, I have usually found it far easier to get its glue-and-boxes model to do what I want than wrestle with CSS.

To make matters worse, the CSS people considered it a badge of pride that CSS lacks programming features. Allow variables to represent colors so we don't have type #f0c450 all over the place? Nesting constructs? Perish the thought!! That would make it look like a programming language, with scopes! As a result, we now have LESS and Sass which plug up the worst holes, but do nothing about the fundamentally brain-damaged layout model.

For example, centering in CSS is trivial if you're only doing it for one viewport size, font, font size.

CSS doesn't really have vertical positioning within arbitrary boxes, which is insane if you think about it. This shortcoming has nothing to do with viewports or fonts or whether it's screen or paper. After all, the rule "box B is to be vertically centered within box A" is not dependent on a particular medium such as print or screen. The rule "box A is to be 100 pixels tall" adds medium-specificity, but that's different.

Rather than providing rich high-level rules to create simple, responsive layouts, CSS makes one jump through hoops to accomplish trivial things like vertical positioning, and gets mired in finicky micro-details and a cumbersome, inflexible layout model. It breaks down quickly; for example, only recently, with the introduction of "box-sizing: border-box", has it been possible apply percentages to box sizes that have padding. (Before, if you had two boxes with "width: 50%", they would wrap if you applied padding.)

As an aside, I am personally not convinced that the CSS promise of separating presentation from content has paid off. In any serious web app, the DOM is visual, and separating CSS from the DOM makes no sense. It's useful as a way to organize code and to share style rules, to be sure, but those benefits don't come from content/presentation separation. I wish we had an inverted model — a visually oriented language concerned only with presentation (think SVG, only not limited to vector graphics), with a separate data language concerned exclusively with data.

CSS has boxes, more or less. It does not have glue in any meaningful way, i.e., it does not give a direct way to specify what happens in between the boxes. Pretty much all the things that are difficult to do in CSS have to do with the difficulty of describing what happens in the negative space.

I'm talking about things like the way "floats" transformed from a way of wrapping text around pictures (good) to a general-purpose layout mechanism (disaster).

About how there's no way to put a footer at the bottom of your page that stays at the bottom if your content is short, but gets pushed down if your content is long (the normal desired use case).

About how the only way to get two columns of equal height, but that expand to fit the text, is to use a <table>, but that this is supposedly disallowed because it's "unsemantic".

About the complete disaster that float-clearing is, yet how it's central to almost all modern CSS layouts, and fixed only by bizarre byzantine hacks like "clearfix", overflow:hidden (which breaks other things), or the classic "<div style="clear:both;"></div>" which needs to be peppered throughout HTML, negating the whole supposed distinction between HTML and CSS.

And finally, the fact that the width of an element doesn't include its border and padding, making for nesting div's that include border and padding much more difficult than it should be. (Although this is, of course, fixed in newer versions of CSS.)

In the end, it's not really "current language features", but mainly the disastrous decision to adopt floats as a basic layout concept, instead of grids/columns/etc. (Which is, of course, why so many people wind up using <table> in the end, which has its own problems...)

Meanwhile, CSS is still a well-designed language in terms of syntax and principles. We just need a few more features that weren't in the original spec as new uses for the web emerge.

[1]: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi...

In other words, instead of being able to write any of these

  padding: 0 0 0 0;

  padding-top: 0;

  padding: 0;

If you could only have one mechanism, and you weren't going to lose significant functionality, it would have to be the longhand padding-top, padding-bottom, etc., set.

But I think having the shorthand rule is worthwhile.

The reason I chose the first example over the second is that, if you only ever specify padding-bottom for example, what are the default values for the other unspecified padding properties? This is why we have the CSS reset technique and normalize.css (more hackery).

I would make it mandatory that you declare all four values for the padding rule to remove any ambiguity. That would also mean eliminating shortcuts like

  padding: 5px 10px 15px;

  padding: 5px 10px;

  padding: 5px;

  padding-bottom: 10px;

  padding: 5px 5px 10px 5px;

It doesn't make much sense with "padding", but for something like "border: red solid 2px;", how do you override just the color if you don't have the individual components broken out?

I forgot that padding required explicit "inherit".

So, bottom line, yes, it would seem to make sense to just have the single-line complete version:

  padding: *w* *x* *y* *z*

This is incorrect. Using display: table and display: table-cell allows you to achieve equal height columns.

This is probably why the woefully layout-inadequate CSS had to include these hacks to mimic table behavior.

So, it's more like CSS is fooling nobody.

I can tell you that I'd much rather use CSS than Android XML layouts, or WPF, or adding layout containers a la Swing or AWT. It's simple, easily understood across disciplines, and very powerful. Elements of a pretty well designed system.

On the other hand, it's 2013 and we're still trying to figure out how to center one element inside another.

In some ways, we are trying to apply desktop application design paradigms to something that started document or content oriented.

Which is exactly the problem. Web development today is a Turing tar pit, because we're using tools that were originally created for very different purposes. HTML is great for static documents, and lousy for apps. Javascript is great for attaching dynamic behavior to widgets, and lousy for large-scale software projects. CSS is great for consolidating style information, and lousy for layout. Yes, after over a decade of hacking by many smart people we've built up elaborate frameworks that sort of do what we want most of the time, but I wish we could have had more appropriate tools in the first place and been able to spend those resources elsewhere.

100% this. CSS is a very powerful tool if you know its quirks very well, and there are a lot of quirks. I know a lot of incredibly talented developers who can pick up any programming language or technology in no time at all, but still occasionally waste half a day circle-jerking with CSS trying to make it do something incredibly simple like center one box in another or baseline-align a couple of pieces of text.

However we did have that (Java applets), and they didn't take off. I think the web did hit a bit of a sweet spot at the time, but it's time for us to build new technology on top of it. Personally, it's looking like asmjs, inline styles and translate3d divs to me :)

Flexbox isn't the answer either. I had high hopes for it and I'm in the middle of redesigning a web application UI using Flexbox for layout, and I still can't do some basic things like have an overflow:auto content area that expands to fill the space between a fixed left-hand nav panel, a variable-height fixed header, and a fixed footer. I'm still stuck with a bunch of javascript and a window.resize event handler to measure some heights and adjust the sizes of my containers. Maybe the upcoming CSS grids will work, but it'll be another couple of years before support is wide enough for me to use them.

EDIT: I also wanted to say that I've learned xaml in the past few years, and that's absolutely not the direction I'd want CSS to go.

A lot of people who are shocked with the complexity of CSS aren't saying this after switching from another better GUI environment, they're getting into visual apps after doing backed work.

CSS is not perfect but I'll take it over previous presentation idioms any day.

You're on. I pick QML.

On the contrary, it's the box model that's horribly designed. CSS is quite excellent.

We're long past the days of web pages being simple hyperlinked documents, but the browser's layout options haven't evolved quickly enough.

16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.