the css of tomorrow/grim musings
If you look at what css people write about, there are mainly two types of css articles you'll run into. One type is about bugs, how to fix stuff and workaround methods. The second type is about the future of css. What needs to be fixed, what is missing and where we are going. And once in a while you bump into an article that's basically a sobbing wail of css sorrows. I guess this article is a bit like that third kind of articles.
complaining
Complaining is a form of sanity control. It happens when you need to get something of your chest, and as a css guy you need quite a big chest already to carry all the weight. Apart from IE6 issues (let's say bad browser support in general), people usually like to complain about the slow innovation cycle of html and css. And rightfully so, css is very unlikely to answer to the geek/gadget dna many people in the IT sector hold.
It's not exactly the lack of new ideas or features that is responsible for this lack of innovation, but the immense backlog and serious backwards compatibility constraints that lie hidden within our job. We are still not freed from dinosaur browsers like IE6 and FF2 (who'd still want to use that one?), and until that time, all "new" tricks we use are likely to mess up our sites in those older browsers. It's something you learn to live with as a css developer, grasping at strands (like the new Opera 10 beta - which is nice and all, but does it really chance anything?) but it has a way of sneaking back at you at regular intervals.
A very typical complaint for web developers, but not really what I want to talk about today.
working to a new css future
I'm more worried about the development of css as a professional occupation. People seem so concerned with bugs, browser differences, new features and complaining about them, that they neglect the opportunity to make css a more mature and solid language. From time to time I like to roam around the web to take a look at other people's css. I will not deliver direct criticism here, but in my humble opinion the level of professionalism isn't all that high most of the time.
Even simple things, like structure and clean overview are unaccounted for. Most css files look as if 10 cssers whipped it together in one day trying to reach an insane deadline. Ten year old tag soup is easier to read than many a css file out there. There are no defined sections, css rules aren't logically grouped together and browser fixes are thrown in at the craziest places. Even if basic sections are presents, they are often messed up by people I assume joined at a later time and didn't help with the original css file.
And that's just form. The css itself is often a mess of unnecessary paddings/margins mix ups, filled with obsolete properties (remnants of quick experiments no doubt), badly thought out em/px use and the list goes on. Now, I understand that there is not one way to go about a problem in css, but the difference between method and lack of method is still painfully clear. Most people write css in a way that they go with what works. If it displays okay in browsers, they skip the cleanup process, afraid to break it again.
more, more, more
Sadly, the problem runs even deeper than bad css coding by css authors. I've been running into some structural css issues this last year (the implementation of rounded corners, the issue with sprites and most importantly, the lack of control over collapsing margins). I took the time and effort to participate in the w3 css mailing list, but the reactions were less than satisfying. From the time I've spent there I believe people are more interested in getting SVG graphics in css than solving core problems which are preventing css from becoming a solid, strong language.
It's not that I don't understand the need for innovation, but I fail to see how hard it is to understand that the lack of control over collapsings margins is already a very big issue today. It's very basic css issue that doesn't need 83 live examples to understand the seriousness of the problem, just a very simple sit-down to consider the (future) problems this obvious lack of control has and will have. And it's not that nobody is willing to listen, its just that they seem more preoccupied with other things. So unless you keep spamming and shouting for attention, a simple but crucial issue like this simply falls through the cracks.
conclusion
Bottom line: people seem unmoved by the fact that css is such a mess. Authors as well as developers just go with the flow, rather than make sure there's a solid base to work from. And unless that changes, I expect to keep seeing these chaotic, messed up css wreckages that support the visual presentation of sites in a browser. I believe it's time for more best practices, more core control and more structure. More people that consider the simple issues of css, like whether to use a margin or padding when both solutions are possible. Because there are always pros and cons, and with that preferred methods of working. And all that stuff about SVG graphics, css animation and rounded corners is cool,but not when I have to litter my css with overflow:hidden statements to keep margins from collapsing.
End complaint.
i agree with you. i've often wondered if it would be better to do all one's css in style attributes. and then when ready "compile" one site and have the computer figure out the most concise css for the pages.
on the other hand, css itself could certainly be improved. some things that should be easy are just a pain to achieve.
I think one thing that makes stylesheets spin out of control is there's no clear way to layout your rules. Plenty of CSSers use various methods to organize their rules but there's no obvious best way. Personally, I organize my stylesheet according to the structure of the documents, and even indent to show descendance. It's worked for me for the past couple years but it's not clearly better than sectioning or alphabetic.
It could help to have more ways to refactor. Via CSS variables or even nesting rules. I often use comma separated selectors in order to reduce redundant rules but that just leaves redundant selectors. It's really hard to stay DRY with CSS. If there's more options for simplifying your CSS we might see better CSS.
I'm sure part of the problem is that there's a low barrier to entry for editing CSS. There's 10000 beginners and amateurs for every craftsman. Most of these people will never get good at CSS or even be interested in doing so. Often my opinion with the unskilled is to try to remove the wrong choices or at least make them harder. How do we do that for CSS? What are the bad choices that CSSer's make and how do we make those harder than the right choices?
I really don't care. That is, I always start out with the intention of doing clean css but it always ends up a bit of a mess in the end. But, to me it's a non-issue. I can deal with ten of thousands of lines of css that's total spaghetti and firebug will point me in the right direction.
Bottom line. The VERY WORST css code is a cakewalk compared to spaghetti back-end code. It wasn't always the case pre-firebug though.
It's a little harder for firebug to tell you the unused selectors, redundant and unused properties. If your stylesheet is ridiculous looking at firebug is almost like looking at a stack trace. In any event you're comparing a formatting language with a programming language, big difference.
Still it is a point that even with all the structured niceties of a full programming language people are still going to turn it to a snarled mess.
I really appreciated your comments today on 'object-oriented css' at sitepoint http://www.sitepoint.com/blogs/2009/06/16/first-look-object-oriented-css/, especially about portability vs. re-usability vs. changeability.
I use "location-based" selectors mainly (and I mean derived from the xhtml structure, body classes and so on NOT presentational "float-left" sort of thing), but when that gets unwieldy I've tried a component or modular approach--and, like you say, get hung up on finding generic selectors that aren't tied to styling or affected by content-change or a change in the component's use.
Jethro: not only that, it makes it a lot harder to adapt for someone who needs to quickly change something in the css but hasn't worked on that particular site before. It's not the first time I need to change a rule, then find out there are 4-5 more stringed together to the same set of declarations. Leaving me two options: I can go and find those 4-5 and check if they need to be changed too, or I can pull the needed selector out, getting us back to square 1, unsure about those other selectors. My reason for not stringing css selectors unless the styles should always match, even in redesigns.
Apart from that, strong comments :)
Dave: well you can, but can the next guy. And even though Firebug is a real big help alright, it still gives you information about one page. It wouldn't be the first time I make a seemingly easy fix and break half of the other pages on the site.
I organise my css as much as possible on single-instance rules and their comma-separated selectors: Respectfully, I disagree that that practice necessarily leads to confusion. Quite the opposite, at least for me. Rather than having to familiarise myself with the xhtml structure and what exactly div and classnames refer to before I can understand the css, I can looking at just the style sheets see at once everything floated left, everything positioned relative, or coloured grey to form quite a complete picture of the web sections/pages/site. Inheritance becomes more obvious and mass changes are quickly effected as are single ones because I can safely move them from the rule being certain that I'm not affecting another instance of the rule somewhere else, buried under a selector I haven't found or taken notice of.
I would, however, as I mentioned above in comment #5, like to reduce/reuse/recycle component selectors more effectively than I do now since they are derived mainly from the xhtml structure and that can lead to unwieldy strings of selectors. But, again, reasonable organisation of selectors, linearised, alphabetised and so on, can help the understandability of the style sheet.
It's a question of perspective: to you collapsing margins might be crucial; to me (and seemingly the people on the CSS working group) it's not something I ever worry about much.
... which doesn't really surprise me, since most of what they've been doing seems to be related to spiffy new features, rather than fixing what's broken in the current implementation of css.
Even if you've never worries about collapsing margins before, it's not hard to see there are easy to identify problems with the current implementation. Ignoring those issues isn't exactly the way I want such a group to go about developing css standards.
No, it's still a question of perspective. For you it's not hard to see, but for me it is. I don't see any problems with the current implementation; for me it's a non-issue. Just as you think there are probably people who agree with you that it is a problem, there's probably equally as many who think it isn't.
Collapsing margins is a cool feature, but it definitely feels like one that should be toggleable. Also I find myself wanting to use it for left/right margins when doing floated tiles so that the spacing between elements stays constant. Instead I have to use odd tricks like
margin: 10 10 0 0;and then make special cases for the starting elements. Not the most intuitive way.I do like the
box-sizing: border-box;property. I think it's easier to do the width calculations from the border edge than from the padding. I have no idea why W3 went with the padding line as the width.Mozilla has some interesting CSS extensions including
flexwhich could make good additions to the CSS spec. Worth investigating.You don't see a problem with applying an overflow:hidden or padding:1px 0px to an element for certain margins to take? I'm honestly quite surprised.
To me that's the same as saying you need to apply a background-color first before the css width property kicks in. Fact is that sometimes margins collapse when you don't want them to, and there is no elegant solution or fix out there that solves this. This alone is more than problematic enough, and I believe this doesn't involve any kind of perspective. Whether it's a problem for you personally is not so much the issue here.
You're right, Niels; collapsing margins are the devil and should be dealt with! Having just spent too long trying to fix them and wondering "why"...
* required fields