I recently watched a video about a cool new technology called <angular/>. It looks like a great way to create web applications. It caught my attention because I saw in it some parallels with some of my recent writings and what I am currently working on.

The video was very good but in the beginning Misko Hevery struggled a bit to describe it and at the end admitted the biggest problem was explaining to people what <angular/> is. To me it is clearly a language, and an extensible one at that. It is (or at least contains) as he describes an HTML compiler. Doesn’t a compiler imply some language to compile. The source is clearly more than just HTML so it must be more than just an HTML compiler. I wonder if there is some reason he avoids calling it a language. The fact that it can be extended to handle new behaviors, widgets, etc. just makes it a better language. Is there some fear that calling it a language would put people off? It doesn’t bother me since I previously said that higher level languages will provide the biggest productivity gains.

The parallels I was talking about are:

• Its a declarative language
• The language is designed to be extended
• It has two way data binding

Two way data binding is a very important aspect in simplifying the creation of web apps. The first time I ever saw data binding was back in the the late ’80s. I was visiting a friend that was working on a maser, which is cool (literally) in its own right, but what caught my eye, as he showed me around his lab, was some software running on an old Mac. That software was LabView. The fact that a line drawn between a sensor and a gauge meant that any time the senor value changed the gauge was updated really impressed me. More recently I noticed that data binding is built in to the JavaFX language. I haven’t written any programs in LabView or JavaFX so I’m not sure if the bindings can be bidirectional but I’m pretty sure at least in JavaFX that bidirectional changes can be accomplished.

It is the two way data bindings that most notably distinguish <angular/> from template languages. I used to be a big fan of template languages, and StringTemplate was my favorite. Lately I have found them to be less useful. One reason is that in my recent work I have found that procedural logic far outweighs the amount of template text. The bigger reason is that most template languages don’t automatically protect you from script injection (XSS). There are many JavaScript template languages available now and I don’t have a need for any of them. But <angular/> is different — it is not a template language and it looks like it protects against script injection by default.

<angular/> is new but it looks very promising.

Using positioned background images (a.k.a CSS Sprites) has a number of benefits:

• Performance. One of the performance recommendations made by Yahoo’s performance team is to reduce HTTP requests. One way to do this is using the CSS Sprite technique — combining many images into a single background image.
• Skin-ability. With the img tag the image URL is in HTML markup where it is hard to change. With CSS Sprites the image URL is in a CSS file making it more convenient to change. Sure you can change the contents of the original file but there are reasons for changing the URL. It is not as easy to move the images to a different server or group them in different image files when the URL is not in CSS.

However there are drawbacks. The biggest is accessibility, specifically high contrast mode. In high contrast mode all background images and colors are ignored — replaced with high contrast colors such as white on black or black on white. The other issue is that background images are not always printed.

The prevailing accessibility advice is to not use background images for functional images. The underlying problem is that there is no way in HTML/CSS to identify a background image as being functional. They are all considered decorative. It is also true that not all img tag images are functional but again there is no way to distinguish them for the purpose of high contrast mode. So high contrast mode makes a reasonable assumption that background images are decoration to be removed and img images are functional and must be shown. From here on I’ll call functional images icons. They either convey important information or are interactive (like a toolbar button for example).

I have seen recommendations that functional background images should be replaced with text when high contrast mode is detected. This does not seem right to me at all. A desktop app does not change its toolbar button icons to text in high contrast mode. The assumption is that icons are already designed to have reasonable contrast.

It also just feels right to me that the icon URLs should come from CSS.

Since I care about performance and accessibility I’m not happy with this conflict. I want a solution that puts the icon URL in CSS, works in high contrast mode and allows me to combine icons into a single image file. Here is what I came up with.
Continue reading…

While working on some accessible UI widgets I found strange behavior in IE8 related to when it does or doesn’t show the focus outline around an element that has focus.

When you use the focus method to set focus to a focusable element the expectation is that, in the absence of css rules to the contrary, the browser will show a focus outline around the element using its default style. This is what happens in Firefox, Chrome, and Safari. (Opera has its own set of focus problems which I didn’t investigate fully.)

There are a number of elements that are naturally focusable, such as inputs and anchors. In addition any element with a tabindex attribute equal to -1 is focusable. If the tabindex is non-negative then it is focusable and in the tab order. My test case uses list elements with tabindex of -1 or 0. I suspect that the same is true of other elements using tabindex.

Older versions of IE (I tested IE6 and I believe IE7 works the same in this regard) had some strange additional requirements beyond just calling focus. The outline would not be shown if the focus method was used to give focus to an element with a tabindex of -1. So before setting focus you would have to set the tabIndex to zero (or a positive number).

elem.tabIndex = 0;
elem.focus();


Also if you click on an element with tabindex of -1 no outline is shown unless the className is updated (even if the value doesn’t change). Perhaps other style changes would work as well.

IE8 adds some new bizarre behavior. First if css is used to set an explicit outline style on the elements (either directly or inherited) then the old IE quirks mentioned above go away as well as the new IE8 problem described below. Setting your own outline style for focus isn’t a good idea unless you are giving your whole web app a focus style makeover. I think it is best to stick with the default styles since it is what the user is probably used to. There is also the problem of old browser like IE6 not supporting the outline style.

If the className of the element receiving focus is updated in the onfocus handler while the tabIndex is -1 then no focus outline is shown. Assuming that the tabIndex is -1 and addClass is a function that adds a class to the className, one would expect the following two lines of code could be executed in either order.

addClass(elem, "myfocus");
elem.tabIndex = 0;


In IE8 setting the tabIndex to zero must be done first or the outline is not shown. This is exactly what tripped me up. If I just happened to write the statements in the opposite order I would never have discovered these oddities.

Note that in all cases focus is actually set correctly it is just the visual indication of focus that is wrong – but thats the important part of focus.

I created a test page that allows playing around with these rules. It is also an example of how focus can be managed with a roving tabindex. If you play with this page in different browsers you will notice that in Firefox (versions 2 – 3.5) , Chrome, and Safari 4 (I tested on Windows) it doesn’t matter what options are checked, the behavior is correct. In IE you can play with the options to see which combinations work.

I wonder if this is intentional in IE8 or is something that will get fixed in a point release.

I have read Life above the Service Tier a few times now. Its a very good paper, one that really changes your perspective, but I wish it was better. If you work on web applications and you haven’t read this paper I recommend that you go read it now — but do come back.

I agree with the overall reasoning and the conclusion.

So one obvious way to correct the thin client architecture is to implement a true MVC framework on the client side… That means that all “Presentation Flows” must occur within the currently ­loaded web page… So one workable model is the Single Page Application (SPA).

First let me get some minor complaints out of the way.

Continue reading…

The HTML button element has given me trouble in the past. My conclusion was to not use the button element except to progressively enhance the look of buttons. This means the button would initially be an input of type button and JavaScript, if enabled, would change it to a button element.

Well at work I’m working on an app that requires JavaScript and all form submissions are done with JavaScript already so I thought it would be safe to switch over to <button>. The server never uses the button names or values (all needed information is in other inputs – hidden or otherwise) so the IE bugs should not be an issue.

This time the problems I found were exposed with Firefox but the real problem was in the web app code even if the browser behavior was surprising.
Continue reading…

[This originally appeared on my dev2dev blog 16-Nov-2007]
Here are instructions for using JSLint from Ant to check your JavaScript for common potential problems.
Continue reading…