The postings on this site are the contributor's and don’t necessarily represent IBM’s positions, strategies or opinions.
May 17th, 2009 Alex Moffat Posted in CSS | 5 Comments »
I’v recently been looking at the CSS guidelines from the Yahoo Best Practices for Speeding Up Your Web Site document. What we do for Blueprint is use a number of separate CSS files during development linked together via @import statements. As part of the build process a single CSS file is created for each page by combining the individual files and running the result through the CSS compressor that is part of the YUI Compressor. The name for the combined file is formed using a hash of its contents. This means that whenever the contents changes the file name also changes so we can tell the browser to keep the file permanently cached and still be sure we pick up any style changes.
Just recently I’ve been experimenting with data:url to inline background images into the CSS file. This reduces the number of files the browser has to download, especially in the empty cache situation, and provides caching benefits. After the compression step the build process looks at the CSS and replaces any references to images with a inline data:url, if the size of the image is less than 2k. This works fine for browsers apart from, of course, IE7 and below, which don’t support data:url.
There is a very ingenious solution for this problem using mhtml. I managed to get this partially working but in the end decided to give up for now. The biggest problem is that the url for the background images has to be absolute, at least that’s what I’ve found. You have to write something like url(”mhtml:http://my.css.com/somefile.txt!img001″) to refer to an image. This means you can’t use the same CSS file in system test and production. You either have to have it served dynamically so that you can substitute the appropriate host name, or rebuild the file for production. An alternative would be to try and use CSS expressions in IE to substitute the correct host name on the client. None of these was appropriate for me so I decided leave the IE6 and IE7 CSS alone for now. Along the way I did rediscover one thing that I’d forgotten, and that wasted some time for me, the newlines in multipart/related are actually carriage return newlines, so \r\n instead of \n. Without that nothing worked.
June 18th, 2009 at 5:35 pm
Alex,
Have you looked at ClientBundle (available in GWT trunk)?
http://code.google.com/p/google-web-toolkit/wiki/ClientBundle
In particular the capabilities for CSS resources?
http://code.google.com/p/google-web-toolkit/wiki/CssResource
I believe we cover or are at a minimum have considered each of the above issues as part of the design.
If there’s additional room for improvement, we’d love to hear about it.
Thanks
Fred
June 18th, 2009 at 9:44 pm
I have looked at the CSS resources, or at least read about them. I even went so far as to implement a similar thing myself that used a generator to embed CSS into the GWT created JavaScript using the ideas of style injector. The main problem I have with CSS resources is that it requires, as I understand it, the generator to run to produce the final CSS. We don’t have out of process hosted mode at the moment so having to effectively recompile in order to test a CSS change in any browser not supported by the platform hosted mode is a complete non-starter for us. With files it’s a simple refresh to see the effect of any changes. My embedded CSS solution had two modes, one that injected the style inline with a style element, for production, and one that injected link elements instead for development use. We handle browser specific CSS with separate files. I still feel, though I need to test of course, that using a link element in the head to pull in a single compressed strong named cached browser specific CSS file is going to be faster than injecting the style in the onModuleLoad method.
Another, though not so serious issue, is that images referenced in the CSS file are going to be loaded from the same server as the javascript. We try to serve images from a separate server so as to limit the impact of IE6’s two connection limit. Using absolute URLs in the CSS would get round this but then you need to rebuild for production instead of being able to use the same code you tested with.
On the other hand, constants in CSS, I would really like that and the other features look useful as well. Once we get out of process hosted mode maybe I’ll look again. I’d still like it if the CSS could be output as a file though for inclusion via a link.
September 28th, 2009 at 6:28 am
I discovered this problem with IE7 on XP, have you any input on this?
http://www.phpied.com/mhtml-when-you-need-data-uris-in-ie7-and-under/#comment-71551
September 29th, 2009 at 9:14 pm
Sorry, but no. I gave up on mhtml data uris when I ran into problems with generating the right format to use both in system test and production deployment environments. I never got into the other situations where it won’t work.
February 6th, 2010 at 10:36 pm
[...] CSS using data urls. I wrote a post earlier last year describing how as part of our build process the CSS is combined and compressed and images are inlined where possible. The CSS file is given a strong name using the same technique as the GWT generated JavaScript files [...]