> In my initial CSS implementation in 1995 I used the “SkyBlue” constraint solver to resolve conflicting style sheet statements. (By the way, “SkyBlue” and “Cassowary” were both developed at the University of Washington.) Having a constraint solver allows you to express relationships between arbitrary elements and have conflicts resolved automagically. However, things can get complex when elements disappear and new ones arrive, like they do through DOM operations. Circular dependencies must also be handled gracefully. Therefore, the idea of allowing CSS to express layout constraints between any elements were dropped at an early stage.
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.
That might have been true in 2006 but we now have reasonable support cross-browser for Flexbox[1] (especially if you reduce the pain with autoprefixer[2]), and CSS Grid Layout[3] is coming.
Am I the only one who finds flexbox incredibly complicated? It probably covers every possible scenario but doing some simple thing takes me 15 minutes of trial and error to get right.
I would say the opposite: After a small initial hump, flexbox is actually very simple for what it gives you, but it's ultimately fairly limited. It's not up to implementing every kind of grid layout cleanly, and it's not even in the same ballpark as constraint-based layouts.
I'm no CSS expert, but I personally find it incredibly easy and intuitive compared to the usual CSS alignment nonsense. Floats? Table display? Inline block?
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.
There's a learning curve, but it isn't as fragile as the set if margin and position hacks that were standard before. Those old hacks are still used for supporting old browsers (IE8 and before), but flexbox simplifies things once you grasp it in applications.
While you're right that the current versions of all browsers seem to support it now (though Safari still requires prefixing), it's pretty recent on some of these: http://caniuse.com/#search=flex. Most people still won't feel comfortable using it for probably another year or so, and this is just one element in the Flexbox specification; it doesn't necessarily imply the rest is well-supported or that implementations are reasonably consistent across browsers.
It is recent but I'm seeing >85% of visitors to non-technical sites using a browser which supports flexbox. At that point, using something like a CSS preprocessor to manage the prefixing / older spec support and deploying flexie for older versions of Internet Explorer starts looking like a very reasonable prospect. If your goal is simply to do vertical centering, align elements with consistent sizing, or have the ability to reorder elements in different contexts without having to change the DOM order, flexbox works well in all of the browsers listed at http://caniuse.com/#feat=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.
"Any donkey can kick down a barn, but it takes a skilled carpenter to build one."
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.
The comment you're replying to already contains answers to your points. The complainer mentions his credentials as a programmer, and points out an alternative that exists. You can see that alternative at work by viewing the source of this page.
Well, Paul Graham became popular by writing online essays about Lisp, which was invented in 1960 and went out of vogue during the AI winter of the 1970s. Then he started Y Combinator and wrote Hacker News in a dialect of Lisp. If you think old tech is bad, why are you here? ;-)
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.
1. It's pretty easy to find stories of somebody having success using an old technology, but it's even easier to find examples of old technologies being replaced by something better.
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.
I wouldn't really use reddit as an example of quality CSS styling. Yes, it can be used improperly. It can also be used to create clean semantic HTML. Table-as-layout cannot.
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.
http://gridstylesheets.org/ is CSS with constraints and sugar for things like grid layouts. As easy as CSS in simple cases, but powerful enough to handle more complicated cases that require either elaborate hacks or JavaScript with CSS as it exists today.
Unfortunately in the current climate you're unlikely to see someone even try to develop a competitor to CSS, JavaScript, or HTML.
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.
Part of the achievement of CSS is precisely that they have managed to convince every browser vendor to support it. It has overcome or is strongly competing with Flash, ActiveX, native apps, PDF, and a lot else.
This magical CSS replacement would have to do that, even if CSS didn't exist.
> 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.
With IE10+ silently shipping evergreen by default its hopeful that this part of that problem will go away in the near future.
Do you remember coding rounded corners in HTML? Slicing images, putting a 3x3 table with rowspans and colspans? That was easier than `border-radius: 3px`?
And I have seen no solution for how we might code responsive layouts in pure HTML.
Your making a lot of assumptions, but to be pedantic strait text + links is both pure HTML and a responsive layout. Sure CSS is useful, but IMO most of the pain from HTML / CSS / JavaScript is trying to recreate native application's pixel perfect layouts in a webpage. Also, I think you can embed all CSS functionality into strait HTML5 the advantage is CSS is concise not necessary. Granted, not something you want to create by hand, but if your code is generating HTML anyway it's not such a big deal. EX: <style>
In the end CSS was designed to allow you to swap CSS styles independent of the underlying HTML not add new functionality to HTML.
> strait text + links is both pure HTML and a responsive layout
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, for one, have given almost nothing back to the CSS. I don't read the papers, get involved with testing, implementation, or any of that. I don't even deserve table-based layouts.
Interesting, since table based layout gave such ugly html sources. CSS might be incomplete, and too programmer oriented, but it has some value (it abstracts halfway).
<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>
<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); }
Unfortunately in the reason world you tend to design components that can be used anywhere in the page (and hopefully reused in different pages) so you don't get the freedom to work this way.
Are you kidding? The semantic web was just a bunch of extra junk layers of indirection. Schematize everything, but nothing's actually using the schemata. Replace your <i> tags with <em> tags, because that's more semantic, and easier for a screenreader to interpret (this was a real argument made at the time). Write your actual page as an XSLT on top of what we'd now call your API - but XSLT is barely human-writable, never mind human-readable.
Ah yes, we've at least gotten over the inline css ... although we seem to have gotten back into inline javascript with various ng-click="doSomething()" thingies.
When you do everything from inside JS (as Pete advocates) then you have a real programming language to work with. Inline JS in the HTML is much less expressive.
As I wrote a few weeks ago[1], I hate this way but I can't argue with results. It's quicker and simpler to solve low-hanging fruit this way, which lets me spend cycles on application logic.
He is very much correct in this -- but do note that without the bad parts he dislikes we wouldn't have responsive design today.
It could have been implemented better, but the underlying thinking that users agents should try to programmatically position elements where possible is sound.
I think CSS has become the thing it was supposed to prevent. A modern web page is impossible to render as anything other than a web page; you can't separate the styling from the content, and if anything the complexity of CSS makes doing so harder than in the days of font tags and tables. Users were supposed to be able to override the styles of their pages, but have you ever tried to do that lately? (e.g. I wish I could make all the fixed-width pages on the web full-width).
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 always felt CSS solved the wrong problem. It's too low level -- and it doesn't really help separate content from elements as much as it should. It feels like the designers looked at what people were already doing with tables (forcing old, DTP-style layout on web pages, ignoring the ability of user-agents to prefer how content should be presented) -- and tried to separate that layout out from the mark-up. So you ended up with two types of mark-up, just as with tables, semantic mark-up (h1, p, em, img, a/href, li) and "layout mark-up" (span, div). To a certain extent CSS was successful in making table-markup semantic again. But pages are still evolving away from being easy to parse for content, just as they were with table-based mark-up.
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/ ).
The CSS Zen garden made sense in an age where people hand-wrote their pages. But today any CMS could achieve exactly the same results with plain html + tables - the pages are already rendered on the server (or in Javascript) based on a template + content (probably in markdown or some such).
I disagree. It is much more feasible to have templates and widgets that work across different CMSs and blog platforms, if you can have a common html target to style with css (and enhance with js). And even if you don't think ready-made templates are a good idea (eg: using a layout made for wordpress with ghost, or vice-versa) -- many companies have heterogeneous solutions where the "web site" is actually made up of various independent systems, unified behind a proxy like Traffic Server or Apache with mod-rewrite.
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.
Users were supposed to be able to override the styles of their pages, but have you ever tried to do that lately?
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?
Maybe inline is an extreme example - but suppose we didn't allow the selector syntax, only a simplified form of CSS where the only selector is a single class, and only allowed one class per element? Then the browser could share everything it can share today - it still needs to compute the final style for every element on the page, so the only way it can reuse styling information is if two elements come out with exactly the same style - but it would be much easier to see why any given element was styled the way it was, the browser implementation could be simpler, and our programmatic frameworks for styling components on the page would still be able to help us avoid repeating ourselves.
With regards to separating style and content (and layout):
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.
You could have a semantic relationship between two comments, and then have lots of options for how you want to style it. They're separate. You could draw lines between them, or indent them by various amounts, or draw a box around them, etc. Styling is how you express the semantic meaning in a particular context, but changing the styling shouldn't change the semantics.
Inline style would definitely be a bandwidth hog, that's for sure. As to how much extra bandwidth it would take up and would that make a noticeable difference given that most bandwidth is used for images and video is up for debate.
I think we'd regain any bandwidth cost through compression. Compare the rise of VNC (and VNC-like protocols) compared to X - it turns out there's no advantage to sending drawing commands rather than sending bitmaps, because they both compress to the same thing.
Automatic inlining is used in some contexts, notably emails where everything else works barely-if-at-all.
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.
CSS is problematic in every project I've been on. It takes a lot of effort to stay disciplined and not just throw stuff in a class namespace that shouldn't be there. This article [1] by Nicholas Gallagher sums up how I feel after trying my damnedest to write maintainable CSS in my applications. I'm now using the Suit CSS [2] preprocessor to enforce strict guidelines to our app's CSS. It's working well so far.
"What’s your opinion on pre-processors like SASS and LESS? Does CSS have anything to learn from them?
(...) 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?
single-line comments are already supported in the way that are invalid css :) so if you comment with // the stuff that follow will be ignored.
Again, it is invalid CSS and I am not suggesting that you should use it, just bringing that up :)
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.
Be careful with using // in CSS. It causes some browsers to completely ignore the whole rest of the CSS file after the line you wanted to comment out (iirc IE9 does this).
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.:
If you haven't seen it, it's worth checking out his PrinceXML browser. It's basically an entire web browser that implements many of the CSS working drafts way before any of the mainstream browsers. It's designed for turning html/css into professional quality PDFs, so it implements a lot of the very early print media related working drafts, e.g. the one for running headers and footers, and the one for generating a table of contents automatically from page numbers. Turning analytics data into PDF reports is something pretty much every big company asks for at some point, and if you're willing to spend the time learning all the w3c specs then it's actually pretty viable.
CSS is pretty embarrassing if you ask me. Maybe it was suitable for simple and small document styling for total noobs, ok, but as a standard for web development it's rediculous and sucks all the way... And the worse part? They are still adding to it instead of giving up and leaving it as it is.
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.
Great story. I have yet to think of a valid reason why "box-sizing: border-box" should not be the default. It goes into every CSS document I've ever written.
Then you probably haven't been writing CSS for very long. Its support is quite recent. border-box is a much smarter default, but they'd break a lot of old sites by changing the default behavior.
It's funny—back in the day when IE 6's box-model did it more like this (it was really margin-box, which still doesn't exist and probably never will), I used to say that IE's model, while incorrect was superior. And people would disagree with me vehemently. Now, people swear by border-box, which is much more like the old incorrect IE box-model (for good reasons). But it's funny how anti-IE sentiment overruled common sense.
I was looking for the following points when reading through this interview:
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?? )
> 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?? )
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.
As far as I can tell there are three opinions on CSS:
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.
Somewhat interesting but not very thought provoking. But some of the history of how it came about was nice. After all, he didn't even answer the question about using a magic wand to banish features of CSS. The first two paragraphs are browser features and the third paragraph speaks of adding features.
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.
It's 2014 and browsers are only now starting to add native support for CSS variables. CSS would be so much easier and cleaner if it supported conditional logic (for layouts) and more powerful variables.
I think they should have cloned HTML tables and called it <layout> or something. It's certainly not perfect, but it would have been an easy way to solve a lot of problems.
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.)
> I believe that the CSS code we write today will be readable by computers 500 years from now.
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!
Not sure what you mean. Are you suggesting everything produced today will simply be thrown away? There will be much better computers 500 years from now, but people will still want to see content created in the early days of computers (if only to giggle).
Very interesting to learn that what we now call "responsive layouting" was already proposed in the original document. Of course, at the time the proposal was written the original "the user agent has the final say of rendering decisions" philosophy was still going strong, before the years of rigid pixel-size-everything, "requires 1024x768 or more" mentality borrowed from the print world.
Also, I'm glad that the percentage-based weighted-average influence system did not make it into actual CSS :)
I don't think rigid pixel-size-everything was a "mentality", so much as a way around the lack of min and max-width we didn't have until CSS2. 100% width websites looked bad.
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.
I remember printing up the CSS rules, studying them instead of paying attention in class, and then implementing them on my website...
...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.
Who else is having a "bad css day"? Just spent a few hours nailing down font rendering differences across Internet Explorer versions. Ended up using a combination of conditional statements & weird ms-specific media queries. CSS. Fun for the whole family.
I've never met anyone who likes CSS. Sure, I write it, the people I meet write it and it's unavoidable but it's little more than a necessary evil, as nothing else works on the web.
Regardless of whether you like the technology or not, it's used in virtually every modern computing platform. I'd feel pretty damn good about creating something like that.
Ah yes, the beginnings of Opera, when they had a management that was interested in great technology; before it was exchanged for a management interested in profits.
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...