Eesh -- no, AjaxMin should not be falling over on code like that. It should throw an error, but it should still produce valid output (maybe just not as optimized as it could be). I'll get on that.

Running that line through AjaxMin, I don't see the tool "fall over." I get the expected error message:

missing-value.css(1,64): run-time error CSS1036: Expected expression, found ';'

And the resulting CSS is:

.ui-widget{font-family:Verdana,Arial,sans-serif;font-size:}

Isn't that what you expect as well?

Just curious.....since it is obvious that having proper JS or CSS syntax is not a prerequisite for minimizing the code......what is the purpose of checking the JS or CSS syntax ?.....is this purely for the programmer's benefit ?.....to help weed out any potential problems ?

I am coming from a very old version which did not conduct syntax checking.

Thanks

I actually find it interesting that an older version wouldn't throw error messages for you -- if it didn't throw an error around an issue, it usually just hung or otherwise crashed when the syntax was bad. Over the years it's been an uphill battle to make it gracefully handle bad code, and I'm not anywhere near where I'd like to be on that front.

But to answer the question, AjaxMin is meant as a build-time developer tool -- a combination of minification and lint. Here at MSN, for example, we have the warning level cranked up so high, your code will fail the build if you check in anything that causes even a style warning. It has always had those two purposes tied together, though, and I'm not all that fond of the combination, to be honest. It [should] always report syntax-level errors because if it didn't, you could minify your source code and get garbage back and not know why (nor even have any indication that anything went awry), since it's not all that great at handling syntax errors. The CSS parser is custom to AjaxMin, so I think I've gotten better at being forgiving of errors. The JavaScript parser is still based on the old ROTOR sources, and it's not anywhere near as forgiving, and will frequently output garbage if it encounters any errors.

The next version (5.0) will have a whole new set of parsers, and three separate and distinct roles:

1. minify code -- outputs only the minified code and nothing else. No errors, no warnings, just minified code. And if it encounters any errors, it outputs the source code around that error as-is so as to preserve any syntax that it just might not understand. This would be a build-time/run-time role.
2. lint code -- doesn't minify the code at all; just outputs only the errors and warnings in the source and nothing else. This would be the lint-style development-time/build-time role aspect.
3. prettify code -- neither minify the source code nor lint it; just expand the code as-is (only whitespace and line-terminators added) so that it's easier for developers to read and debug. This would be a purely development-time role.
   But that new version is still quite a ways off.