No problem; on the contrary, I did want to know more!
Thanks for the explanation, it sounds great!

However, this is totally different from Dean’s one, and I think his algo is able to create more compact results (I focused more on compatibility with “strange” code) … anyway, what’s packed.it can do, and no other compressors can yet, is to produce a single file merging both JS and CSS that will use the same keywords list (think about div.classname {} in CSS and the usage of “div” or div and getElementsByClassName(”className”) in JS … these words are both from a single list).

This simply means than in a single file you can serve entire libraries and their dedicated CSS, while JS not comaptible or disable browsers will download only one or more basic CSS (try to disable JS in packed.it and look what do you download when you have JS enabled and what’s different when JS is disabled).

Sorry Robert, I know this is not the right place to talk about packed.it … but hey, it was your fault, you asked? I replied

Thank you!

Andrea,

Ha ha! Well, yes, I do think it’s very important to support Conditional Compilation as well. If it isnt fixed, I might consider testing another compression method.

Out of curiosity, how does packed.it stand against Dean Edward’s Packer?

Tanny,

That is changed since a couple of weeks, and will be in the next upcoming release, since 64-bit support should of course also be in there.

Regarding compression, I’ve been very happy with the mindset and result of YUI Compressor, although I’m sure packed.it is very competent. The minifying problem is still there, though, so well see if I will change it.

I do not use YUI Compressor, but if this does not do nothing with conditional comments (too simple in this way, guys :D), it means that packed it could produce more compact code, for the simple reason that @cc_on contains JavaScript, the same javascript that could be minified outside the comment.

I would like to mantain this feature, since CC are widely used and with 3 IE box models (8, 7, 5.5 or whatever is it), libraires.Next will use them more each new release ( IMO )

P.S. … ooops, does YUI Compressor use Rhino and does not Rhino is compatible with IE cc_on code? … he, he, he

Thanks a lot!

Thank you!
It is very interesting that you mention this, since I’ve considered it for some time (but never gotten around to testing it). The DOMReady function, as I’m sure you’re aware of, is heavily influenced by the work of Dean Edwards and others with window.onload (again).

My thinking has more been that they have tested it thoroughly and therefore have been a bit reluctant about changing things.

But just as you say, the above code really should work, and if nothing goes wrong, I will include it in the next release of DOMAssistant (which will be out in a week or two, and have some nice things; stay tuned ).

Regarding compression, I’ve been very happy with the mindset and result of YUI Compressor, although I’m sure packed.it is very competent. The minifying problem is still there, though, so well see if I will change it.

I have only one comment about one single piece of code …

/*@cc_on @*/
/*@if (@_win32)
if (document.getElementById) {
// doStuff
}
/*@end @*/

could you please avoid open + open / close or nested conditional comments?

What I mean is that this should does exactly the same thing
/*@cc_on
@if (@_win32)
if (document.getElementById) {
// doStuff
}
@end @*/
but it makes life easier for both non-IE browsers, during comment parsing, and “minifiers” as well.

Switching them I’ve successfully parsed the full file into 7.3 KB, using packed.it service.

I know you had problems as well, that conditional comment is not minified as expected even in your compressed version, while packed.it is able to minify conditional comments as well, there’s javascript inside

Your nested open without close case scenario is quite hard to understand correctly. However, did I say good stuff?

Kind Regards