CSS: It was twenty years ago today
dev.opera.com
dev.opera.com
That was the biggest mistake, IMO. John Nagle's comments here [1] express that point really well:
> With Dreamweaver 3 and tables, it wasn’t necessary to look at HTML to lay out a page. With Dreamweaver 8 and CSS, the page designer must understand CSS, HTML, and probably Javascript. That’s was a big step backwards. The CSS system is just too programmer-oriented. And I’m a programmer. (Programmer as in MSCS from Stanford, the Nagle algorithm in TCP, inventor of ragdoll technology, real-time robot vehicle control, not programmer as in “writes some Perl”. And my first web site went up in 1995.) 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 form of “grid” layout. There’s no way to relate a DIV to anything but its predecessor, its parent, or an absolute position. The system is just too dumb. That’s why people have to stand on their head just to get three columns to work. Tables actually are a better designed layout system. 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.
[1] http://www.raizlabs.com/graiz/2006/09/25/ten-reasons-why-css...
<div class="container">
<div class="row">
<div class="col-xs-4">
What do you mean tables produced ugly html?
</div>
<div class="col-xs-3">
Looks totes modern to me ...
</div>
</div>
</div>[1] http://swizec.com/blog/i-was-wrong-about-angularjs/swizec/66...
<body>
<main>
<p>It can be much better if you avoid abusing
HTML classes for style.</p>
<p>Classes are meant to describe the role of
the tag, not its presentation.</p>
</main>
<aside>(use Sass instead)</aside>
</body>
/* Sass + Neat */
body { @include outer-container; }
main { @include span-columns(4); }
aside { @include span-columns(3); }I miss them days.
[1] http://www.w3.org/TR/css3-flexbox/
That said, it is something of a travesty that one of the most popular reasons to dive down that particular rabbit hole in 2014 is to get real vertical centering: https://gist.github.com/acdha/a91a46706de02c37566a is still 11 lines for one of the most basic layout requirements.
Flexbox is the first CSS layout feature that makes me feel like I don't have to harness an army of hacks to get anything done.
It could have been implemented better, but the underlying thinking that users agents should try to programmatically position elements where possible is sound.
What language would be able to support billions of websites coded by millions of developers, rendered on thousands of different types of media and be easier to code with than CSS? Until I've seen a working demo of this mythical styling language, I'll be very grateful for what I've got.
And I have seen no solution for how we might code responsive layouts in pure HTML.
In the end CSS was designed to allow you to swap CSS styles independent of the underlying HTML not add new functionality to HTML.
It's a responsive layout, but not one that somebody is willing to pay me to build. Those that people will pay me for are, in my experience, easiest to build with CSS.
I personally don't have much of experience with different layout systems used in other fields, yet what I got from working with ActionScript3 (flex) layout methods few years ago and then recent experience with current android layout system, just brings back the appreciation of CSS.
It might not be perfect, easily becomes complicated, but it works and allows great flexibility.
The problem is that those technologies are all held hostage by at least two inefficient committees, and enough browser vendors have signed on to that to make doing anything without their approval near impossible.
So let's say you had a magical CSS replacement which is perfect in every way, that's ten years in committee which is a back and forward process where they can effectively force you to alter the design for obscure reasons, and then even after that you have to convince every single browser vendor to implement it, and only then FINALLY will it take another ten years for all browsers to support your new syntax so you can use it freely without worrying about incompatibility.
This magical CSS replacement would have to do that, even if CSS didn't exist.
With IE10+ silently shipping evergreen by default its hopeful that this part of that problem will go away in the near future.
The way forward is to develop what we have to make it better, incrementally. Local maxima be damned, there is no alternative.
More to the point, I think the discussion of tables vs CSS is worth reopening, because the original arguments in favor of CSS focused on having clean semantic HTML, and we all see how that turned out. Just go to http://reddit.com/ and view the source, you'll see <div class="spacer"> staring you in the face. So that argument is a wash. As for the specific drawbacks of CSS compared to tables, I think the original comment covered them well.
2. Finding somebody successfully bashing a nail into a wall with a shoe doesn't mean we should all throw away our hammers.
3. If we get into the drawbacks of CSS vs tables, tables are going to lose. I can think of two situations where tables will win - lack of developer skill (yes, tables are easier to learn quickly), and needing to support old browsers more than new ones. Whereas CSS will win on responsiveness, performance, workflow, third-party tools, features, maintenance, accessibility, flexibility, semantics, and just about every other area of front-end development you care to mention.
EDIT: Here's an article from 2003 (!) that makes the same points. As CSS has improved, the arguments have become stronger.
When CSS is being generated by programs, you might as well have those programs generate inline styles - what would we lose? And we would gain in simplicity.
The biggest loss of using inline styles everywhere would be for instances where the appearance of the DOM is changing dynamically. Instead of just saying "hey, make that node have the class 'shinyWidget'", you'd wind up needing to specify all the styles that shinyWidget includes - and then reliably un-apply them when the node was no longer shiny.
Bonus fun if two things want to change the style of a single element, though that's still sometimes a headache with CSS and specificity rules.
I still think Adobe's proposal:
http://www.w3.org/TR/css3-regions/
is a much better way to solve the problem how "how can we let publisher dictate how the pages should look, users be damned, but still keep the html-markup simple and semantic" -- than the traditional CSS model.
All that said, sites like the legendary CSS Zen garden, does illustrate that CSS is a powerful tool, and offers quite a few improvements over plain old html+tables:
Still wish they'd gone with something that was more informed by Desktop Publishing Software (along with some proper support for breaking up words, a la: https://code.google.com/p/hyphenator/ ).
Having a sane html template to target, makes it much easier to have a uniform looking (and behaving) site -- and you only have to fix css bugs in one place.
That probably has more to do with the "appification" of web sites than anything else, where huge amounts of JS and CSS are used together to produce a poor imitation of a desktop application. Pages that aren't SPAs are far more amenable to styling changes, and are often quite readable (or even more readable) even with all author-CSS disabled.
When CSS is being generated by programs, you might as well have those programs generate inline styles - what would we lose? And we would gain in simplicity.
I see inline styles as being more of a "one-off" thing, while CSS selectors can affect many nodes in the tree, so I think both have their uses. The "simplicity" is offset by the increased memory consumption and overhead of parsing every inline style, when much of them will be the same. You could argue that pages could be compressed and maybe browsers could use methods to identify duplicate styles so they can also compress them in-memory, but why do all that (i.e. making every client, on every page reload, have to expend the resources to derive this information) when you can group together common styles under one selector for which the browser will naturally treat as one object?
It seems to me that HTML is no longer the purest form of content. I've been thinking that having your content in an API (or markdown or text files in the case of static site generators), using HTML for the layout (inline styles maybe, or JS driven positioning), and CSS for the styling of the content creates a more flexible and future friendly flow. Then stylesheets could be far simpler. Layout needs to move to a new layer of the stack perhaps.
Even right here on HN. One comment being a reply to another is indicated visually with a level of indentation. That's semantic meaning. A comment saying "I disagree" carries vastly different meaning depending on what comment is its parent. If you remove layout from HN, you remove threading from conversations and lose or change the meaning of posts.
We use layout to indicate meaning in all sorts of ways. Even a simple set of tabular data with two columns will depend on visual layout. An item for sale needs to be next to the correct price for that item, for example. An image with a caption depends on having the caption spatially near the image.
I agree that it feels like layout belongs in a new layer of the stack. But how do you do that? You'd need all sorts of semantic meaning to be expressible in the data structures from the API. Things like parent/child post hierarchy, or item/price, or image/caption, or any number of other relations. How do you generalize that? This sounds tantamount to and as intractable as strong AI in the area of knowledge processing.
[1] http://nicolasgallagher.com/about-html-semantics-front-end-a...
(...) My own favorites would be nested comments, and single-line comments (starting with //). When CSS turns 50 I’ll tell you why they were not part of CSS from the beginning."
Now, this makes me really wonder why single-line comments weren't part of the spec from the beginning. And I can't wait 30 years... Anyone an idea?
I personally like how single-comments works on pre-processors. They are ignored at compile time and therefore are a good way to comment on functions, mixins or anything that won't be compiled to raw CSS.
When I want to quickly comment something out (and don't have an editor shortcut handy), I just put an 'x' in front of the property name. I.e.:
xbackground-color: #f0f;We desperately need a better standard, more in the direction of QML, so you can also talk with a lower level language. If you come from a systems programming language and you want to design a UI with CSS, well, good luck! It will suck all the joy out of your work. Center some text or a div? well buckle up for some fine days of f@*$ing around with position: relative; or position: absolute; margin: 0 auto; text-align: center; ? It all depends on the situation, and if one thing changes, your whole design is gone.. ..it's pathetic.
It's fun how history repeats.
1. A mention of the box sizing model ( which is imo the core of CSS )
2. Following that, a mention of the double margin IE bug. Nope; but there was vague mention of browser differing in spacing.
3. Mention of the fact that nothing can be changed because browser vendors don't get along and refuse to change stuff in any meaningful time-frame regardless of the specs. Wasn't disappointed.
4. Mention of SASS/LESS. It's there.
5. A statement along the lines of "CSS is obviously wonderful because it's still around. It will be around forever." Got it.
6. Mention of the need for a way to do paging properly. Yay.
Pleasantly surprised by:
1. Mention of the Acid tests.
2. Mention that single line comments are desirable. Why still not there???
Unhappy with: Hatred for IE conditional comments, web fonts, and the video tag. ( but confused since he advocated for both web fonts and the video tag?? )
All in all an interesting read.
The question was "what would you banish? what would you add?"
His response was like:
Banish: Conditional Comments Add (past): web-fonts, video tag Add (future): Pagination.
I was confused as well, and had to read it like 4 times until it made sense.
1) CSS is a single-pass layout programming language. It is impressive, but the single-pass constraint makes certain layouts very difficult to achieve.
2) CSS should be replaced with a constraint solver. Look how powerful Auto-Layout in iOS is. With a constraint solver, you are only limited by your imagination and intelligence, not some single-pass rule.
3) CSS sucks because people think visually in terms of grids and boxes, and it is too hard to do even the simplest thing with a single pass layout language.
I am personally in Camps 1 & 2, but Camp 3 is by far the most vocal. Constraint solvers are powerful, but they require a huge amount of thinking, and you end up with stuff like '==|50[x(30)]<=|==' as the interface.
I think the "flexbox" stuff is pretty good as it is an attempt to accommodate both groups 2 & 3.
Which brings up an interesting point to me, even the creator of CSS provides non-CSS complaints when asked what's wrong with CSS. A great deal of the dislike and hate towards CSS seems to be so misplaced.
But I even do the same thing. When asked what I think is wrong with CSS my response is all the designers out there that continue to insist on designing web pages as if they were print designs for a magazine.
I know it violates the strict separation of style and content, but how well has that actually worked out?
(This is me just being cranky -- I've done a bunch of typesetting resume's and such when I was younger -- so having tabs work like they used to on old typewriters, where you set them to a defined distance from the left, would have solved a bunch of problems, too.)
Well, good luck with that one! I wonder if he seriously believe computers in 500 years time will actually resemble our computers in any way? Or was it a throwaway comment? I hope for the sake of his sanity it's the latter!
Also, I'm glad that the percentage-based weighted-average influence system did not make it into actual CSS :)
Rigid made sense. Economical to make and most of your visitors were 800 x 600 and above for many years. Fixed width sites still look and function well on tablets in many cases.
Absolute positioning rocks! I like it's predictability.
Funny that he said he doesn't like conditional comments! "Bad for web standards". Agreed.
...only to have all the CSS in the <head> get rendered by the popular browsers of the time, and friends tell me that my webpage was broken and that if employers saw I couldn't even make a website I'd never get hired.
Fun times.
Once they were able to fire most of their dev staff though they made more money with the Chrome clone.
Downvote me, I couldn't help it.
Only THEN, I will read what it's there to be read by one of my myths: Bruce Lawson.