Skip to the content Back to Top

I run into CSS position problems with IE6 every so often when using elements that float, or with position:absolute inside a position:relative parent. Not so often that I immediately recall how to fix it, of course, and each time the problem crops up it's just different enough from last time to appear as a separate and unrelated problem. Here's hoping that writing it down will make it stick. And of course, I get some catharsis in pointing a hysterical finger at that Great Satan behind all the problems, IE6 itself, which Norway has declared war on. I'm cheering for Norway, but IE6 has all the staying power and good looks of the cockroach, so I rather suspect it will smugly survive the Norwegian Gambit and become the official browser of the post-nuclear-exchange web.

The best description I've ever read of IE's layout deficiencies are covered in depth in the "On having layout" article at http://www.satzansatz.de/cssd/onhavinglayout.html, but for those who are more interested in applying the fix quickly without whys and wherefores, here it is: force the element to have "layout" by applying a width or height. There is more than one way to do this, but the following fulfills my needs.

Part One - zoom:1

Zoom is an MS proprietary CSS property that forces layout to any element in IE5.5+. Hide zoom with conditional comments if you want the CSS to validate. Doesn't work on IE5.0.

   1: <!--[if lte IE 7]><style type="text/css">
   2:     .someElement { zoom:1; }
   3: </style><![endif]-->
   4:         

More info in the "On having layout" article on hack management: http://www.satzansatz.de/cssd/onhavinglayout.html#hackmanagement.

Part Two - Standards Mode

This should really be part one. Do not allow your website to render in quirks mode! Choose and use a valid doctype before designing your layout so that all browsers render your pages in standards mode. Else you really cannot count on this fix or any other. Unless of course you are designing your site to only be viewed in IE6 come the onset of that nuclear winter, in which case you will also want to consider the usability requirements of your primary end user: the cockroach.

 

I swear to Somebody Above, or, if it will get results, to Something Below, that I simply cannot witness one more lame attempt to hitch an industry wagon to the "Web 2.0" star.

The whole Web 2.0 conceit is one that went down my gullet like a barbed meatball anyway, but okay, fine, I digested it and moved on with my life. At least it kind of means something now, I guess: AJAX-heavy apps, community collaboration, and candyshell logos.

Library 2.0 elicited a mild groan from me when I heard it, the kind of mewl that comes out of you the morning after 7 vodka martinis the night before, and now Sales 2.0 is something that just infiltrated my inbox and stabbed me in the eyeballs.

This 2.0 thing has gone too far.

It's important to be aware of what's happening out there in the web environment, the kind of impact it might have on your business or organization, and the evolving expectations of your customer/audience base, but to claw your way onto the latest bandwagon and call yourself Whatever 2.0 does not say: "We're boldly riding the bleeding edge of web technology." What it says is: "We haven't a clue but we're desperate to look cool."

Andornot 2.0, or, hoist with my own petard

Hmm. Eight hits on google from andornot.com for "web 2.0". Forty lashes with a wet noodle for this one, I think.

 

I'm looking at upgrading Macromedia Studio 8 and Adobe Photoshop CS2 etc. to the latest Creative Suite 3 Design Premium Suite, but no go in testing out the trial version of Dreamweaver. Every attempt to load up what appeared to be a successful install leads to: "A problem was encountered while trying to load the trial period for Adobe Dreamweaver CS3..." followed by something like "you'll have to go online a purchase a license in order to try this out." Apparently, I'm not alone - even paid versions are having install problems. One user even claims to have lost his job because of it. And no, this is not a Vista-specific issue.

Multiple attempts (I'm persistent) to install/reinstall/remove/reinstall/hack the registry/regsvr32 DLLs/etc. all lead to the same result. So why am I writing this up? Eventually it gave up being pretty in response; now every time I attempt to load it up I get the following:

Catastrophic

Just hilariously awesome.

I was going to call this post Blah blah blah: The Maddening, but a lucky dip into forums.asp.net just before I began to write saved my bacon. I now have a fix, and the madness has been reduced to a mere simmer from its former rolling boil.

The Sample

   1: <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs" Inherits="SaskatoonLibrary.OneSearch.WebForm1" %>
   2:  
   3: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   4:  
   5: <html xmlns="http://www.w3.org/1999/xhtml" >
   6: <head runat="server">
   7:     <title>Untitled Page</title>
   8: </head>
   9: <body>
  10:     <form id="form1" runat="server" defaultbutton="SearchButton">
  11:     <asp:ScriptManager ID="ScriptManager1" runat="server" />
  12:     
  13:     <asp:Panel ID="Panel1" runat="server">
  14:         <asp:TextBox ID="Textbox1" runat="server"></asp:TextBox>
  15:         <asp:Button ID="SearchButton" Runat="server" 
  16:             Text="Search"></asp:Button>
  17:     </asp:Panel>
  18:     
  19:     <asp:UpdatePanel ID="UpdatePanel1" runat="Server" 
  20:         UpdateMode="Conditional"
  21:         ChildrenAsTriggers="false">
  22:         <Triggers>
  23:             <asp:AsyncPostBackTrigger ControlID="SearchButton" />
  24:         </Triggers>
  25:         <ContentTemplate>
  26:             <asp:Repeater ID="Repeater1" runat="server"></asp:Repeater>
  27:         </ContentTemplate>
  28:     </asp:UpdatePanel>
  29:     
  30:     
  31:     </form>
  32: </body>
  33: </html>

The Issue

An ASP.NET AJAX* UpdatePanel on the page, triggered conditionally by a button. A single textbox in the form. Without some way of forcing the button to click when the ENTER key is pressed, the form merely does a postback, not a callback, thus rendering the the entire point of my UpdatePanel COMPLETELY NIL.

Note, in the sample above, that the form's DefaultButton attribute is set to SearchButton. This is the usual way to ensure that pressing ENTER fires the appropriate button click event server-side. And indeed, without an UpdatePanel in the picture, this works as advertised for both IE7 and Firefox.

But. Throw an UpdatePanel and the need to fire a callback into the mix, and Firefox pays no attention, but continues to postback when ENTER is pressed. Only IE7 performs correctly: the button's client-side click event is fired and the callback, not a postback, occurs.

The Not-fixes

These don't work. Don't waste your time. Either IE will be happy, or Firefox, but not both. (Remember? The Maddening?)

  1. Add a non-visible textbox to the form, which is a hack only suitable for ensuring the correct server-side event fires. Makes no difference to client-side callback initiation.
  2. Add a client-side onkeypress event to the textbox to check and see if the ENTER key has been pressed, and if it has, forcibly fire the relevant button's click event.
  3. Bang your head on the keyboard so hard people on the street stop and compliment you on the QWERTY tattoo.

The Fix

Set the button's UseSubmitBehavior attribute to false:

<asp:Button ID="SearchButton" Runat="server" 
    Text="Search"
    UseSubmitBehavior="false"
    ></asp:Button>

Apparently there's a little more monkeying to do if the button is an ImageButton:

<asp:ImageButton ID="ImageButton1" runat="server"
            OnClientClick="this.disabled=true;__doPostback(this.name,'');"
         />

 

 

* In the name of Cyclopean Cthulhu, couldn't we just have kept calling it by its in-development codename: "Atlas"? It feels like a mouthful of marbles every time I say "ASP.NET AJAX". And I have to write it in all caps? Fwah!

 

I've been reading and re-reading the latest book by Peter Morville (of "Information Architecture for the World Wide Web" fame). It is an easy read, in that it is fast paced, well written, often humorous, with information on fascinating new developments and concepts. However for anyone involved in designing websites and search interfaces, there is also a wealth of information on usability that needs to be reviewed in more depth. The book is full of references and quotes from a myriad of sources. Since its publication a de.licio.us bibliography has been created with links to many of them, making further research much easier. I'm now aware of concepts like ubiquitous computing; wayfinding; intertwingling, folksonomies and the sociosemantic web. I'm struck by Mooers' law that states that people may avoid using a system because it gives information which they have to try and understand, and which may be painful and troublesome. As Morville says, we cannot assume people will want our information, even if we know they need it, and that behind most failed websites is a misguided model of users and their information seeking behaviours. This reminds us that the design of useful systems requires a deep understanding of users and their social context. Morville is a librarian and discusses the failure of library initiatives such as Dublin Core to garner acceptance in the wider arena, as well as condemning ALA president Michael Gorman's negative comments on blogging. However it is not a book just for librarians, but for anyone interested in the latest research on information retrieval and interface design. "Ambient Findabilty", by Peter Morville. O'Reilly: 2005. 204 pages. ISBN: 0-596-00765-5. Check out these related websites: Findability.org; Business Week, November 9th 2005 interview with Peter Morville; reviews at Amazon.com.

Let Us Help You!

We're Librarians - We Love to Help People