Blog - Microsoft .NET, ASP.NET, AJAX and more

AJAX Control Toolkit - Layout Problems

by Damien White 6/11/2008 9:55:07 PM

A real common problem with using the AJAX Control Toolkit revolves around the rendering of the controls.  Taking an example from the ASP.NET Forums, let's say you have a Tab Control on your page.  Everything looks ok, and then you run it.  You notice that there is a weird space towards the bottom of one of your tabs.  D'oh!  What could be wrong?  Well, in general, usually the cause of these types of problems are related to one of two issues, Quirks Mode or CSS conflicts.  In the ASP.NET Forum example above, it was a Quirks Mode issue.

  1. Quirks Mode - A complete definition as well as what causes Quirks Mode to occur can be found on Wikipedia.  A quick definition is that Quirks Mode is a type of rendering that the browser adheres to.  Typically, a browser supports Quirks Mode and Standards Mode rendering.  The main difference between the two have to do with the box model and how things are calculated.  For example, if you have a DIV with a width of 100px, and that DIV has a padding of 5px, is the DIV's width 100px or 110px?  Well that's the confusion.  In Standards Mode, it's 100px, in Quirks Mode, it's a narrower 90px because the padding takes up part of the width.  The thing you need to know is that the AJAX Control Toolkit assumes Standards Mode rendering, otherwise, things will be out of whack. 

    The Fix - Quirks Mode
    To fix this issue, it's as simple as verifying you are using a proper DOCTYPE (these can be found in the Wikipedia entry).  The other thing to note is whether you should include or exclude anything (such as an XML declaration) before the DOCTYPE, which is also described in the Wikipedia article.  For example, to designate a page as conforming to XHTML 1.1, you would have something along these lines (note I am using a Master page):

    <%@ Master enabletheming="true" Language="C#" AutoEventWireup="true" CodeBehind="MyMaster.master.cs" Inherits="MyMaster" %>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

  2. CSS - Another common problem occurs with CSS.  There are many times when a developer has a style that may conflict with that being set by the Toolkit Control.  An example of this could be something like having a style defined for all SPAN elements, and then realizing that the Tab Control doesn't look correctly.  It could really be just about any one of styles you can apply to elements.  Because of this,  this is a harder problem to catch and requires troubleshooting on your part.

    The Fix - CSS Issues
    The fix for this is just finding that pesky style that is causing you the issue.  Easier said than done.  However, there are some tools to make your job easier.  First, my favorite is an add-in called Firebug, but it only works in Firefox (although there is a "lite" version for IE).  You can inspect any element on the page, and get the CSS being applied, plus you can edit the style in real time!  It is a invaluable tool for debugging not just CSS, but also JavaScript, and it does so much more.  I would recommend it highly for every web developer. 

    On the Internet Explorer side, you can use the IE Developer Toolbar.  Like Firebug, you can inspect the styles for an element, but you can't manipulate or toggle them like you can with Firebug.

In my experience one of these have been the issue in just about every case I've come across.  I hope this helps in solving those ASP.NET AJAX Toolkit issues that you may come across in your applications.

Shout it kick it on DotNetKicks.com Bookmark and Share
Tags:
Categories: AJAX | AJAX Control Toolkit | ASP.NET | CSS
Actions: E-mail | Permalink | Comments (1) | Comment RSSRSS comment feed

Comments

6/12/2008 6:27:05 AM #

Giles

I also have several issues with the ordering of events on the page.
You can't define when behaviours are assigned (for example I might want to assign them manually after running a function on load), and in several instances, you can't hide the control in its initial state without breaking the behaviour of the toolkit).  Whilst you can do this to a certain extent hacking around on the client side it's not elegant in any stretch of the imagination!

The resizeable behaviour is particularly troublesome as it requires the item being resized to be fully displayed on screen when the page first renders (i.e. you can't have it set to display:none initially) otherwise all behaviour properties are set incorrectly and it won't work.  The calendar is also buggy with the release for the .Net 2.0 framework, not loading its CSS if it's rendered using a partial postback.

All in all, several pieces of work I've done since joining this company have involved ripping out the control toolkit elements and replacing them with more lightweight bespoke code that doesn't cause issues or break the layout!  A shame it wasn't tested more thoroughly really.

Giles United Kingdom

Comments are closed