• More search engines are supported. Added MSN Live, Technorati and Dogpile.
• Add the framework for search engines that don’t use query string, i.e. Technorati, Dogpile and many others.
• Fix up an issue with Hilite.style_name_suffix = false.

It has also been tested on IE7, FF2 and Opera9. Go to the project page and download either the zipped file or the raw JS from my SVN repository.

I’ve also fixed a few stylesheet glitches with Internet Explorer 7.

Ajax has been revolutionizing the web. However it is greatly limited by the browser same-origin policy, meaning that your site can only be as good as the web applications and tools that you create. But there’s a lot of great tools out there, wouldn’t it be nice to tap into them? Changeable Origin Web Services — COWS — Ajax breaks down this barrier.

It argues that “traditionally” Ajax, which utilises XmlHttpRequest object to perform asynchronised HTTP requests, has one problem — which was actually a security policy. The way to solve this “problem” is by using its COWS Ajax mechanism which allows web services from hosts other than the origin of the page to be performed.

Behind the scene is actually quite simple. In order to invoke a web service on a different domain, the COWS API does:

1. Create a <SCRIPT/> DOM element.
2. Point the src attribute to a remote Javascript.
3. Append the <SCRIPT/> DOM element to <HEAD/>.
4. Javascript code returned from a remote domain will then call a predefined handler, and then remove the <SCRIPT/> from <HEAD/>.

Sounds exactly like how many complicated bookmarklets work. My old Google video download script works the same way. Besides security issues due to trust, there is really nothing new. In fact, I won’t even consider it as “Ajax”. What is Ajax then?

Asynchronised

In Ajax applications, you hand in your handler to be called back when the HTTP request completes. In COWS, there is no guarantee that your callback will be called. A Javascript file is returned by remote service and is evaluated by the browser, and at its mercy your response callback might be called. Your error callback is only called by constantly polling the system.

Javascript

Well, it is in Javascript and I won’t argue that.

Aand

And?

XXML

The result of the web service is not XML. Nor JSON. In fact it is full on Javascript code that will be evaluated by your browser before the evaluated code calls your handler.

I personally don’t think COWS has resolved any issue that has already been addressed. Nor is it a savour to Ajax — it is far more limiting than the “traditional” XmlHttpRequest style Ajax. There is however much market-speak on COWS’ website:

And in exchange for making the cool apps, the application host can create branding, drive traffic, or employ serveral revenue streams. Everyone wins! In this case, the cow coming home is the cash cow ;-)

You need much much more than COWS to create a cool app, and you need much much more than a cool app to bring in the cash. Meanwhile, COWS just sounds like bull to me.

The Yahoo! User Interface Library is a set of utilities and controls, written in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, HTML and AJAX. The UI Library Utilities facilitate the implementation of rich client-side features by enhancing and normalizing the developer’s interface to important elements of the browser infrastructure (such as events, in-page HTTP requests and the DOM). The Yahoo UI Library Controls produce visual, interactive user interface elements on the page with just a few lines of code and an included CSS file. All the components in the Yahoo! User Interface Library have been released as open source under a BSD license and are free for all uses.

Good thing about corporate-backed open source library is that it is very usable right from the beginning. In fact, according to Yahoo! User Interface Blog, the UI library was started almost one year ago before released to the public. It is also functional — AJAX, DOM, animation effect, drag ‘n’ drop, and a cross-browser event model, plus a few ready-made Javascript widgets like calendar and tree view. Moreover, Yahoo has a guideline on its graded browser support, including who are they committed to support (currently IE 5.5+, FF 1+ and Safari 1.3+).

Neat. If you can stand YAHOO Javascript namespace all over your code :)

However when you look around at what has already been done by other OSS libraries, YUI doesn’t really add anything that is extra-ordinary special. Yes — it has good clear defined cross browser support. Yes — it has useful documentation. But is there anything new? YUI is on the “fat” side of the library in comparison to libraries like Scriput.aculo.us, but it is not “fat enough” to provide all the web gizmo a web developer wants (I want a tree/list control that emulates XUL’s Tree control, thanks!). Hopefully more UI components are in the making.

Also with some of the examples I have looked at, I found it still lacks user accessibility from developers’ point of view, i.e. it is not that developer friendly. For example, the Connection Manager library that does cross-browser XMLHttpRequest. Instead of performing operations on the object returned by asyncRequest(), you need to keep on typing in YAHOO.util.Connection... to check status, abort requests, etc. The same can be said about other libraries — there are just way too much typing.

The question is, why is Yahoo releasing their UI library for free? One thing for sure is, since Javascript is sent to the browser in unobfuscated clear text, those who are interested in “how Yahoo! does it” would have “stole” the code anyway. It can’t be Yahoo that wants to spur up the development using the open source model, otherwise other license will be used instead of BSD, where contributing back modifications is not even required.

As far I can see, it is just a stunt. Yahoo! released a well-documented open source Javascript library, so we should all classify them as the “Good Guys”. Especially in the view of recent Google-related events, who “helped” ruthless Chinese government oppressing innocent Internet users. This move will surely win the hearts of many freedom-loving open source geeks.</sacarsm> :)

Honestly, I believe many other open source projects (or even commercial proprietary projects) will benefit from Yahoo! UI because it is indeed a high quality (though a bit awkward) piece of library.

So yesterday evening I hacked this Javascript, Google Video Downloader Bookmarklet, to automatically reveal the actual URL of the Flash Video, and provide one click download to save it on my hard disk, so I can recompress them with Xvid to watch on my Dell Axim v50.

Hopefully it will be useful for others as well.

Taken from the bookmarklet section of the Scripturizer page:

You are not only able to hyperlink Bible references on your own website, you can now also scripturize other websites! Even been to a website where the webmaster just forgot to provide links for passages to the text (like I usually do)? The Scripturizer bookmarklet is here to provide the fix.

Bookmark it! And Scripturize It!

Scripturizer for Javascript 2.0

• Almost a complete re-write. Instead of searching and replacing innerHTML with regular expression, I have made a DOM walker to create DOM elements and text nodes in places of Bible references. It runs faster on MSIE, and pauses every 500 nodes parsed to make UI more responsible on large documents.
• Link URL generation is now done on the fly — so you can change Scripturizer’s parameter on a parsed document, and the new parameter will still be used. See example on testing page by changing the Bible translation.
• Fully tested on Safari 1.2.x on Mac OS X.3 and Opera 8.5 on Windows.

ESV Popup 1.1

• Better MSIE compatibility. It now also uses CSS filter to draw a shadow under the popup for Internet Explorer.

Future development of these tools will be announced on this blog.

• Rewrite the parsing engine to use DOM instead of resetting the HTML.
• Easier customisation on search engines.
• Use Javascript Cruncher for distribution.

Download the SE-Hilite 1.3 (2.7kb, zip). See usage for instruction.

Previously the highlighting was done by grabbing the entire HTML inside the DOM element, doing some sort of regular expression substitution, and then resetting DOM element with the resulting HTML. It has some issues especially in correctly identifying the text, as well as some regexp magic that behaves differently across browsers.

In SE-Hilite 1.3 it has been changed to use DOM functionality exclusively. A DOM-walker has been implemented to iterate through all text nodes and create/insert <span/> elements for matches. It also makes possible to pause in the middle of a DOM-walk, pass the thread back to browser, and then resume the walk later, so that highlighting large documents can be done progressively without locking up the browser.

Performance wise, a DOM walk is also faster than resetting the HTML attribute of a DOM element. The benchmarking document I used was W3C’s Document Object Model Core at 436kb, highlighting 4 keywords. Under Firefox 1.5beta1/Win32, both methods were on-par, finished highlighting at around 1.6 seconds on a 1.7Ghz Pentium M. Under Internet Explorer 6 SP 1 however, SE-Hite 1.3 finished the test in 3.1 seconds, but the old innerHTML method hangs the browser completely.

I have yet to test the new code on Safari 1.2/2.0, but I think it should work as Safari supports DOM2.

• Fix up the bug when search keyword containing partial match of ‘span class="hilite"‘.
• Having an extra boolean flag Hilite.exact, whether the parser should perform exact match. Default to true, i.e. searching for “search” will not match “searching”.
• Minor performance optimisation.

Download the latest version of Search Engine Highlight Javascript.

What stands out is this implementation does not require a middle man as service broker. It breaks the security restriction of XmlHttpRequest by making you visit the site first, click on a link to insert a <javascript/> element to import direc.tor’s bootstrap script, and completely rewrite the document body (and disable all the stylesheets). Now you have complete control of the document, plus you can make XmlHttpRequest to the site you want, as document location is still the old URL!

For more detailed write up, check this article on setting up a client-side web service broker.

Basically it allows you to do what Greasemonkey does, without Greasemonkey or even Mozilla/Firefox. We shall see more and more of this kind of web applications, the ones that re-write your web sites and make into their own.