Sometimes I wish I could get back all the brain cells that I've wasted on the hundreds of "little tricks" you need to know to get things working -- and then working cross-browser.

Short answer: CSS is just a horribly, horribly, terribly badly designed language. It's the absolute worst. Don't let anybody tell you otherwise. It's that, it's what we've got, and it is awfully powerful in many ways. But it's complete rubbish in others, which include a lot of incredibly basic layout things.

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.

See this well trafficked "CSS sucks"-type article, Ctrl-F the comments for John Nagle, be tantalized at the hints of how it could be so much better: http://www.raizlabs.com/blog/2006/09/25/ten-reasons-why-css-...

Look up "constraint-based layout" and more specifically "constraint cascading style sheets". You'll find papers such as this one: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.101.4... and this one: http://csis.pace.edu/~marchese/CS835/Lec7/mmJournal.pdf thoroughly describing such a system.

Find "GSS - Grid Style Sheets" at http://gridstylesheets.org/ , "an implementation of Badros & Borning's Constraint Cascading Style Sheets". This is still half on my todo list, but it seems like the real thing. The catch? Relies on Javascript.

Dream of a world in which this kind of system was built into browsers as the primary way of doing layout <insert Simpsons happy dancing people gif here>.

It’s not that CSS is hard; it’s that CSS is bad. (...) The worst problem with DIV-based layout is that the layout system is too weak. (...) There’s no way to relate a DIV to anything but its predecessor, its parent, or an absolute position. (...) Table layouts allow table cells which span multiple rows and columns. If all tables could do were simple grids of cells, the CSS approach might make sense, but tables are more general than that.

I get it that HTML is supposed to be for content, CSS for layout and JS for programmatic logic, but the house of cards, duct tape, bailing wire and chewing gum that goes into making a web application is astonishing.

I almost think it would be easier for somebody to come up with an entirely different "web application/dynamic document layout" technology stack with a sane and well-working model all the way through, so that stupid basic things like vertical alignment don't go unfixed year after year after year and we end up with the teetering tower of hacks we have today. We pretty much know what we want out of the web, somebody should just go build it from top to bottom all over again and throw out the huge train wreck we have to deal with today. Sure it would take a while to catch on, but I bet a more efficient set of tools and display environments would rapidly catch on.

We've done it before and replaced older broken technologies with newer, why not do it again?

That is to say, it's not possible to create any conceivable layout with CSS alone. It might be possible if the thing spits out Javascript as well.

Yes, but if someone managed to create a logical, concise Web publishing standard that was something other than a can of worms, it would be a proprietary system, most likely patented. Which means no one would voluntarily adopt it.

The advantage of a public, open-source, no-one-in-charge system like we have now is that it's collaborative, democratic, and free. That's also its disadvantage.

For a classic counterexample, look at Apple's products -- they create much more consistent and usable products than the rest of the marketplace. But as many have said, Apple is a walled garden. If an Apple product happens to do what you want with no changes, then fine, otherwise you're out of luck.

Freedom is messy. Democratic technology seems always to veer toward chaos.

The W3C isn't a town hall, it's more like the UN. At best they prevent the web from going back to the chaos of the mid-90s.

Like Guido Van Rossum in the Python world (with the title "Benevolent Dictator For Life"), who seems (so far) to manage his power well. But I think this is a rare exception to a well-known rule about arbitrary power.

It was called Flash. Or Java applets.

See history.

Edit: since you are a new developer, let me add that "ugly hackery" is what you quickly arrive at once you start doing anything of reasonable complexity (read: stuff that's actually useful). Handling the edge cases is what consumes most of the code in real production applications, and this is conveniently omitted from the beautifully clean code presented in tutorials and examples.

CSS, from my experience, makes it very easy to do web design the right way and very hard to do it any other way. It's just that the right way is often a little different from what people expect. If you accept that <i>the browser is the boss</i>, you'll be a lot happier, and incidentally your users will be a lot happier as well. The trouble is people coming from other platforms or mediums often expect 100% control, and for that it really doesn't hold your hand.

I totally agree. For example, the CSS box model sounds so simple and elegant at first, but when you add dozens of styles and elements to your page, the interaction between different styles can quickly become horribly messy no matter how disciplined you are with your CSS code. Beyond a certain number of styles, CSS inheritance turns into a black art.

CSS simply doesn't scale well for anything beyond relatively simple pages. A huge part of designing web pages is layout and spacing and yet positioning and spacing elements remains ridiculously messy and convoluted (even with CSS3).

You could also argue that tools like SASS and LESS are in effect sticking-plasters for inadequacies in CSS.

I know hindsight is a wonderful thing, but if we were designing CSS today from scratch, I think it would be designed very differently.

It seems like flex-box fixes a lot of this, but at the same time, it could be so much easier.

You're right though. CSS would be so much different and so much more gloriously painless to use. I can even imagine a better styling engine allowing for applications like macaw, dreamweaver to actually generate properly good CSS and thus building sites with a GUI would finally be plausible.

It's why it's so frustrating when people treat front-end design with disdain as something trivially easy. Of course, if you only decide to serve the newest version of Chrome and Safari, it can be easy to remember that there people out their who don't - or can't use them.

It's web development you're referring to.

The people writing production-ready HTML and CSS were known as "web developers" or "client-side/front-end engineers".

Some material:

http://www.raizlabs.com/blog/2006/09/25/ten-reasons-why-css-...

http://diveintohtml5.info/past.html

The user gets what they want, the designer gets what they want, and the only people unhappy are some purists.

why? what about this is wrong?

You can get away with using "display: table-cell;" and the like inside components that are independent of responsive requirements, though.

Also remember that not everyone views the web in a browser. Having well structured markup helps those that use screen readers or alternate methods of browsing the web.

I don't think this is true any more than "good print design and good postscript go hand-in-hand".

I don't think tables are the right way either, but they're too often the pragmatic way until CSS gets dramatically more expressive.

The "restraint" you're talking about is not something designers should have to accept —- not least because CSS appears to be being developed with insufficient concern for what designers would actually like to be able to do. If it wasn't, vertical alignment would have arrived long ago.

It also makes it far harder for other user agents to make the design fit in small spaces: many table based designs are completely unusable on mobile devices for instance. While the alternative might still not look nice in such an environment, it is more likely to not be completely impractical to use.

Of course if you are presenting something that naturally fits in a tabular structure, tables are the thing to use as that is what they are designed for.

The HTML table model has evolved from studies of existing SGML tables models, the treatment of tables in common word processing packages, and looking at a wide range of tabular layout in magazines, books and other paper-based documents.[1]

It was only later when table layouts began to be discouraged.

[1] http://community.roxen.com/developers/idocs/rfc/rfc1942.html

I do agree though that it is a pain when something is easily achievable in tables but doesn't work in normal CSS. Vertical alignment being one of them.

What does annoy me is when you see people creating "CSS table" systems. I'm not being funny but that is just plain stupid. I saw a whole project dedicated to replicating the behaviour of a table.

I started developing when tables were fine to use for all layouts and I feel CSS was adopted as a layout too early without some very basic things being answered.

Unfortunately the real world hardly ever works like this.

Right. Purists like blind people who access your site with a reader, and Google's page crawler.

Usually developers try to find a way to solve the problem because they are engineers and that is what engineers should do. HTML, CSS and JS wasn't invented to what it has become today. It has evolved thanks to people like you and me who has find ways to use to our advantage. Example AJAX was existed since dark ages (IE5+) but no one used/knew about it. Google used that in google maps in 2004. Now, pirates are using it in usenet/torrent applications (utorrent, sabnzbd, sickbeard etc), or 3d rendering in the cloud (http://home.lagoa.com/).

If you are waiting for something better to be found, i think you will have to wait long time. There is nothing on horizon that is as simple as HTML.

For me, hardest part is in the web development is to deal with designers and product managers.