Tatham Oddie

Here’s what my Start Bar looks like:

Specifically, you’ll notice that I have all the major browsers there as first class citizens. When I want to launch a browser, I just randomly move my mouse towards the bottom left of my screen and click which ever browser I hit first. As I write this post, I’m using four of them to browse the web. LastPass deals with my passwords and I don’t use bookmarks anyway.

I do this to maintain my knowledge of all the browsers, to help me be a better web developer.

For day-to-day browsing, this works fine. For development though, I find myself actively switching to Firefox just so I can use Firebug. On paper, Internet Explorer’s developer tools do everything Firebug does. In practice, I’ve just never liked them as much. Even with the current progress on consistent rendering, we need good development tools in all the browsers.

Over the last few days, I’ve been exclusively using the Internet Explorer 9 developer tools. I’ve noted each feature that I think needs work. Now, I want to add your feedback so that we can build a cohesive set of requests for the IE team. None of these suggestions will make it into the IE9 release, but now is a good time to get our feedback in before they commence planning for IE10.

General Browser

• JS error dialog is annoying as hell – would be good to say “stop showing error dialogs” after the first one, and route the rest of the text to the console
• Would be nice to be able to view JSON responses in the browser instead of getting a download prompt, just like XML

Console tab

• Aaron Powell has written a great post on the limitations of console.assert in IE9

HTML tab

• Minor, but the HTML should really get renamed to DOM. It feels a bit silly telling people to go to the HTML tab when they want to see how an SVG is structured
• Selecting an element in the DOM should outline it on the page
• Can’t delete an element
• Adding CSS properties in dev tools (should be able to do it from trace styles, not via attributes)
• "Edit" button in DOM always seems to edit the wrong node
• Typing style=" to add an attribute results in style="" which works against the habit
• Rename "Trace Styles" to "Applied Styles" and make it the default
• Rename "Style" to “Trace Styles” and make it second
• Layout pane is too chunky – always have to make the dev tools bigger just to see it
• With an active node in the DOM, need a way to get into the attribute editing via the keyboard only F2

Script tab

• Whenever I hit “Start Debugging”, the dev tools undock and docking gets disabled. Seems unrelated and certainly annoying.

CSS tab

• "This stylesheet cannot be viewed because its source is in a different domain than the page."

General dev tools

• Why is there a "Clear Browser Cache" button in the HTML + CSS tabs? It’s already in the menu.
• Why is Disable > Script not available? (It’s there, but greyed out.)
• Consolas over Courier please.

What are you suggestions? Comment on this post.

I’m on the Microsoft campus in Seattle this week so I’ll be championing as many of these issues with the IE team as I can.

Last REMIX AU I talked about geolocation and people loved it.

Now I want to take the talk to MIX in Vegas.

Please help: http://l.tath.am/gJuCTD

(Update: Session voting has closed and Microsoft have removed the page)

At REMIX10, TechEd AU 2010 and TechEd NZ 2010 I’ve been showing some of what’s new in Internet Explorer 9 for developers.

Here are the slides and code: http://db.tt/JvEUu3o

The recording from TechEd New Zealand (the third and best version!) is available here: http://www.msteched.com/2010/NewZealand/WEB304

The recording from TechEd Australia (version 2 of the talk) is available here: http://www.msteched.com/2010/Australia/WEB204

And finally, here’s a recording from REMIX10 Australia (version 1 of the talk): http://www.microsoft.com/australia/remix/videos/default.aspx

If you’ve attended any of these talks, thank you for your feedback! The session evals at conferences are like crack for speakers. We read every single one, and then we read them again.

– Tats

At both the REMIX10 conference in Melbourne, Australia and more recently TechEd New Zealand I presented on geolocation for developers.

This was the abstract:

It’s pretty obvious by now that geolocation is a heavy player in the next wave of applications and APIs. Now is the time to learn how to take advantage of this information and add context to your own applications. In this session we’ll look at geolocation at every layer of the stack – from open protocols to operating system APIs, from the browser to Windows Phone 7. Building a compelling geo-enabled experience takes more than simple coordinates. In this session Tatham will introduce the basics of determining a user’s location and then delve into some of the opportunities and restrictions that are specific to mobile devices and their interfaces.

The talk was filmed at TechEd New Zealand, and is available for download here: http://www.msteched.com/2010/NewZealand/WEB205

(Note: this version has a Windows Phone 7 demo in it too.)

The first version of the talk was also filmed at REMIX10, and is available for download here: http://www.microsoft.com/australia/remix/videos/default.aspx

Here are some links to the code and resources (but you really want to watch the talk first):

• My demo code
  http://gist.github.com/423252
• The W3C Geolocation API spec
  http://dev.w3.org/geo/api/spec-source.html
• The Flickr findByLatLon WOEID API
  http://www.flickr.com/services/api/explore/?method=flickr.places.findByLatLon
• The core WOEID API
  http://developer.yahoo.com/geo/geoplanet/
• My recent locations
  http://tath.am/where
• The code that generates my personal location map
  http://github.com/tathamoddie/longitude/blob/master/longitude.rb

(Post last updated 7th Sep 2010 with new links and videos)

Over the last few months Damian Edwards and myself have been spending quite a bit of time building out a Model-View-Presenter framework for ASP.NET Web Forms.

Until now we’ve been pretty quiet about it all on our blogs because we were busy polishing off v1 and trying to get all the documentation in order. Nevertheless, the word has definitely started to spread as Scott Hanselman interviewed me about the library on this week’s Hanselminutes episode.

Listen to the podcast

Learn more about the library

Following up from my last post about the ASP.NET MVC vs ASP.NET WebForms debate, we’ve had a second TechTalk posted, also from TechEd Australia. In this video, Michael Kordahi, Damian Edwards and I sat down to discuss building fast, public websites. It was a bit of a teaser for our breakout session at the conference, which will be available online as a screencast in the next week or two.

If you’re interested in learning more about building large public websites on ASP.NET, remember that the full video from our recent REMIX session is still available online too.

Watch Online or Download

At the recent TechEd Australia conference, Paul Glavich, Damian Edwards and myself sat down to discuss what we thought about the current MVC vs WebForms debate. Our TechTalk has now been posted on the TechEd Online site, and available for anyone to watch.

Check it out, and feel free to continue the debate with any of us.

Watch Online or Download

If you’ve read my previous post explaining a common pitfall with view state, I’d hope you’re preparing all your controls in the Init event of the page/control lifecycle.

Even if I’m not reusing them through my application much, I like to factor elements like a drop down list of countries into their own control. This centralizes their logic and allows us to write clear, succinct markup like this:

<tat:CountriesDropDownList ID="AddressCountry" runat="server" />

The code for a control like this is quite simple:

[ToolboxData("<{0}:CountriesDropDownList runat=\"server\" />")]
public class CountriesDropDownList : DropDownList
{
    protected override void OnInit(EventArgs e)
    {
        DataSource = Countries;
        DataBind();

        base.OnInit(e);
    }
}

The Problem

Once you start using this encapsulation technique, it won’t be long until you want to pass in a parameter that affects the data you load. Before we do, we need to be aware that the Init event is fired in reverse order. That is, the child controls have their Init event fired before that event is fired at the parent. As such, the Page.Init event is too late for us to set any properties on the controls.

The natural solution is to try and use the Page.PreInit event, however when you do you’ll often find that your control references are all null. This happens when your page is implemented using a master page, and it relates to how master pages are implemented. The <asp:ContentPlaceHolder /> controls in a master page use the ITemplate interface to build their contents. This content (child controls) is not usually prepared until the Init event is called, which means the control references are not available. For us, this represents a problem.

The Solution

The fix is remarkably simple; all we need to do is touch the Master property on our Page and it will cause the controls to become available. If we are using nested master pages, we need to touch each master page in the chain.

I often create a file called PageExtensions.cs in my web project and add this code:

public static class PageExtensions
{
    /// <summary>
    /// Can be called during the Page.PreInit stage to make child controls available.
    /// Needed when a master page is applied.
    /// </summary>
    /// <remarks>
    /// This is needed to fire the getter on the top level Master property, which in turn
    /// causes the ITemplates to be instantiated for the content placeholders, which
    /// in turn makes our controls accessible so that we can make the calls below.
    /// </remarks>
    public static void PrepareChildControlsDuringPreInit(this Page page)
    {
        // Walk up the master page chain and tickle the getter on each one
        MasterPage master = page.Master;
        while (master != null) master = master.Master;
    }
}

This adds an extension method to the Page class, which then allows us to write code like the following:

protected override void OnPreInit(EventArgs e)
{
    this.PrepareChildControlsDuringPreInit();

    MyCustomDropDown.MyProperty = "my value";

    base.OnPreInit(e);
}

Without the call to the extension method, we would have received a NullReferenceException when trying to set the property value on the MyCustomDropDown control.

You now have one less excuse for preparing your controls during the Load event.

(If you don’t get the title reference, Wikipedia can explain. A more direct title could be: Understanding and Respecting the ASP.NET Page Lifecycle.)

This whole article needs a technical review. Parts of it are misleading. I’ll get back to you Barry.

Page lifecycle in ASP.NET is a finicky and rarely understood beast. Unfortunately, it’s something that we all need to get a handle on.

A common mishap that I see is code like this:

protected void Page_Load(object sender, EventArgs e)
{
    if (!Page.IsPostBack)
    {
        AddressCountryDropDown.DataSource = CountriesList;
        AddressCountryDropDown.DataBind();
    }
}

The problem here is that we’re clogging our page’s view state. Think of view state as one of a page’s core arteries, then think of data like cholesterol. A little bit is all right, but too much is crippling.

To understand the problem, lets investigate the lifecycle that’s in play here:

1. The Page.Init event is being fired, however we are not subscribed to that.
2. Immediately after the Init event has fired, view state starts tracking. This means that any changes me make from now on will be saved down to the browser and re-uploaded on the next post back.
3. The Page.Load event is being fired in which we are setting the contents of the drop down list. Because we are doing this after the view state has started tracking, every single entry in the drop down is being written to both the HTML and the view state.

There’s yet another problem here as well. By the time the Page.Load event is fired, all of the post back data has been loaded and processed.

To investigate the second problem, let’s investigate the lifecycle that’s in play during a post back of this same page:

1. The user triggers the post back from their browser and all of the post back data and view state is uploaded to the server.
2. The Page.Init event is fired, however we are not subscribed to that.
3. Immediately after the Init event has fired, view state starts tracking. This means that any changes me make from now on will be saved down to the browser and re-uploaded on the next post back.
4. The view state data is loaded for all controls. For our drop down list example, this means the Items collection is refilled using the view state that was uploaded from the browser.
5. Post back data is processed. In our example, this means the selected item is set on the drop down list.
6. The Page.Load event is fired however nothing happens because the developer is checking the Page.IsPostBack property. Usually, they say this is a “performance improvement” however it is also required in this scenario otherwise we would lose the selected item when we rebound the list.
7. The contents of the drop down list are once again written to both the HTML and the view state.

How do we do this better? Removing the IsPostBack check and placing the binding code into the Init event is all we need to do:

protected override void OnInit(EventArgs e)
{
    AddressCountryDropDown.DataSource = CountriesList;
    AddressCountryDropDown.DataBind();

    base.OnInit(e);
}

What does this achieve?

• We are filling the contents of the drop down before the Init event is fired; therefore a redundant copy of its contents is not written to the view state.
• We are filling the contents of the drop down before the postback data is processed, so our item selection is successfully loaded without it being overridden later.
• We have significantly reduced the size of the page’s view state.

This simple change is something that all ASP.NET developers need to be aware of. Unfortunately so many developers jumped in and wrote their first ASP.NET page using the Page_Load event (including myself). I think this is largely because it’s the one and only event handler presented to us when we create a new ASPX page in Visual Studio. While this makes the platform appear to work straight away, it produces appalling results.

As this is a suggestion which comes up quite regularly, I felt it valuable to document some of the research I have collected about the readability of light text on dark backgrounds.

The science of readability is by no means new, and some of the best research comes from advertising works in the early 80s. This information is still relevant today.

First up is this quote from a paper titled “Improving the legibility of visual display units through contrast reversal”. In present time we think of contrast reversal meaning black-on-white, but remember this paper is from 1980 when VDUs (monitors) where green-on-black. This paper formed part of the research that drove the push for this to change to the screen formats we use today.

However, most studies have shown that dark characters on a light background are superior to light characters on a dark background (when the refresh rate is fairly high). For example, Bauer and Cavonius (1980) found that participants were 26% more accurate in reading text when they read it with dark characters on a light background.

Reference: Bauer, D., & Cavonius, C., R. (1980). Improving the legibility of visual display units through contrast reversal. In E. Grandjean, E. Vigliani (Eds.), Ergonomic Aspects of Visual Display Terminals (pp. 137-142). London: Taylor & Francis

Ok, 26% improvement – but why?

People with astigmatism (aproximately 50% of the population) find it harder to read white text on black than black text on white. Part of this has to do with light levels: with a bright display (white background) the iris closes a bit more, decreasing the effect of the "deformed" lens; with a dark display (black background) the iris opens to receive more light and the deformation of the lens creates a much fuzzier focus at the eye.

Jason Harrison – Post Doctoral Fellow, Imager Lab Manager – Sensory Perception and Interaction Research Group, University of British Columbia

The "fuzzing” effect that Jason refers to is known as halation.

It might feel strange pushing your primary design goals based on the vision impaired, but when 50% of the population of have this “impairment” it’s actually closer to being the norm than an impairment.

The web is rife with research on the topic, but I think these two quotes provide a succinct justification for why light text on a dark background is a bad idea.