Venting on CSS
geeklondon.com
geeklondon.com
1. Curvy corners
2. Vertical floats.
3. Formatting for forms.
4. Floats within elements.
http://www.positioniseverything.net/easyclearing.html
5. Graphical Buttons.
http://particletree.com/features/rediscovering-the-button-el...
6. Column support.
http://www.stuffandnonsense.co.uk/archives/css3_multi-column...
http://developer.mozilla.org/en/docs/CSS3_Columns
http://www.quirksmode.org/css/multicolumn.html
http://www.w3.org/TR/2007/WD-css3-multicol-20070606/
7. Order independence.
8. Widths on inline elements.
9. Addressing text within textareas (and other elements).
"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.
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).
2. vertical-align: center; ?
3. i dont have problems with this
4. never had this problem
5. whatever happened to <input type="image" src="bitmapurl" /> or styling <button>'s?
6. css3
7. You must be a rebel, because it's not that hard to follow simple rules for writing out an X/HTML doc.
8. I completely agree!
9. Sure why not?
10. I've already got a mustang.
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.
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.
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!
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.
Look at the RIAA. A model of cooperation.
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?
Given that your question is sitting in html like this:
p < span < td < tr < tbody < table < td < tr < tbody < table < td < tr < tbody < table < center < body < html
org 100h jmp start table1 db 97 dup (' ') table2 db 97 dup (' ') start: lea bx, table1 lea si, string1 call parse lea dx, string1 mov ah, 09 int 21h lea bx, table2 lea si, string1 call parse lea dx, string1 mov ah, 09 int 21h mov ah, 0 int 16h ret parse proc near next_char: cmp [si], '$' je end_of_string mov al, [si] cmp al, 'a' jb skip cmp al, 'z' ja skip xlatb mov [si], al skip: inc si jmp next_char end_of_string: ret parse endp end
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.
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.
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.
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.
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.