4 ms·

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

by ionfish 18y ago

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). http://www.positioniseverything.net/easyclearing.html http://www.positioniseverything.net/easyclearing.html 5. Graphical Buttons. What's wrong with the button element? Image replacement works fine for submit buttons, too, as do background images. http://particletree.com/features/rediscovering-the-button-element/ http://particletree.com/features/rediscovering-the-button-el... 6. Column support. 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... http://www.stuffandnonsense.co.uk/archives/css3_multi-column_thriller.html http://www.stuffandnonsense.co.uk/archives/css3_multi-column... http://developer.mozilla.org/en/docs/CSS3_Columns http://developer.mozilla.org/en/docs/CSS3_Columns http://www.quirksmode.org/css/multicolumn.html http://www.quirksmode.org/css/multicolumn.html http://www.w3.org/TR/2007/WD-css3-multicol-20070606/ http://www.w3.org/TR/2007/WD-css3-multicol-20070606/ 7. Order independence. 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.

dcminter 18y ago
To answer some of your direct questions: "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.
- ionfish 18y ago
  "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).

by ionfish 18y ago

dcminter 18y ago

To answer some of your direct questions: "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.

ionfish 18y ago
"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).