An Underestimated Tool in Windows: HTA (HTML Application)

I can’t find a convinced source telling in which specific date did HTA become available, but it seems to be earlier than the year 2000.

On the official introduction page of HTA, there’s a highlight saying “The Power of Trust”. Unlike normal HTML pages running in a normal browser, HTA can have almost the same permissions that an exe file could have. Which gives it access to varieties of ActiveX that are not available in normal browsers due to security reasons.

I am always wondering why only a few people know and use HTA? Hmm, maybe one of the reasons is its “Microsoft” tag. I have given up the thoughts hoping HTA could be relatively mainstream, however, for developers who use JavaScript and HTML, HTA could still be a good choice to write some lite productive tools for your colleagues and yourself.

NodeJS would certainly have much better ecosystem now but for some specific tasks I still prefer tools with GUI… T-T (Now I also use NodeJS to do some batch work.)

But it was a shame that Microsoft stopped making it better. Wishes.

Disable Scroll Bouncing Effect of WebBrowser Control on Windows Phone 8

Just another story happens when developing WordsBaking.

First, the basis. If you don’t have any element in your web page that requires overflow style being auto or scroll, “-ms-touch-action: none;” under “html” selector should work well . Actually it works all the time in Internet Explorer, but in a WebBrowser control, if there’s something like a list for which you may need that style, the solution becomes tricky.

I spent tons of hours and tried tons of ways hoping figure out a solution, and luckily, found one.

That is the good news, but the bad news is, this solution doesn’t seem to be elegant (though it works perfectly so far).

The first thing that I found might be useful is that this bouncing effect happens only when your finger touches the elements that already have their contents at the top/bottom or both. So, the first solution I thought might work was to add a pointerdown (MSPointerDown) event listener on the element, and determine whether its content has reached the top or bottom. Unfortunately, it doesn’t work well.

Later I read about an article shows a solution on suppressing scrolling and zooming in WP7 WebBrowser control, I can’t say that it works (on WP8), but it helps.

Combining these two parts (and this is why I think it’s not elegant enough), here’s the solution:

C# Part

private void mainBrowser_Loaded(object sender, RoutedEventArgs e) {
    // here we are using a library named Linq to Visual Tree.
    var border = mainBrowser.Descendants().Last() as Border;
    border.ManipulationDelta += border_ManipulationDelta;
    border.ManipulationCompleted += border_ManipulationCompleted;

void border_ManipulationCompleted(object sender, ManipulationCompletedEventArgs e) {

void border_ManipulationDelta(object sender, ManipulationDeltaEventArgs e) {
    var status = mainBrowser.InvokeScript("onmanipulationdelta") as string;
    if (status == "top" || status == "both") {
        if (e.DeltaManipulation.Translation.Y > 0) {
            e.Handled = true;
    if (status == "bottom" || status == "both") {
        if (e.DeltaManipulation.Translation.Y < 0) {
            e.Handled = true;

JavaScript Part

window.manipulationTarget = null;

window.onmanipulationdelta = function () {
    if (!window.manipulationTarget) {
        return '';

    var target = window.manipulationTarget;

    var top = target.scrollTop == 0;
    var bottom = target.scrollTop + target.clientHeight == target.scrollHeight;

    return top ? bottom ? 'both' : 'top': bottom ? 'bottom' : '';

window.onmanipulationcompleted = function () {
    window.manipulationTarget = null;

// and you'll need to make calls to every elements
// with overflow auto or scroll with this:
function preventBouncing(ele) {
    // using jQuery.
    ele.on('MSPointerDown pointerdown', function (e) {
        window.manipulationTarget = this;

And good luck fellows~

Let's Again Talk About IE (Internet Explorer)

As an amateur but the same time professional front-end engineer, one of the most common things in my life is to press F5 in different browsers.

When this word was not “standardized” as it is now, I was used to pressing that button in several versions of IE, Chrome, Firefox, Safari, and, if I was in a really great mood, Opera. So I hadn’t suffer less than anyone. Especially from IE 6/7.

Now I basically test only in IE 8+ and Chrome. If the project is platform targeted, even better. There has been a lot of scoffs about IE  on compatibility and performance these years, which make me sort of sorry. People would always be fond of the new and tired of the old, even though it is the old one which brings the bright start to all these wonderful things.

IE 6 in my opinion is a great browser. It is out of date but It was well-designed and ignited many features in modern browsers. Actually, tons of newly added features in HTML5 or CSS3 can be imitated in IE 6, a browser which was released 12 years ago. And many earlier IE-only features have become the standards.

The earlier versions of IE is buggy and perform slow, but they perfectly served the days when it was released.

Well I am not trying to ask people not to give it up, but just hoping we can keep the respect, which this browser deserves, to it in its last days.

Microsoft seems to have realized their mistakes on detaining the developing of IE these years and brings us the new IE 9/10/11. Compatibility issues have become minor since version 9 (also it brings us fully GPU acceleration, which is a really important event for web apps), and since version 10, IE finally caught up the steps of modern browsers.

IE now is almost ready for web apps which could be as great as native apps, and I am looking forward to the booming of mobile web apps in the next several years. 🙂

Thoughts after Developing WordsBaking

Several months ago I started my own project called WordsBaking, which is a tool developed for helping students or learners like me to remember new English words. Considering the time and resources I have, I finally decided to use HTML/CCS/JS technologies so that it could be easier to have the versions for the three major mobile platforms.

But there would certainly be some subsequent issues. In last post, I wrote something about performance, gestures and preventing tap highlight. And in this post, I am gonna write some notes about browser bugs.

First of all, I like IE 10 Mobile quite much, comparing to original Android browser. But unfortunately, it still gets some weird bugs.

1. Scrolling issue with CSS3 transform.

I spent a lot of time locating this issue, as scrolling should be one of the most basic features, which in other word should be stable enough. It is a list of which the parent node has the style “overflow” with value “auto”. And the pseudo element “:active” of the list items has a transform with transition: translateX, so that when finger is on the item, it moves a little bit rightwards. Then the problem came, you can’t scroll the list down directly. If you want to do so, you’ll have to scroll up a little first. And, after you scroll to the bottom, you can even continue scrolling up (though the scrolling becomes no longer smooth).

So I have to change the transform to some older ways, like margin, padding, etc.

2. Scrolling issue with phone:WebBrowser control.

Ohh, again scrolling. To use pointer series of events built in IE, I have set -ms-touch-action to none under html selector. So that the page won’t move around or dance with your fingers. It works well until you get some elements with style “overflow: auto;” (or “scroll” I guess). After a list is scrolled to the top or bottom, if you put away and back your finger and continue scrolling, the whole page starts a bouncing effect. Luckily, this only happens in a phone:WebBrowser control. But unfortunately, I am using that control to wrap up my app.

I guess there should be a solution but I really haven’t found it.

Okay, so these are issues with the front end. On back end, I chose NodeJS as I am more confident with my JS skill. But it really took me quite a lot time to start due to the poor documentation. I am not familiar with back end and everyone knows I write front end all the time. I can’t say it would be a challenge to write the back-end stuffs I’ve done these days, but it was a great chance to learn new things.

The main problem I have is lack of database related experience, I don’t know how the db engine works in the box, so I don’t know how would my structures and logic perform. T-T

But back to NodeJS, I am quite missing my VEJIS, which helps JSers coding without looking for online documentations. Oh dear you know how it feels when you press the “.” but there is no accurate auto completion and hints? It might not be that helpful after one is extremely familiar with a framework, but before that, it helps a lot. And one more thing, we are never be that familiar with every new code line we write…

A thousand words are reserved here…


So, I am very excited as WordsBaking for WP is almost ready for beta, after months. I always believe the power of a team, but when a team is not available, I also believe my own skills. Thanks my CTO (Chief Track Officer) for Tracking my developing progress btw, or I wouldn’t be able to finish the beta version. 🙂