This is a technique that I really like. It’s excellently suited to intranet sites and administrative interfaces, where your users are typically familiar enough with the application to know which text they can click to edit. It’s actually very easy to implement, with a small amount of JavaScript.

To get started, we need a web form to display the inline text Label and a hidden TextBox that will be swapped in for editing:

<asp:ScriptManager ID="ScriptManager1" runat="server" 
  EnablePageMethods="true">
  <scripts>
    <asp:ScriptReference Path="behaviors.js" />
  </scripts>
</asp>
<asp:Label runat="server" ID="Label1" />
<asp:TextBox runat="server" ID="TextBox1" Style="display: none;" />

Note that instead of using the Visibility property of the TextBox, I used CSS to hide it. This is important because ASP.NET renders no HTML for invisible server controls, making them unavailable for client side manipulation.

For the sake of brevity, I’m going to use the Cache to populate our Label. You could just as easily use a database, file, or other data store instead.

protected void Page_Load(object sender, EventArgs e)
{
  if (Cache["Title"] != null)
    Label1.Text = Cache["Title"].ToString();
  else
    Label1.Text = "Default Title (click to edit)";
}

Using JavaScript to toggle the elements

First, we’re going to need an Application Init handler to set up client side event handlers on the Label and TextBox.

>All of the following JavaScript code blocks are excerpts from behaviors.js.

var Label1, TextBox1;
 
Sys.Application.add_init(AppInit);
 
function AppInit(sender) {
  Label1 = $get('Label1');
  TextBox1 = $get('TextBox1');
 
  $addHandler(Label1, "click", Label1_Click);
 
  $addHandler(TextBox1, "blur", TextBox1_Blur);
  $addHandler(TextBox1, "keydown", TextBox1_KeyDown);
}

In addition to wiring up the event handlers, I’ve set up a couple global variables to hold references to the Label and TextBox elements. This avoids excessive $get() calls and improves readability a bit.

Next, let’s handle the click event of our Label:

function Label1_Click() {
  TextBox1.value = Label1.innerHTML;
 
  Label1.style.display = 'none';
  TextBox1.style.display = '';  // Thanks, Ira.
 
  TextBox1.focus();
}

A few things happen here:

• First, to make sure everything stays in sync, the TextBox’s value is always overwritten with the Label’s current text before showing it.
• Then, by toggling the display properties of the two elements, we effectively make an instant swap from Label to TextBox.
• Finally, using the focus() method of the TextBox will place the cursor in the newly displayed TextBox.

This sequence of events creates an intuitive user experience. It’s just as if clicking the text simply placed the cursor into a text editing field that had been there all along.

Next, we’ll handle the blur event of the TextBox.

function TextBox1_Blur() {  
  Label1.innerHTML = TextBox1.value;
 
  TextBox1.style.display = 'none';
  Label1.style.display = '';  // Thanks, Ira.
}

This updates the Label with the TextBox’s new value and then toggles both elements’ visibility again. This is just the inverse of the Label1_Click() function.

The enter key is a habitual troublemaker

A problematic scenario is when the user presses enter while editing. Pressing enter in the TextBox will submit the form and generate an undesired postback. In fact, this scenario is probably more likely than the user blurring the TextBox to finish editing.

Luckily, the solution is simple:

function TextBox1_KeyDown(event) {
  if (event.keyCode == 13) {
    event.preventDefault();  // Thanks, Alessandro.
    TextBox1.blur();
  }
}

What this does is intercept any enter key press, cancel the pending form submission, and then blur the TextBox so that things proceed as desired.

Put it back, before anyone notices it’s missing

If we don’t save the edits back to the server somehow, none of this is worth much. The UpdatePanel and __doPostBack() combination comes to mind as one way to save, via partial postback. However, UpdatePanels have dangerous performance drawbacks, I’m going to avoid using them here.

Instead, I think this is yet another great situation for using JSON and page methods.

First, we’ll need a static method for saving to our data store. As I mentioned earlier, I’m using the Cache for simplicity, but in your code you could just as easily update a database field or write to a file here.

[WebMethod]
public static void SetTitle(string title)
{
  HttpContext.Current.Cache["Title"] = title;
}

Note: Since an instance of the Page class is not created during a static page method callback, HttpContext isn’t directly available in our method. Due to this, the Cache class needs to be referenced as shown. Simply using Cache["Title"] won’t work in a static method.

So, now we’ve got a mechanism to save our data. Now, all we have to do is modify our TextBox’s blur event handler to utilize it:

function TextBox1_Blur() {   
  Label1.innerHTML = TextBox1.value;
 
  TextBox1.style.display = 'none';
  Label1.style.display = 'inline';
 
  PageMethods.SetTitle(TextBox1.value);
}

That’s it!

Notice that there isn’t an UpdatePanel anywhere on the page. Those things aren’t nearly as necessary as you may believe! Using JSON makes this work very quickly, efficiently, and unobtrusively.

Ways to make it better (always)

This is just the beginning. A few potential improvements include:

• Check the TextBox’s content against the Label on blur, and only call SetTitle() if the content has actually been edited.
• If working with a slow data store, progress indication may be beneficial.
• Resize the TextBox, based on the size of the Label.
• Use some sort of background image to indicate that the content is editable inline.
• Handle the ESC keyCode (27) and “cancel” the edit by switching back to the Label without changing its content.
• Can you think of any other improvements? Let’s hear about them in the comments.

Give it a try for yourself (this source includes the first suggested improvement):

Update: This functionality is also available as an ASP.NET server control. Inline Edit Box .NET