Digital Web Magazine

The web professional's online magazine of choice.

RESTful CSS : Comments

By Steve Heffernan

November 18, 2008

Comments

Andrew Jaswa

November 18, 2008 10:12 PM

Steve, could you explain how this is useful? I’ve read over your article and, while it is neat, I can’t find any production worthy use out of this. It seems that using an intelligent structure for your CSS would go farther then making it RESTful…

I don’t want to knock RoR folks but they seem to want to do everything through their frameworks while ignoring the built in power of the tools that they are using. In this case failing to utilize the cascade of stylesheets.

Hrvoje Blažeković

November 18, 2008 11:48 PM

I prefer using one style sheet, but then I do make sub groups of rules that apply only to desired pages identified by the body ID (eg. <body id=“edit”>).

This article is interesting and gave me some ideas how to further optimise my style sheets, but I do not agree with You on making separate css files for every new page type.

Andrew Ingram

November 18, 2008 11:55 PM

The definition of REST is completely wrong in this article. That’s not to say the article doesn’t have value, it’s just not REST.

Ross Bruniges

November 19, 2008 12:13 AM

This seems like overkill and over-engineering on a pretty major scale and clearly a technique created by developers to make CSS ‘easier’.

I like the idea of splitting up your CSS into separate files per section; it’s a great way to cut down on in-dev issues and regression bugs but then tying (essentially hard-coding) this sheet to one specific view seems a bit dumb and will lead to lots of duplicated CSS IMHO.

Also the fact that CSS can’t be merged and concatenated makes this technique fairly useless for high performance sites or those with ambitions to be so therefore on that I cry FAIL!

Kari Pätilä

November 19, 2008 12:26 AM

Is it just me, or has the quality of Digital Web, along with A List Apart and Smashing Magazine with the ridiculous “10 advanced php tips”, gone rapidly downhill during the last month or so – especially when it comes to performance realted issues?

It makes me wonder if the lessons from High Performance Web Sites have been left unnoticed on purpose by those whose opinions matter a great deal to the newcomers in this industry.

Ross Bruniges

November 19, 2008 12:27 AM

@kari – could not agree more with you! Well said.

Lar Van Der Jagt

November 19, 2008 12:30 AM

Gotta agree that this has very little to do with REST. The seven “RESTful” actions are just one small part of what makes REST what it is.

I do however thing that the Rails conventions do offer some great ways to organize CSS, using controller & action names as namespaces. To do this I just stick the controller and action name into my body (or some other top level element) as multiple classes. So you would have <body class=“controller action”>. I use a simple page_class helper method to accomplish this. Then when defining styles, you can still take advantage of the cascading nature of CSS.

Matthew Pennell

November 19, 2008 1:45 AM

@Andrew Jaswa: I think you probably mean specificity rather than the cascade. As Steve notes in the article, the technique may not be for everyone. In this case it is replacing large, specificity/inheritance-based CSS files for smaller, cascade-based stylesheets.

@Andrew Ingram: I’m sorry you feel that the article incorrectly describes REST. I think Steve’s characterization of RESTful principles reflects how a designer working on an MVC framework might think, being largely concerned with the templates/Views only.

@Ross Bruniges: As Steve notes, this technique shouldn’t lead to duplicated code — any situation where you are writing duplicate CSS for different views would mean that that CSS should probably be moved into the global stylesheet (application.css in Steve’s example) instead. The article also notes the concerns and drawbacks when it comes to your ability to concatenate files — as I said, the technique may not be suitable for all sites. If minimizing the number of downloads is key (as it will be on a high-traffic site), and there is no benefit to separating the CSS for high-traffic Views (e.g. an application Dashboard) from other, lower-traffic Views, then don’t use it!

@Kari Pätilä: It’s easy to snipe from the sidelines — all the publications you mention would be happy to hear from you with an article proposal of your own. Steve’s article does not ignore the issue of performance — but equally, high performance should not be the only metric one uses to judge the success of a technique.

trovster

November 19, 2008 5:27 AM

This is a useful tip for organising your CSS. I don’t see it as anything new, actually, I was implementing this last night on a new version of my site, and do it all the time at work. It’s just nice to keep styles for their sections (or controllers in the MVC case).

I am using Zend Framework for my new site, I am defining the controller stylesheets in the preDispatch controller, in a dispatch plugin. This can be broken down in to development mode and live trunk – where you can combine the files in to a single file if you wish.

The articles doesn’t touch on the issue of performance, as Matthew says. But it also doesn’t say ignore it. It was talking on a specific topic. You, as the performance-guy, can and should make those decisions. You’re not telling me you develop “in performance mode” as I just don’t think that is wise. Performance can be optimised post-development (although knowing the gotchyas and rules while building is a must), but making you jump through hoops when developing just slows the entire process down.

Bradley Wright

November 19, 2008 5:57 AM

This article seems like a beginner’s article on “modular CSS”. I’m all for tying CSS to particular modules or applications within a site, but I think it’s very dangerous to consider rendering just the ones you need per page. That’s actually a performance bottleneck.

In this day and age of post-YSlow performance emphasis, writing articles which make it actively impossible to reduce HTTP requests per page (and worse, duplicating requests across pages) by citing developer ease seems like a somewhat naive notion, and certainly one that should not be posted in a publication like Digital Web. The YSlow guidelines don’t exist for the purposes of theoretical perfection, but to actively improve the user experience by making sites download faster and cache better. You might as well say throw away user experience design as say basic principles of performance cannot be followed because we follow a particular development methodology. After all, we’re building these things for people, not for our own self-gratification (that’s a bonus).

Andrew Jaswa

November 19, 2008 7:47 AM

@Matthew Pennell So let me get this right… You think that the cascade is not influenced by specificity? Because the cascade only works because of specificity… And implying that I don’t know that. It seems your own ignorance is coming into play here. That’s not cool Mr. Editor in Chief, from a new reader of your publication.

My question still stands what, if any, practical production application does this have?

Matthew Pennell

November 19, 2008 8:08 AM

@Andrew Jaswa: My understanding of the various terms used within CSS is that specificity refers to how specific a particular rule is: elements vs. class names vs. id names and so on. The cascade refers to the broader picture of ‘nearness’ to the element being affected: inline styles trump styles in the head, which trump styles in external stylesheets, of which later ones override earlier ones (with user stylesheets overriding all). Specificity is part of the cascade, but not analogous.

As Steve’s technique relies on the cascade to work — loading multiple external stylesheets so that later ones can override rules in earlier ones — it obviously doesn’t “fail to utilize the cascade”; I assumed you meant specificity instead, as that is how most single-stylesheet sites apply rules to particular, specific circumstances. My apologies.

Steve Heffernan

November 19, 2008 12:21 PM

Wow, such passion! The main benefit I find when using this structure is that when styling a specific action, I can treat it as if it houses the only pages on the site and use very simple selectors. My stylesheets are concise and focused, and I enjoy working this way. It does require a slightly different mental strategy, which may be uncomfortable for those who are used to working with only global stylesheets. However, I imagine if you attempt this on your own RoR app, you may at least see why I appreciate it.

Some commenters seem to have gotten the wrong impression that this method prevents you from doing any kind of concatenation or compression. All global stylesheets can still be concatenated and compressed. Action and controller stylesheets can be compressed individually. Site-wide performance differences would be minimal at most, and entry page performance may actually improve as styles are distributed to later pages of the site where global styles have already been cached. I touched on this in the article, but apparently not enough.

@Andrew Jaswa: This method absolutely relies on cascading, allowing action styles to override global styles. So your knock on RoR developers is somewhat unjustified. As far as “production worthy”, I’ve hopefully explained why it shouldn’t be much different than your current method. So you’ll have to decide for yourself if it would add any benefit to your workflow, though it doesn’t sound like you’ll be building a RoR app anytime soon. :)

@Andrew Ingram and Lar Van Der Jagt: My definition of REST is not wrong. Yes, this method only deals with a small portion of REST, but it deals with the part that has the greatest impact on site structure and therefore CSS. I’m sorry if you think I took too much creative license with the title.

@Bradley Wright: I’m aware of the YSlow guidelines, and judging by your passion for them, I’m going to guess you work for Yahoo. Congrats! In typical situations this method would add an HTTP request to sub pages of a site, but not to the homepage, where it would actually reduce the size of the stylesheet loaded. I’d be interested to know if you think there are any scenarios where that would be a benefit.

@Matthew Pennell: Thanks again for taking a chance on an untested author, and I apologize for the flack you seem to be receiving for it. I applaud you for attempting to expand the content to a slightly different audience, and I hope this article doesn’t dissuade you from doing it again.

You all seem to be intelligent and passionate about the topic of CSS, so I encourage you to contribute back with your own articles and give Matthew more to choose from. Otherwise you may see another one from me. :) There’s no money in it, but even with the negative feedback I’ve still gotten a lot of satisfaction out of it.

Bradley Wright

November 19, 2008 12:33 PM

I’m aware of the YSlow guidelines, and judging by your passion for them, I’m going to guess you work for Yahoo. Congrats! In typical situations this method would add an HTTP request to sub pages of a site, but not to the homepage, where it would actually reduce the size of the stylesheet loaded. I’d be interested to know if you think there are any scenarios where that would be a benefit.

You’re only half correct – I used to work for Yahoo!, and no longer do. So thanks for the unnecessary congratulations. One of the reasons I’m passionate about them is not, in fact, a corporate shill. I have nothing personal or professional to gain from blathering on about YSlow other than what users get out of it. I’ve seen the amount of testing and metrics that go into creating standards like YSlow, and I can guarantee that all the guidelines are sound from both a quantitative and qualitative metrics view.

I’d like to address your point about the homepage – as frameworks allow us to create better and more search crawler friendly pages, the likelihood of the homepage being the major source of your traffic are slowly dwindling. So you should be optimising for all pages, and not seeing a smaller homepage footprint as necessarily a benefit (in and of itself it is a benefit, but becomes less so once you consider deep linking/crawling). If you went the full YSlow dogma route and optimised the homepage, you’d likely be embedding your CSS inline to prevent the DNS/HTTP overhead anyway.

Andrew Jaswa

November 19, 2008 12:44 PM

@Steve Heffernan, I guess how I worded it was wrong. What I mean is that you are solving a challenge that is already solved within CSS itself. I’m not trying to be negative I just don’t see how this solves anything that isn’t already built into CSS.

As far as being unjustified, I think its pretty fair to say that programmers (RoR or otherwise) tend to try to solve problems with programming. Which I can’t blame them because its what they know.

Matthew Pennell

November 19, 2008 2:05 PM

Bradley:

as frameworks allow us to create better and more search crawler friendly pages, the likelihood of the homepage being the major source of your traffic are slowly dwindling

I guess the benefits or lack thereof come down to your definition of an application. If you’re building what will become a ‘regular’ website (e.g. a CMS in Rails), then I agree that assuming your homepage will bear the brunt of traffic is probably wrong. However, if you’re building a “web app” — say something like a personal finance application, where 90% of user visits are to check the dashboard and nothing else — then the benefit in reducing the size and complexity of that homepage’s CSS increases.

But, as you say (and as YSlow/Souders notes) you’d then perhaps be in the realm of inline CSS anyway. :)

Lar Van Der Jagt

November 19, 2008 3:00 PM

Just wanted to clarify that I wasn’t saying your definition of REST was wrong, just that it is incomplete. I am also not sure that the term fits here. IMO you are taking advantage of REST conventions, but there is nothing particularly RESTful about this technique. The only reason I bring it up is because REST is already hard enough for newbies to understand as it is, and appropriating the term for concepts only loosely related to REST can only add to that confusion.

Steve Heffernan

November 19, 2008 4:37 PM

@Bradley Wright: Just to clear things up, I have nothing against the YSlow guidelines. I feel indebted to Yahoo for doing the research behind them. And yes, I am a sinner. I added an HTTP request and hellfire should rain down on me. But let me build on Matthew’s point, and maybe I can at least get you to say “It’s not as bad as I thought.” Many if not most Ruby on Rails apps require you to log in either through the homepage or the login page before reaching a sub page. If neither of these pages has an additional HTTP request, and the number of styles loaded is actually reduced on these entry pages by distributing them to other pages, is this still the most horrible thing ever? I don’t think you need to totally sacrifice the performance of sub pages by using inline CSS, but in this scenario it seems there could be some benefit to allowing sub pages to carry a little more of the load. If I’m totally wrong about this I’d love to know why.

@Andrew Jaswa: I think I understand what you’re saying, and I’m really not trying to fix anything with this article. I’m merely proposing a different method for organizing CSS and utilizing the cascade. I don’t feel like I’m trying to avoid the built in functionality of CSS, just using it differently.

Jeethu Rao

November 19, 2008 10:56 PM

The idea is something similar to what I’ve been doing in the django. All I wanted to say was just because you’re splitting style sheets into multiple files, it doesn’t mean that you can’t automatically concat and compress stylesheets on the production server. Check out django-compress .

I use a slightly souped up version of django-compress to have a whole bunch of css %} blocks and one final {%compressed_css “compressed_?.css block. In debug mode, it just serves all the CSS files as is. In production mode, it checks if the compresed file exists, if not it queues up a job to concat and compress the files (with yui-compress) and serves all the css files. The next time, since it finds the file, it serves the compressed file. The compression and concatenation is done out of process.

Yeah, I know that it sounds like an ugly hack, but it works beautifully well.

Kari Pätilä

November 21, 2008 5:43 AM

@Matthew Pennell In my previous comment I probably should have just noted that it really irks me to see a trend of slicing up CSS files on the rise.

And as far as the sidelines are considered, an article of mine on designing for performance did result into some back and forth with an editor at A List Apart. I guess I could have Digital Web review it as well, since I haven’t heard from ALA for a while.

minimal design

November 24, 2008 7:34 AM

Since I’ve had to bash the latest DW articles on CSS which in my opinion were subpar (I still cringe thinking about “all you know about CSS was wrong”…) I thought I’d chime in to say I enjoyed this one. Most issues I can see with this technic were addressed by the author. Although you can argue wether or not this setup is appropriate for CSS, it was interesting to read about a different way of doing thing from someone who actually put some thought into it, and some effort in describing it in great detail.

Thanks to the author and hopping DW keeps it up!

Alistair Holt

November 25, 2008 3:00 AM

This seems completely useless and ugly to me. Why should an MVC structured app reflect how the CSS is written? It shouldn’t! There are better ways to organise CSS than this that are more effective and easier to maintain.

Dave

November 25, 2008 5:44 AM

Wow! That is just HORRIBLE!

Andrew Brown

November 25, 2008 9:31 AM

An interesting attempt to organize your css files, but I’ have to agree with most of the posts in the article that this isn’t practical and too granular to be considered useful. I would only go as far as creating a stylesheet for each controller.

Andrew Cairns

December 11, 2008 8:18 AM

I have experimented with this technique in the past which also considers which browser the user is using and buffered the whole contents into one file request.

This technique proved to save time when developing for cross-browser compatibility, however creating the number of files required in this implementations looks tiresome.

I do believe some form of dynamic CSS will present itself in the future. Good article and a nice read :)

Sorry, comments are closed.

Media Temple

via Ad Packs