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.

• 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.

My typical markup for an icon is something like this:

    <button><span class="icon edit"></span></button>
    <button><span class="icon delete"></span></button>

The basic style is:

span.icon {
    display: -moz-inline-box;
    display: inline-block;
    width: 16px;
    height: 16px;
}
button span.icon.edit {
    background: transparent url(images/toolbar.png) no-repeat 0px -32px;
}
button span.icon.delete {
    background: transparent url(images/toolbar.png) no-repeat 0px -16px;
}

This creates a button with an edit icon assuming that toolbar.png is a sprite image with the edit icon at offset 0, 32 etc. I left out extras like a title tooltip and hover and active states for the button icon to keep things simple. This works nicely until high contrast mode is turned on.

You can use the same sprite image in an img element and position it relative to a fixed size parent that has overflow:hidden to achieve similar functionality to a background image.

For example:

    <button><span class="icon edit"><img alt="" src="images/toolbar.png"></span></button>
    ...

The style to make this work is:

span.icon {
    display: -moz-inline-box;
    display: inline-block;
    width: 16px;
    height: 16px;
    overflow: hidden;
    position: relative;
}
button span.icon.edit img {
    position: relative;
    left: 0px;
    top: -32px;
}
...

This works in high contrast mode (as well as normal mode) and has multiple icons in a single image but the image URL is in the markup not in the stylesheet. What I want to do is use JavaScript to take the image URL from CSS and dynamically add the img element as a child of the icon span. The html mark up and stylesheet will be the same as the first example above except that the stylesheet will have these additional styles:

span.icon.edit img {
    top: -32px;
    left: 0px;
}
span.icon.delete img {
    top: -16px;
    left: 0px;
}

These additional rules are not too much extra work considering you will usually have additional rules to adjust the position on hover and active states anyway.

My first attempt tried to get the URL from the current styles using jQuery like so: $(…).css(“background-image”). The trouble is that in high contrast mode the effective current background image is “none” even though the CSS file does have a background image. This makes sense — the program should “see” what the user sees. The solution is to get the actual background image directly from the CSS rules. This takes a little fiddling to get it to work cross browser. Some browsers return the full URL and some return exactly what is in the CSS file. Some times its wrapped in quotes.

This test page shows an example of the traditional CSS Sprite technique as well as my jQuery enhanced high contrast mode compatible version. All the styles and JavaScript are in the html file to make it easy to see how it works. It also contains code to detect high contrast mode. One option is to only make the dynamic change if high contrast mode is detected but that is not the approach I took in the test page.

View the page with high contrast mode turned on and off to see the difference. Note: not all browsers or operating systems support high contrast mode. Firefox and IE on Windows do. It is also important that the dynamic changes work even in browsers that don’t support it (by work I mean that the icons look right and are functional, not that high contrast mode magically starts working in browsers that don’t support it). I tested on Windows with IE8, FF3.5, Safari 3.2 and 4.0, Opera 10 and Chrome and found that they all worked. I also tested on Linux with FF3 and found no problems. I don’t have a Mac to test with. I tested with IE6 and found that it did not work. More investigation is needed but IE6 is not a high priority for me right now. I need to test with IE7 but don’t have it handy right now.

Feedback on how it works in other browsers and operating systems would be very helpful.

I did not do any performance testing. The assumption is that moving the image from the background to an img tag will not cause the image to be requested from the server. The Firebug Net tab indicates that it is fetched just once. The page seems to render fast enough with no flashing. More testing is needed but I think the principal is sound. The script could use some improvement to be more robust especially for much older browsers so they at least fall back to using the CSS sprites as is. I bet there are other cases of relative URLs to test for as well.

Keep in mind that the test page is meant to demonstrate just this technique. It has a bunch of other accessibility no-nos such as the disclose icons are not focusable, keyboard accessible, and have no screen reader accessible label text.

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 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.

The paper tries to be fair to REST but it gets some things wrong. The mapping of CRUD verbs on to HTTP methods is as follows:

• Create is done with PUT or POST depending on the relation between the entity to create and the URI.
• Retrieve as well as search and find is done with GET. Search should not be done with POST.
• Update is done with PUT
• Delete is done with DELETE

It has a definite bias against JSON based on it not having a schema. But there is a proposed JSON Schema and the author seems to have updated his view on this matter. It seems contradictory to me to say REST is valid but XML is the only representation that is acceptable. What would be wrong with microformats in HTML or CSV for example? Any well defined format should be OK — thats the whole point of constrained content types. Using the X in AJAX as justification for using XML shows outdated thinking. Current usage of ajax is not as an acronym but a term referring to an architectural style for web apps leveraging a wide range of technologies.

The description of the POST-Redirect-GET pattern is very good but I don’t agree with the conclusion: “Although ingenious, the POSTRedirectGET pattern is mere bandaid over the fractured web architecture.” I consider the POST-Redirect-GET pattern (I call it redirect after post) to be the way the web is intended to work and I’m still baffled that its use is not wide spread.

The superficial differences between thin and rich clients should be updated. The offline distinction of rich clients starts to go away thanks to Gears and related features of HTML5. The footprint of thin clients is going up as they use more and more JavaScript libraries.

I think the claim that Front Controller is an anti-pattern should be backed up. Give more background on what Front Controller and MVC patterns are and justify why Front Controller is an anti-pattern. Not having this rigor makes it harder to believe the conclusions. The Design Patterns book does not list MVC as a pattern but does note that it is made up of other patterns including Observer, Composite, and Strategy. I think the most important part of MVC is the decoupling of the model and view. The main pattern involved in this separation is Observer. But the Observer pattern, where views get notifications when the data changes, doesn’t work well across the web. So there must be some other benefit to the separation of model and view. This paper describes the benefits in terms of Presentation Flow and Data Interchange separation. Laying the blame on Front Controller doesn’t seem fair. As far as I know Front Controller doesn’t say anything about the combination or separation of model and view. It is simply about combining common precessing in one place and dispatching to command processors for specific processing. It made sense given the state of web app architecture at the time. Perhaps Front Control means Model 2 in the context of this paper. I never did understand how server side framework’s, such as Struts, can claim to be an MVC architecture or more generally I don’t agree that Model 2 is MVC.

The two more fundamental issues I have with the paper are:

• The insistence on a schema for the model.
• Too many implementation issues left unanswered.

I’ll discuss these in order.

My background and experience is in creating web applications. Functionality, usability and performance are the most important factors (along with time to market) driving the design. I have not had any direct experience with SOA. One aspect of SOA is loose coupling between systems. The loose coupling motivates a strong contract. In my experience the presentation layer (a.k.a UI) of an application has tight coupling with its model. For this reason I don’t have a problem with the data that flows between the UI and model not having a schema. At some point the underlying data will likely have a schema or some formal description, for example a database schema. Way back when I worked on desktop apps there was the notion of an intermediate model between the view and the underlying data store. Now this intermediate model is delivered as a REST resource and it is in direct support of the presentation layer. It satisfies the needs of the presentation layer — not the other way around. A simple change to the UI can result in a need to rewrite the contract with the data model. The overhead in maintaining the contract must be considered.

So I could be all wrong about this. My experience could be too limited and there are cases where you want a firm contract between the presentation and the data. If so then SOA makes a lot of sense. I’m not trying to say anything negative about SOA. It seems to me that the insistence on schema is more a motivation for SOA than anything else. Without it I would still draw the same conclusion, as others have done, that a single page app (i.e. move the controller to the client) is a good idea. Is the principal of statelessness from REST enough motivation in itself to draw the conclusion that the controller needs to move to the browser?

The paper ends with a list of principals for the SOFEA model and an example but a number of tough issues and details are left out. Some of these issues apply to ajax techniques in general. In the traditional web app architecture you can always choose not to use a particular ajax technique if it causes a problem but when your application architecture requires ajax at a fundamental level these issues must be addressed.

The first two issues are about accessibility. A single page app (SPA) relies on JavaScript. What about users who disable JavaScript or browsers that don’t provide JavaScript. Is it reasonable in this day and age for web apps to require JavaScript or should you try to make your app accessible to as many user agents as possible? What about the principals of unobtrusive JavaScript (UJS), is it easier to apply when the app uses multiple pages (traditional server controlled presentation flow) rather than a single page.

A SPA also makes dynamic changes to the DOM which causes trouble for assistive technologies. Is it a matter of assistive technologies needing to catch up? Do we wait for WAI-ARIA to come to the rescue? If you are designing for the future or your users are on the cutting edge (or you don’t have users with disabilities) then this may be a non issue. If your app has strong accessibility requirements including legacy software support then a SPA is out of the question.

Is this architecture appropriate for all kinds of web apps or not? In which cases does it apply? For example does it apply to web sites. This brings up the old debate about the distinction between web apps and web sites.

Does putting a controller inside a web page break the way the web is supposed to work. There are issues with bookmarking, and the back button that must be addressed.

What if the app is too big to fit in a single page? Sure you can grab bits of the HTML structure as needed but how will this impact search engine spiders?

There are many implementation details to solve in creating a MVC framework in the browser. The paper bemoans the proliferation of web frameworks but this architecture and ajax in general have enough challenges to ensure that there will be an equal or greater number of client side frameworks. How do we keep from making the same mistakes that were made server side? For example some client side libraries for templating are sprouting up and they seem to be making the same lack of model view separation mistake that server side template engines made. In a previous post I asked “Is there a need for a JavaScript implementation of StringTemplate?” I think the answer is a clear yes. However, templating is just one way to get the data back into the view. Another option is directly injecting each data value into the DOM. What are the pros and cons of each method?

Is SPA the only way to move the controller and state to the client? The paper also mentions frames as a potential solution. Would local storage such as Gears work with multiple pages each making a separate request for its data satisfy the principals of SOFEA? The conversational state is kept in local storage. Separating the data from the view and having multiple pages has the disadvantage of increasing the number of requests at least until the view pages get cached. This means it is even more important to give the static view pages a far future expiration date.

Another issue is localization of text strings. In traditional web apps this was done as part of the same templating that merged the data in with the markup. This seemed reasonable at the time but text translation is very different from data access. The application data is likely to change frequently whereas the text translations rarely ever change. Would the principals of SOFEA recommend that text localization be done on the client side as well? As far as I can tell it makes no recommendation in this area. As long as the data and view are separate it shouldn’t care if the translation is done on the server. But running the otherwise static view markup through a template engine just to do text localization seems silly. Why not pre-translate the view and store it on the server?

I’ll stop now before I ware out my question mark key. Wait, one more: How are you solving these issues?

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.

The app is doing two interesting things with buttons. It disables the buttons before it submits a form and it has some buttons that work like a link by setting location.href. My goal was to simply change the button style and not other functionality so I just changed <input type=’button’…> to <button …>.

Here is a reproducer that captures the essence of what the app is doing. The actual app uses the post method and does useful stuff.

...
<p>Doesn't work on Firefox 2</p>
<form id="f1" method="get"
  action="http://hardlikesoftware.com/weblog/">
    <label for="someinput">Label:</label>
    <input type="text" value="foo" id="someinput">
    <button id="b1"
      onclick="this.disabled=true;document.forms.f1.submit();">
        Disable and Submit
    </button>
</form>
<p>Doesn't work on Firefox 3 - here the button works like a link</p>
<form id="f2" method="get"
  action="http://hardlikesoftware.com/weblog/">
    <label for="someinput2">Label:</label>
    <input type="text" value="bar" id="someinput2">
    <button id="b2"
      onclick="this.disabled=true;self.location.href='http://www.google.com'">
        Goto
    </button>
</form>
...

The expected behavior is that the “Disable and Submit” button will take you to the HardLikeSoftware main page and the “Goto” button will take you to google. On Firefox 2 the first button gets disabled and no request of any kind is sent. The second button works fine. On Firefox 3 the first button works as desired but the second button submits the form and you end up at the HLS main page. The problem goes away if you use IE7, Opera, or Safari (I suspect IE6 also works), or change the button elements to input buttons, or move the buttons outside of the form. If you don’t disable the buttons then the first button works in both Firefox 2 and 3 but the second button doesn’t work in either.

When I first noticed the behavior I thought I was going crazy. The first step in figuring it out was isolating the problem to something like the simple reproducer above. I also used Firebug to step through the JavaScript and used the Live HTTP Headers plug-in to verify that no request was being sent in the first case.

It was the behavior of the second button that finally tipped me off when I realized that it was actually submitting the form. Noticing this was more difficult with the actual app simply because of the way it works.

The code had been getting away with not returning true or false from the click handler for a long time. Simply adding “return false; to the event handlers solves all the problems and continues to work in the other browsers. Returning false from the click event means don’t take the default action. For a submit button the default action is to submit the form.

Another aspect to this issue is that when you use the input element to create a button you make a conscious choice between a submit button and a regular button. But when you use the button element it is a submit button by default. Thanks to IE the default isn’t a very useful default because you can’t use it this way.

The moral of the story is always return an appropriate value from an event handler. Also it may not be a bad idea to be specific about they type of button. Although it looks redundant <button type=’button’> may be the way to go.

There is an online version of JSLint, which is cool, but we don’t build our software by pasting it into online forms right? It is natural to want to use JSLint from Ant assuming you’re in the Java world. The JSLint documentation gives pretty good motivation for why you would want to use JSLint as part of your build.

Besides the web version JSLint comes in WSH or Rhino command line versions. I could exec a Rhino command line from Ant but I wanted something a little more integrated. I wanted to be able to do something like this:

<jslint options="{passfail: false, browser: true}">
    <fileset dir="${src.dir}">
        <include name="javascript/*.js"/>
        <include name="lib/js/*.js"/>
    </fileset>
</jslint>

I looked around for an existing ant task. There is a Java command line version jslint4java that has an ant task. I have not tried it so I can’t say anything about how it works.

It seemed to me that since JSLint is written in JavaScript that it should be possible to use it with an ant scriptdef tag. Here is how to do it.

1. Download fulljslint.js and make a copy of it called jslintant.js.
2. Depending on your version of ant you may need newer versions of Rhino and BSF. I used js.jar from Rhino 1.6R7 and BSF 2.4.0.
3. Edit jslintant.js and add these lines to the very bottom of the file.

   importClass(java.io.File);
   importClass(Packages.org.apache.tools.ant.util.FileUtils);
   importClass(java.io.FileReader);
   
   var options = attributes.get("options")
   var fileset;
   var ds;
   var srcFiles;
   var jsfile;
   
   project.log("Attribute options = " + options);
   eval("options = " + options + ";");
   
   if (elements.get("fileset").size() > 0) {
       // should only be one fileset
       fileset = elements.get("fileset").get(0);
   
       ds = fileset.getDirectoryScanner(project);
       srcFiles = ds.getIncludedFiles();
   
       // for each srcFile
       for (i = 0; i < srcFiles.length; i++) {
           jsfile = new File(fileset.getDir(project), srcFiles[i]);
           checkFile(jsfile);
       }
   }
   
   function checkFile(file, options) {
       // read the file into a string and make it a real
       // JavaScript string!
       var reader = new FileReader(file);
       // readFully returns java.lang.String
       // new String makes it a java String object
       var input = new String(FileUtils.readFully(reader));
       // this makes the type string, which is important
       // because JSLINT assumes that input is an array
       // if it is not typeof string.
       input = input.toString();
       if (!input) {
           print("jslint: Couldn't open file '" + file.toString() + "'.");
           return;
       }
       if (!JSLINT(input, options)) {
           project.log("jslint: Problems found in " + file.toString());
           for (var i = 0; i < JSLINT.errors.length; i += 1) {
               var e = JSLINT.errors[i];
               if (e) {
                   project.log('Lint at line ' + (e.line + 1) + ' character ' +
                           (e.character + 1) + ': ' + e.reason);
                   project.log((e.evidence || '').
                           replace(/^\s*(\S*(\s+\S+)*)\s*$/, "$1"));
                   project.log('');
               }
           }
       } else {
           project.log("jslint: No problems found in " + file.toString());
       }
   }

4. Add a scriptdef element to your ant target as follows.

   <scriptdef name="jslint"
           src="${path_to_script}/jslintant.js"
           language="javascript">
       <attribute name="options"/>
       <element name="fileset" type="fileset"/>
   </scriptdef>

Now you can use the jslint task as shown above.