CSS can be hard for a programmer. It kinda should. You should be programing. I do CSS all day
Well, yeah. But that's the logic that COBOL programmers used for years and years: "it works well enough." Enough experience can make up for all sorts of design flaws. That doesn't mean that CSS isn't a flawed design.
CSS is a terrible design-by-committee disaster. Is it good to have a stylesheet language to define presentation details? Yes. Is it good to have this stylesheet language? Not so much.
yes it has it's faults. But it has to be designed-by-committee no matter what. While you might only count 3 or 4 browsers as "counting" there are dozens. And if they can't agree on something we will be back to the old days of IE and Netscape. that was truly torture.
Articles like this are always a little shallow and not really informational.
There are plenty of CSS workgroups that can explain why CSS does or doesn't do something. As frustrating as the slow pace of CSS advancement goes they do have smart people trying to do their best to set world wide standards.
Yeah. CSS can be hard for a programmer. It kinda should. You should be programing. I do CSS all day every day and what ever issues CSS have I've long since learned how to work around them to the point where I forget what most of the big bugs are.
I find programing a little daunting sometimes. I don't say it needs to be made easier. If any one can learn programing in a couple hours it probably would not be as powerful.
I'm not sure why you expected an article called "Venting on CSS" to be terribly "informational." It's a rant, duh!
That said, as a web designer, I too know the ins and outs of CSS, and how I can get it to do what I need it to. However, the fact that it can be hacked to do anything is not an argument against making it better and more intuitive. You seem to be saying that, since you know how to hack around the bugs, the fact that they're there doesn't really matter! This is not a matter of the fundamental complexity of a language like this, it's a matter of improving a kludgy way of doing things, and therefore lowering the barrier of entry so that my mom, little brother, and girlfriend can learn to code a website without having to know what "star-HTML" or "double-margin-bug" means, and I'm not really sure why you'd be against that. And yes, I know that it is being improved constantly, it's just painfully slow sometimes.
And since I'm in rant mode now, one of the things I hate about CSS is the box model... the "correct" one, not the ie6 one. The idea that the "width" of an element is not actually it's total width on the page (including border and padding), but the width of the internal content constantly pisses me off. It may be a good idea in theory, but in reality, when you're laying things out, the width of the content area is almost always far less important than the total width, and I hate having to do arithmetic every time I change padding!
Part of the problem for me, however, is that I can't assume that designers know CSS, and I can't assume that the designers will know how to use their tools to spit out CSS that's compatible with the application that it will be applied to. I have no choice but to tangle with CSS whenever I want things to work correctly - and that's my prerogative as a programmer.
Looking at the CSS3 standard, the designers seem to be making mistakes of the "more of the same" variety. For example they are proposing additions to allow for multi-column content, but nothing I can see there suggests that they will allow for an arbitrary number of columns.
Today's frustration is trying to get a textarea to fill the remainder of the page rather than specifying its size exactly. As far as I can tell that's impossible without using Javascript. Why? There's nothing unusual about my requirement - to me it seems that CSS is simply deficient.
Is there a "workaround" for this?
So, to address your criticism of "shallowness" - yes, that's probably fair; I am an occasional CSS user. But still, that's a legitimate usage pattern. Why don't I feel the same sense of crushing frustration when I work with SQL, HTML, or Javascript? I believe it is because they're better designed.
Now, I may be wrong. CSS may be brilliantly designed. If so, I have to assume that I am therefore using it incorrectly or am missing some fundamental philosophy of design that explains everything. If so, most of my "shallow" criticisms should be easy to counter. Are they?
If you just mean that my article is shallow because it doesn't really impart any new knowledge - then why aren't developers up in arms about the awfulness of CSS?
sad but true. I often forget that such a large % of web designer are kinda crap when it comes to the technology that they design for. It's like painting with out brushes. You need to know the medium you work in.
I'm not sure. Maybe you are right - but for me the problem is that the designers that I can afford who know CSS don't produce such pretty designs as the ones who don't.
Perhaps that's my error, but if CSS were easier for me to work with it wouldn't be such a problem in the first place.
So am I being stupid? Is CSS actually easy/rational and I'm just missing the big picture, or is it really kind of flakey and I'm just going to have to lump it?
I'd prefer the "Dave is ignorant" answer to be correct, to be honest, because it at least I stand a chance of rectifying it.
A lot of the stuff you want to do is in the "standard" but you need 3 or 4 browsers to all implement it and do it in the same way before it counts as being truly an option.
I always cringe when I read a "CSS is awful!" article that even mentions table-based layout. The mere thought of going back to building (and more importantly, MAINTAINING) sites with nested tables makes me want to become a farmer. The article has valid points - CSS is far from perfect - but can we please collectively admit that tables are not the answer?
I don't follow you. The question was "can we please collectively admit [that css is better than tables]". The answer is no, not everyone is willing to admit that.
I tried, and evidently failed, to make it clear that I am not in any way advocating a return to table based layout. I'm just frustrated that CSS is so much harder than table based layout to actually implement.
When I see similar frustrations expressed elsewhere, they seem to be roundly condemned with comments of the form "no, CSS is EASY" yet any suggested workarounds for specific problems supporting that theory are of diabolic complexity.
Thanks for clarifying. I just think that a valid case for the shortcomings of CSS can be made without even mentioning tables. And to be honest, now that I really know CSS, it is easier than tables. Tables might be easier when you're dealing with a single page, but any site that has even a slight variation in layouts will be much easier with CSS.
It sounds like much of your frustration has to do with browser inconsistency, which isn't necessarily CSS's fault. Getting things to work on Firefox 3 is fairly easy. Getting it to work on you client's Windows 2000 desktop is not.
"Tables might be easier when you're dealing with a single page, but any site that has even a slight variety in layouts will be much easier with CSS."
That's a valid point. Nonetheless I think that it is also valid to consider the ease with which tables can be used to express layout as a metric for what CSS ought to aspire to.
I think we all agree that we make the effort to avoid using table for layout but sometimes it's the only sure way to get a consistent layout without lots of glue and duct tape.
CSS was originally intended as a text formatting language and it serves that purpose adequately.. not exceptionally but adequately. This is why box widths are internal: it was assumed that the content of a box is more important than its position on the page.
The great tragedy was overloading CSS as a layout language, a purpose for which it is laughably ill-suited. The most trivial layout tasks are so difficult that their implementations must be crafted by master alchemists, named and disseminated to the helpless masses. Even layout tasks that don't require ridiculous hacks must often misuse the language e.g. using float to create horizontal stacks.
The intuitive way to express a layout is something of this sort:
"Box A expands horizontally to fill the page with a maximum width of ### and minimum width of ###. Box A and B both expand vertically to contain their content and the shorter one expands so it's bottom bound is equal to the longer one. Box C is horizontally and vertically centered in box B and has 1/2 its width."
There is absolutely no reason that a formal layout language should not allow you to express yourself this simply. A constraint based language does exactly that. A grid based engine requires more translation effort but is still intuitive and complete. This model is used by most GUI toolkits.
Why do we accept the pathetically underpowered CSS as progress? Perhaps it is the geek tendency to create mental challenges.. or the human tendency to associate suffering with doing good.. or just the job security instinct.
I have a friend who is not technically savvy but has enough of a grasp of tables to make web pages with them, which she used to do quite a bit. Now, she doesn't make sites because CSS layout is beyond her abilities and she feels that the stigma of tables is too opressive. I try to convince her that she is being paranoid but I can't deny that there are many out there who do indeed feel that she should not contribute to the web at all if she can't do it with CSS. This seems to violate the open, inclusive spirit of the web and leaves me sad and frustrated.
As someone who basically thinks CSS is a great idea, I have mixed feelings about this article. On the one hand it's a rather silly rant, and is downright wrong in several places. On the other hand, CSS has a number of irritating limitations. However, overall I'd say that the real problem is the dog-slow speed of inclusion of new CSS features by certain browser developers, and the even more glacial up-take of more modern browsers by a large class of users. A lot of the real problems in the article would be solved by people ditching Internet Explorer. As it is, I spend an awful lot of my time writing workarounds for its broken DOM and box model.
1. Curvy corners
I'm not sure what the author's obsession with JavaScript fixes is. There are plenty of pure CSS rounded corner implementations. However, they are universally horrible, involving large amounts of junk markup and/or image backgrounds.
2. Vertical floats.
What do floats have to do with vertical positioning? The problem, however, is real enough. This one is a perfect example of the "We could do this easily with tables" class of CSS layout problems.
3. Formatting for forms.
In this case, the author doesn't go far enough. Laying out and styling forms with CSS is a horrible job; at work we have an entire JavaScript package to help out. As far as layout goes, though, a few floated divs tend to deal with most problems. The real problem is when you don't have control over the markup, for example when using the auto-generated forms coming out of a CMS.
4. Floats within elements.
Not really sure what he's complaining about here; this is just how floats work. They take elements out of the document flow. There are various ways of clearing internal floats. I tend to use Clearfix, but overflow:auto is good too under certain circumstances (for example, if you're absolutely sure that nothing is going to go beyond the bounds of the container element and thus cover the page in scrollbars).
This one is interesting. While I broadly agree with the author, there are some issues. The first is that even if a column specification makes it into CSS3, it still won't work in Internet Explorer 6 or 7. The second is that there are actually multiple, competing column specifications. Unfortunately we're going to be waiting a while for this one. I do, however, wonder if it can really be as easy as the author supposes...
Mixed feelings here. There's support in CSS for a certain amount of order independence, but it requires one to use a lot of floating or absolute positioning. Plus, of course, the point of HTML is to mark up a document. The presentation should mirror or enhance the structure, not change it, and order is surely part of that structure.
8. Widths on inline elements.
Pretty sure this is what display:inline-block is for.
9. Addressing text within textareas (and other elements).
What does this have to do with CSS? But yeah, let's hope that some decent forms enhancements makes it into HTML5 in 2021 or whenever. Until then, we have JS frameworks to hack around the massive limitations of the DOM.
"I'm not sure what the author's obsession with JavaScript fixes is"
Well, I'm not sure "obsessed" is the right word. But when I try to find the solution to any given CSS problem the answers seem to fall into three boxes:
a. Put markup in to manage the problem.
b. Weird hack.
c. Javascript
Of the three Javascript is the most elegant except that it stops working if (duh) Javascript is disabled. So my focus on it is more about discarding it out of hand as being unacceptable (whereas the other two options are merely, as you point out, horrible).
"What's wrong with the button element?"
Thanks for the link. It looks like I'm just wrong on this point (or maybe out of date, but that's still wrong).
"In this case, the author doesn't go far enough." (on forms)
Well, the post was getting a little log (perhaps not by Yegge's standards though) and also I worry about my blood pressure whenever I think about forms and CSS.
"Pretty sure this is what display:inline-block is for."
Ok, probably another place where I'm just wrong. The more of those the merrier from my point of view.
Thanks for the reply - there was some really helpful stuff there.
"Of the three Javascript is the most elegant [...]"
Oh, definitely. When I'm doing a personal project I tend to just not bother with niceties like rounded corners for IE users, and as long as the content's still accessible I'm not too bothered. This cuts down on the number of times I need to add junk markup, weird hacks or JavaScript (or, more usually, some combination of the three).
At work, we tend to try to do as much as possible with CSS and HTML, since in the end most DOM manipulations done with JS are still changing CSS-accessible properties. The other day we had a client who wanted the bottom border of several columns with different heights aligned. This isn't possible in CSS (although, of course, it was very simple with tables), at least if one is still supporting IE6, as we are, but a few lines of JavaScript sorted it out pretty sharpish.
In other words, best practice as far as I'm concerned is to leave JavaScript out of the picture as long as possible, at least where styling or layout enhancements are concerned. This means that users without JavaScript (a very small number, admittedly) will get the best possible experience, and more importantly, it means your JavaScript and your styling are as loosely coupled as possible. That's not too important for a small site, but on a big one where you have to maintain it over a number of years, it becomes absolutely vital (in this way it's no different from any other kind of programming).
I'm curious then - could you explain how you approach CSS based layout for forms? Drop me an email (dave@paperstack.com) if you want to discuss it offline.
I use lists to layout forms, other people use tables. Forms can be a beast! It helps if the designs have been done with the 'web' in mind and not just what looks pretty on paper.
As noted by others here, CSS3 style columns are supported in Firefox with a -moz prefix. In my opinion the implementation is barely usable though, because if you have too much text to fit onto the page they overflow off the bottom of the page instead of off the right hand side.
I seriously wonder if the CSS standards group has any loud voices from anything other than a static-content background because everything makes perfect sense if and only if you know exactly what will be on the page.
Well, yeah. But that's the logic that COBOL programmers used for years and years: "it works well enough." Enough experience can make up for all sorts of design flaws. That doesn't mean that CSS isn't a flawed design.
CSS is a terrible design-by-committee disaster. Is it good to have a stylesheet language to define presentation details? Yes. Is it good to have this stylesheet language? Not so much.