> @Sanford, of course it'd be redone with MT. Okay... but then why ref an existing project as "something mootools docs could use" instead of just spec'ing out a new one? It's not clear there's anything in that particular code that's a keeper, other than the concept of being all client-side, which I think everyone pretty much understands in theory. There are clear differences about whether it is a proper/efficient/exemplary place for a JS-heavy solution at all.
As Guillermo has noted well, the current search is broken. Seems to me anything that *avoids* having to be a MT showcase is likely to be implemented fast/er. I happen to think the client-side idea is fine for a small, non-developer site. It's just... where is the existing, tested, MT solution for this? > You're missing the advantage of having portable docs. Ones that you > do not require any software (aside from your browser) to run the > docs. Really, I do understand: I distribute our own docs using a client-only search engine (with the index pre-compiled and search JS provided by our commercial help compiler) so they can run from CD/flash. The JS is proprietary but it works very well; the HTML is as sloppy as you'd expect from such WYSIWYG help apps. *But* the offline search functionality is all I care about there. I'm not promoting a JS framework, so I'm not worried if anyone looks under the hood of the docs. --Sandy
