How is this module different from ie_css_optimizer ?

I would also like an answer to that question.

Link to the project page:
http://drupal.org/project/ie_css_optimizer (IE CSS Optimizer)

----------------

ie_css_optimizer provides an option where it will compress some of your css files, and leave only the theme css uncompressed. If you choose that no css should be compressed, the site will still break in IE.

unlimited_css links the uncompressed CSS files with @import statements, so that you can have a very high number of uncompressed CSS files, and your site will still work in IE. This is not possible with the other module.

EDIT:
This explanation is wrong, as you can read below in #4 - #6.
Main issues:
- official release for unlimited_css is broken. you have to patch it, or use the -dev version. And this patch is a complete rewrite.
- ie_css_optimizer does exactly what the patched unlimited_css does, with a few details being done differently, and some extra features.

Probably the module description of ie_css_optimizer was different when I wrote the above reply, or I even wrote it months after reading the ie_css_optimizer module description.

UPDATE:
Fixed version of unlimited_css is now published as an official release (since 14 July 2010).

Thanks for the good explanation donquixote.

Thanks for the good explanation donquixote.

Except that donquixote is completely wrong about what IE CSS Optimizer does.

IE CSS Optimizer provides an option where it will compress all module css files, and leaves only the theme css uncompressed.

It will also count the number of theme stylesheets; if that number reaches the IE 31 stylesheet limit, it will load the additional stylesheets using @import method. If the theme stylesheets do not reach the 31 stylesheet limit, the stylesheets will continue to be loaded with the standard <link /> method which is more compatible with javascript development. (using @import causes stylesheets to load in a different order on some browsers. See http://www.stevesouders.com/blog/2009/04/09/dont-use-import/ )

Oh, also, IE CSS Optimizer is not buggy. While the IE Unlimited CSS Loader module has lots of bugs such as this critical bug: #693180: Overriding module CSS files does not work with unlimited_css

Sorry if I misrepresented your module, John. The information was based on the ie_css_optimizer module description as it was few months ago, or the way I read it. Well, I guess I did a very bad job reading this module description.

It will also count the number of theme stylesheets; if that number reaches the IE 31 stylesheet limit, it will load the additional stylesheets using @import method.

Which leaves us with a mix of <link> and @import. Somewhere I read this is bad, but I don't remember who exactly wrote that. There was a lot of talking in #228818: IE: Stylesheets ignored after 31 link/style tags. Also, the stevesouders article was heavily debated there.

We also talked about a "magic number", a limit that has to be significantly smaller than 31, to allow for css includes that are hardcoded in page.tpl.php, that Drupal does not know about. I don't know if ie_css_optimizer does that, otherwise this could be a feature request.

The main argument in #228818 against @import was performance - and there was the very valid counter-argument that we only wanted to use @import if aggregation is off - so performance didn't really matter that much.

the standard <link> method which is more compatible with javascript development. (using @import causes stylesheets to load in a different order on some browsers

This is new to me, and definitely more valid arguments than performance!
Can you explain more about this?

IE Unlimited CSS Loader module has lots of bugs such as this critical bug

... except that there is a pending patch that completely rewrites the module and probably fixes a lot of the bugs. Works like a charm on my own sites.
It's a shame this patch is still not released into a stable version of this module. You should definitely look at this patch for any valid comparison. The current official release is badly broken, 100% agree with that.

The patched version has a magic number of 22 (which we will only ever hit if aggregation is disabled). It does not mix @import with <link>. This is because someone in #228818 said that all-import would be better than a mix of both.

----

Both of the two modules use hook_preprocess_page to alter the css, which does only work if other modules don't override these changes.

Otherwise, the main differences are:
- mix of @import + <link> (ie_css_optimizer), vs just @import (unlimited_css), for the case where we hit the "magic number" of stylesheets. I'm not sure which strategy is better.
- magic number 31 (ie_css_optimizer) vs magic number 22 (unlimited_css).
- official release vs patch/dev release. UPDATE: Both have an up-to-date official release now.

I personally feel quite comfortable with my patched version, but probably this is because I did it myself :)

A new release is just out including donquixote's patch, thanks about that! I agree that using @import is not the best solution, this module is really meant for development use only, once you go live you turn CSS compression on and you are done. For any other use cases, or if you have got any problem with unlimited_css, http://drupal.org/project/ie_css_optimizer is a great alternative.

Thanks!

I agree that using @import is not the best solution

It is the best solution, in those cases where we use it! (only question is mixed vs import-only).

this module is really meant for development use only

The good thing is, you can leave the module enabled when the site goes live, because it only does what it does when it's necessary.
(the same is true for JohnAlbin's module)

See also #698492: is this module better worse than the other alternative (unlimited css loader)?

Seems to be facts of live; why can't people who develop almost the same module not work together in one single module? And maybe some additional synergy and expanding this modules features; 2 people together can do more work than both single together:
http://en.wikipedia.org/wiki/Synergy

So I can add this module to my list of hundreds of modules I have to test in the next 1-2 years and try to figure out what in practice it does differently than IE_CSS_Optimizer.

Or am I mistaken? Probably not as logical thinking programmers of course must have thought about this a long time before I mentioned...

Please, don't do this "teacher mode" thing.
As I understand, the two modules started from different points, so it was justified to have two of them. Maybe one day the few ideas that still make unlimited_css different (magic number 22 vs 31, all @import vs mix of @import and link) will be added to ie_css_optimizer as optional features. Until then, it's perfectly ok to have two different modules.

2 people together can do more work than both single together:

This is a not always the case.