UPDATE: Chili 1.6 has been released
Changes
- Changed the recipes format to JSON. Previous recipes need a small conversion. Just compare to a JSON recipe and you’ll see how to
- Improved support for dynamic setups, by means of metaobjects, which allow a clean configuration on a per element basis
- Improved support for static setups
- New examples show how to configure static and dynamic setups
- static: recipes and stylesheets linked from the page
- dynamic: recipes and stylesheets downloaded on demand
- The examples also show how to mix languages in the same page, manually configure a mixed language setup, use metaobjects, use a dynamic download in a static setup
- Added an option for preventing CSS downloading on demand
- Added a new recipe and example for pure HTML
- Updated the bundled jQuery library to version 1.1.1
- Dropped support for Code Highlighter styleSets. It’s very easy to convert a styleSet to a JSON recipe, though
- Fixed a bug in the white space’s rendering
- Improved the white space’s rendering in Opera9.1
- Added scope protection to all the Chili code
- Tested with IE7, FF1.5, Opera9.1
Files
- download all in a zip
- read the manual
- Examples (static)
- Examples (dynamic)
Looks great, Andrea! I like the json formatted recipes. Thanks for all the fixes and improvements!
One suggestion: before the $.getJSON call add this:
if ( !ChiliBook.recipeLoading ) return;
Mike
I really don’t know if it’s needed the check there… I threw it in just for symmetry I guess, but later I realized that it was not very useful.
It’s kind of that you are using Chili but don’t want it to work. I mean, if there is a class defined for a Chili element, then Chili checks for a corresponding recipe and if it does not find it in the repository, then it tries to download it. In a static setup the recipe should already be in place, and in a dynamic one, the check is not needed.
I’m a bit confused: what do you think that check will be useful for?
Thanks for your appreciation 🙂
I found that I needed that check for my setup. What I do is include my recipes right in the Chili script file and then pack it. So I don’t want anything to be downloaded automatically. Without that check it was trying to download a recipe file. It seemed weird that it would do that but putting the check in fixed it!
I see what it is. I use some code elements with class names for which I don’t have any recipes. Chili is trying to load scripts for those – that makes sense. But I don’t want Chili to do that because I’m just styling those blocks with css. I guess I could just define empty recipes for them but it’s easier to use the recipeLoading flag.
I see… But wouldn’t it be enough to do the opposite?
If you setup elementPath and elementClass such that Chili finds just the elements you’re interested in, it will simply ignore any other. For example, elementPath = “code.apply_chili” and elementClass = “apply_chili”, should make Chili process only code elements with an apply_chili class.
Do you think it’ll work for your setup?
«!– this will be highlighted –»
«code class=”apply_chili javascript”»alert( “Hi” );«/code»
«!– this won’t be highlighted –»
«code class=”javascript”»alert( “Hi” );«/code»
Â
Yes! That works great. Thanks, Andrea, I didn’t know I could do that.
Mike
Great ! This version really improves the user experience !
And it WORKS with Safari !
Tested on Mac OS X 10.4.8/Safari 2.0.4 (419.3), Firefox 2.0.0.1, MSIE6, MSIE7, Opera 9
Tried Chili 1.5 with the API Browser and so far it works great!
Currenctly I’m trying to figure out how to optimize the performance of the browser startup, on slow machines it takes more then 10 seconds.
Chili’s setup makes it rather difficult to optimize the selectors: I have jQuery core and all required plugins build into one file, and execute another script after loading the first. Therefore I can’t modify Chili’s settings without modifying my build. That’s basically the same issue as with Thickbox’s autoinitializing: It’s nice when it works as expected, but ugly to customize.
For this setup, I’d prefer a normal plugin: $(“#context code”).Chili()
Yet I’m not sure if that would really help with my problem, so until you fixed everything else, don’t worry about this one.
You can test alternate configurations from outside, leaving your packed file alone.
The ChiliBook global object hosts all the configurable options, so you can specify new options at any moment before the document.onload event is fired, which is Chili’s trigger.
Oh, I didn’t think of that, thanks!