none
Table bug in IE8 (complete with repro case)

    Question

  • I have found a bug in Internet Explorer 8: table cells are changing their width for no apparent reason when the cell contents are changed.  Following is a full repro case:

    <style type="text/css">
    	#buggedTable 
    	{
    		table-layout: fixed;
    		border-collapse: collapse;
    		border: 1px solid black;
    		width: 100%;
    	}
    	
    	#buggedTable td, th 
    	{
    		border: 1px solid black;
    		overflow: hidden;
    		white-space: nowrap;
    	}
    	
    	#buggedTable td > input
    	{
    		max-width: 100%;
    	}
    </style>
    ...
    <table id="buggedTable">
    	<colgroup>
    		<col style="width: 100px;" />
    		<col style="width: 100px;" />
    		<col style="width: 100px;" />
    		<col style="width: auto;" />
    	</colgroup>
    	<thead>
    		<tr>
    			<th>Col1</th>
    			<th>Col2</th>
    			<th>Col3</th>
    			<th>Col4</th>
    		</tr>
    	</thead>
    	<tbody>
    		<tr>
    			<td>Value 1-1</td>
    			<td>Value 1-2</td>
    			<td>Value 1-3</td>
    			<td>Value 1-4</td>
    		</tr>
    		<tr>
    			<td>Value 2-1</td>
    			<td>Value 2-2</td>
    			<td>Value 2-3</td>
    			<td>Value 2-4</td>
    		</tr>
    		<tr>
    			<td>Value 3-1</td>
    			<td>Value 3-2</td>
    			<td>Value 3-3</td>
    			<td>Value 3-4</td>
    		</tr>
    		<tr>
    			<td>Value 4-1</td>
    			<td>Value 4-2</td>
    			<td>Value 4-3</td>
    			<td>Value 4-4</td>
    		</tr>
    		<tr>
    			<td>Value 5-1</td>
    			<td>Value 5-2</td>
    			<td>Value 5-3</td>
    			<td>Value 5-4</td>
    		</tr>
    	</tbody>
    </table>
    ...
    <script type="text/javascript">
    
    	$(function() {
    	
    		$("#buggedTable td").toggle(
    			function() { 
    				var el = $(this);
    				var oldValue = el.text();
    				el.data("oldValue", oldValue);
    				
    				el.empty();
    				el.append($("<input type='text' value='" + oldValue + "' />"));
    			},
    			function() { 
    				var el = $(this);
    				el.empty();
    				el.text(el.data("oldValue"));
    			}
    		);
    	});
    </script>
    This example is a simplified version of the Excel-like grid I'm working on.  Yes, this example uses jQuery, but I do not believe this to be a problem with jQuery (and jQuery is supported by Microsoft anyway).  When a user clicks a cell, the cell's contents are placed in an input element, which is then inserted into the cell.  When the user clicks again, the cell is restored to its previous value.  This is when the bug occurs.  Examining the page with the IE Dev tools, the column loses 3px off its width.  Probably not coincidentally, this is exactly how much space the horizontal padding and border occupies.  According to IE, no style properties have changed on the cell, but it does report that it's layout width has changed by 3px for no apparent reason.  Note that the table cells are given fixed widths (except the last one), that table layout is fixed, and that overflow is hidden, so table cells should not resize no matter what happens to the contents of the cell.  They definitely shouldn't lose 3px like they are.  I also tried zeroing out the cell border and padding, but the bug still occurs, but it only loses 1px off the width. 

    Also, this occurs randomly, it does not happen every time.  Usually I can click around randomly and get it to occur within a few seconds, so it's often enough that it's a serious problem for what I'm trying to do.  It also doesn't always manifest itself immediately.  Sometimes a cell will *appear* to have the correct width, but clicking on a completely unrelated cell (meaning one that is not bordering the cell) will suddenly cause the other cell to shrink by 3px.

    Anyone have any ideas?
    Wednesday, August 05, 2009 2:33 PM

All replies

  • Oh, I should also note that I cannot fix the width back to the correct value using the IE Developer tools.  If I try to change the width from 97px back to 100px on a bugged cell, the width is ignored. 
    Wednesday, August 05, 2009 2:33 PM
  • Additional information:

    - The bug occurs regardless of what type of content change occurs in the cell.  I can insert a <span> or just change the text, and cells will randomly contract by 3px. 
    - Sometimes bugged cells will later reexpand and gain back the 3px they lost.
    - Alert-ing the td width at various points shows that the 3px is lost in random places each time.  Sometimes its when the value of the cell is cleared, sometimes its when the new value is set, sometimes its at some point *much* later than the cell's value was changed...

    Anyone know where you can file an actual bug report for IE?
    Wednesday, August 05, 2009 3:32 PM
  • Sorry to continue to bump this topic, but further testing has revealed that a single CSS attribute is to blame: table-layout:fixed.  Without this attribute, the table behaves as I would expect.  With the attribute, I get the buggy behavior.  Unfortunately, I *must* have table-layout:fixed, otherwise cells will expand to fit their contents, and I don't want that.  So, Microsoft, where can I submit a bug report?
    Wednesday, August 05, 2009 5:47 PM
  • Hello,

    We have the same problem in IE8. Basically it boils down to having table-layout:fixed and padding on the cells. Here is a simple HTML that reproduces the problem. After opening it in the browser try selecting the text with mouse, after a few selections the cells start shrinking to the width with no padding and you can see the table background through.

    Please take a look at the problem ASAP. As a major component development company we can no longer give our customers an answer like "This is a bug in IE8". A temporary workaround would be appreciated as well.

    Thank you,

    Alex Kartavov,
    Infragistics

    <%@ Page Language="C#" AutoEventWireup="true" CodeFile="TableBug.aspx.cs" Inherits="Default2" %>

     

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

     

    <html xmlns="http://www.w3.org/1999/xhtml">

    <head runat="server">

        <title></title>

        <style type="text/css">

       

        tbody.cellStyle > tr > td

        {

          background-color:White;

          border:Solid 1px Green;

          padding:5px 8px 5px 8px;

          font-family:Verdana;

          font-size:10px;

          text-align:left;

          vertical-align:middle;

          height:20px;

          overflow:hidden;

          cursor:default;

        }

       

        </style>

    </head>

    <body>

        <form id="form1" runat="server">

     

          <div style="width:370px">

                <table style="table-layout:fixed;background-color:Gray;width:100%;" border="0" cellpadding="0" cellspacing="0">

                      <tbody class="cellStyle">

                            <tr><td>One</td><td>One</td></tr>

                            <tr><td>Two</td><td>Two</td></tr>

                            <tr><td>Three</td><td>Three</td></tr>

                      </tbody>

                </table>

          </div>

        </form>

    </body>

    </html>

    Tuesday, September 08, 2009 6:34 PM
  • Can anybody help with this please?
    To see how bad it is in the actual control please visit this sample's page and select text inside of the grid with mouse. It does appear to be IE8 bug as it is not reproducible in any other browser.
    http://samples.infragistics.com/2009.1/WebFeatureBrowser/contents.aspx?showCode=True&t=WebDataGrid/DataBinding/WebDataGridDataBind.aspx~srcview.aspx?path=~srcview.aspx?path=WebDataGrid/DataBinding/WebDataGridDataBind.src
    Thursday, September 10, 2009 1:30 PM
  • It does appear to be IE8 bug as it is not reproducible in any other browser
    I indeed don't see it in IE6. However I am not sure if I do the test properly. Can you precise if the bug doesn't hit IE7 or IE6? TIA,

    Versailles, Fri 25 Sep 2009 23:06:35 +0200
    Friday, September 25, 2009 9:06 PM
  • Hi Alex, Start by validating your markup. http://validator.w3.org/check?verbose=1&uri=http%3a%2f%2fsamples.infragistics.com%2f2009.1%2fWebFeatureBrowser%2fcontents.aspx%3fshowCode%3dTrue&t=WebDataGrid%2fDataBinding%2fWebDataGridDataBind.aspx%7esrcview.aspx%3fpath%3d%7esrcview.aspx%3fpath%3dWebDataGrid%2fDataBinding%2fWebDataGridDataBind.src There are critical errors on that page that cause IE8 to fall back to Quirks mode. It is important that when you are testing your pages in IE8 that you first uncheck "Recover from rendering errors with Compatibility View" on the Advanced tab of Internet Options. Regards.
    Rob^_^
    Saturday, September 26, 2009 10:45 AM
  • Hi IECUSTOMIZER,

    I do not see a "Recover from rendering errors with Compatibility View" option on the Advanced tab.  I'm using IE 8 on Windows 7 x64.

    I do not think the problem has to do with invalid markup.  The stripped-down sample I posted in the first message validates with no errors, yet the bug shows up just fine.

    Fortunately, I did find a solution to this bug: just install Chrome Frame!  http://code.google.com/chrome/chromeframe/  I'm going to add a polite warning to liteGrid that urges people to either get a real browser or at the least install Chrome Frame.
    Saturday, September 26, 2009 9:01 PM
  • Hi Matt,

    I'm glad you wrote this up - I'm affected by the same problem.

    I thought I'd let you know that pushing the browser into compatibility mode seems to fix the issue, at least for us. Unfortunately, in our case, doing so using the appropriate meta tag causes other problems, so we have to ask our users to manually select compatibility mode (another thing I'm not super-happy about).

    Any ETA on a fix, Microsoft? It's dead easy to reproduce, and it's obviously a bug. I've put an example up at http://ziggyfoo.com/jqgrid/

    Edit a few cells... it might not happen the first time, but it will happen eventually.



    Tuesday, September 29, 2009 6:16 AM
  • Unfortunately liteGrid makes use of some CSS 2.0 things that are broken when in compatibility view, so unfortunately that doesn't work for me.  I'm considering adding a second layout provider to liteGrid that will render using div tags instead of table cells.  I've seen other grids go that route to work around table bugs in IE. 

    As for a Microsoft response, I've basically given up on one.  If there is a way for customers to report IE8 bugs, I can't find it, and they don't seem to be interested in replying in this forum. :(
    Tuesday, September 29, 2009 1:01 PM
  • We've got the same problem using SQL Server Reporting Services with stoplights. Has Microsoft given you any response? I thought the bad-old days of kludge work-arounds for browsers were over. Please don't tell me the Firefox zealots are right!!! 
    Wednesday, October 14, 2009 1:23 AM
  • I wish.  Microsoft has not said a word to me about this bug, and I can't find anywhere to officially report it as a bug.  Table rendering in IE8 in general is just absolutely junk.  I've lost count of the number of rendering glitches I've seen when working with tables in IE8.  

    It does give me hope though that you're getting errors using another Microsoft-supported product.  Maybe try submitting it as a bug for that product and see if we can get someone to take notice? 
    Wednesday, October 14, 2009 1:31 AM
  • Same problem with me also.  Switching IE8 compatibility mode on/off seems to introduce a bug in cellspacing/cellpadding.  Firefox and Safari render correctly, perhaps this is why these products now own 33% of the Browser market share.

    The decision I have to make now is whether or not I attempt to code for the problem -- if i do a bunch of work around coding now, then Microsoft finally fix this bug, I'll have to go back and undo all the work around code.  So, some indication from Microsoft would be appreciated.

    Yes, this is a pretty obvious bug, but I have to admit, that as Microsoft release more software it seems their bugs are becoming more and more obvious affecting A LOT of companies and individuals -- this isn't a good thing.

    Aaah, I just love NOT having any real standards to follow...

    Rob
    Wednesday, October 14, 2009 10:47 PM
  • Same problem here: http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/dc123cbf-0816-42ca-bcd5-765e6c3238c0

    Unfortunately we have upgraded to IE8 in our company :-((
    Daniel Schmitz
    Tuesday, October 20, 2009 12:12 PM
  • And still no response from Microsoft.  Guess I'll just post a warning about Microsoft's bug on all my web sites (I have many public ones not just internal corporate) and let the end user know that Firefox and Safari don't have this problem.  I'm not going to code around the problem this time -- if Microsoft want more people to move away from IE they can continue to keep silent on this VERY obvious bug.

    Rob
    Tuesday, October 20, 2009 4:05 PM
  • Yeah, I'm very frustrated by how Microsoft is handling IE8.  The only official thing I've seen from them regarding the browser is how awesome it is.  They ignore bug posts on the forums, do not provide any means for actually submitting a bug for review, and make no attempt to fix well-known bugs.  At the very least, aren't there MS MVPs would should be monitoring the forums and providing us with some feedback??
    Tuesday, October 20, 2009 5:03 PM
  • And Microsoft wonder why their IE market share went from 92% to 67% and is dropping every quarter.  I suppose the positive side is that when IE market share is so small, I'll no longer need to worry about it nor code work arounds for it.  In the meantime I've added link to downloads/install of Firefox, Safari, Chrome on my sites - help the end user transition away from IE.

    Tuesday, October 20, 2009 6:23 PM
  • I'm planning on integrating something similar into liteGrid.  When an optional module is used, the grid will display a small, dismissible warning about IE8 compatibility problems.  It will suggest that users either install Firefox, Chrome, or the Chrome add-in for IE8. 
    Tuesday, October 20, 2009 7:14 PM
  • Known Issues

     

    Google Chrome Frame is a work in progress. Many features and APIs are still in a state of flux. The following are known issues:

     

    • Printing is not yet implemented.
    • Downloads initiated from Google Chrome Frame are downloaded, but neither the Google Chrome nor the host browser UI is displayed

    Rob^_^
    Tuesday, October 20, 2009 8:38 PM
  • Google Chrome Frame is as much a "work in progress" as IE8 is, the only difference is that Google is actually going to fix things in Google Chrome.  How long will I have to wait before MS fixes table rendering?  IE9, *maybe*?  Between the two, I'd much rather use an unstable technology from Google than one from the IE development team.
    Tuesday, October 20, 2009 11:52 PM
  • Hi Matt,

    How about providing your site address so we can monitor its visitation an uptake of the 50Mb GF uploads. It should be interesting to watch the mean visitation time drop off.

    Who cares what you do with your site. For me suggesting a buggy browser addon for IE is irresponsible. At least now I know another question to ask users when they say "My IE downloads do not work" or "I cannot print from IE". To me these two known issues with Google Frame are show stoppers.


    "Google Chrome Frame is as much a "work in progress" as IE8 is" - google - define SDLC

    Chrome is licensed from Safari.

    Here is the total validator report for a mashup of the code snippet you supplied.



    Page checked: http://localhost/iec/MSMVP/DynamicCellsTest.htm 
    Total errors found: 4 (HTML: 4) 
    DOCTYPE used for this page: -//W3C//DTD HTML 4.0 Transitional//EN 
     
    
     Back to website summary
    
     Go to first problem
    
    Page Layout
    The line numbers refer to lines in the original source.
    Any with a line number of '0' are implicit tags added by Total Validator:
    
       1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
       3 <html>
       4   <head>
       5     <META http-equiv="Content-Style-Type" content="text/css">
       6     <title>
       6       Dynamic Cells test
       6     </title>
       7     <style type="text/css">
      27     </style>
      28     <script type="text/javascript">
      48     </script>
      50   </head>
      51   <body>
      52     <table id="buggedTable">
      53       <colgroup>
      54 E628 Singleton tags are not allowed in HTML:
                 <col style="width: 100px;" />
      55 E628 Singleton tags are not allowed in HTML:
                 <col style="width: 100px;" />
      56 E628 Singleton tags are not allowed in HTML:
                 <col style="width: 100px;" />
      57 E628 Singleton tags are not allowed in HTML:
                 <col style="width: auto;" />
      58       </colgroup>
      59       <thead>
      60         <tr>
      61           <th>
      61             Col1
      61           </th>
      62           <th>
      62             Col2
      62           </th>
      63           <th>
      63             Col3
      63           </th>
      64           <th>
      64             Col4
      64           </th>
      65         </tr>
      66       </thead>
      67       <tbody>
      68         <tr>
      69           <td>
      69             Value 1-1
      69           </td>
      70           <td>
      70             Value 1-2
      70           </td>
      71           <td>
      71             Value 1-3
      71           </td>
      72           <td>
      72             Value 1-4
      72           </td>
      73         </tr>
      74         <tr>
      75           <td>
      75             Value 2-1
      75           </td>
      76           <td>
      76             Value 2-2
      76           </td>
      77           <td>
      77             Value 2-3
      77           </td>
      78           <td>
      78             Value 2-4
      78           </td>
      79         </tr>
      80         <tr>
      81           <td>
      81             Value 3-1
      81           </td>
      82           <td>
      82             Value 3-2
      82           </td>
      83           <td>
      83             Value 3-3
      83           </td>
      84           <td>
      84             Value 3-4
      84           </td>
      85         </tr>
      86         <tr>
      87           <td>
      87             Value 4-1
      87           </td>
      88           <td>
      88             Value 4-2
      88           </td>
      89           <td>
      89             Value 4-3
      89           </td>
      90           <td>
      90             Value 4-4
      90           </td>
      91         </tr>
      92         <tr>
      93           <td>
      93             Value 5-1
      93           </td>
      94           <td>
      94             Value 5-2
      94           </td>
      95           <td>
      95             Value 5-3
      95           </td>
      96           <td>
      96             Value 5-4
      96           </td>
      97         </tr>
      98       </tbody>
      99     </table>
     101   </body>
     102 </html>
     top
    
    More Information
    HTML Errors
    E628 - 4 instance(s): With HTML you are not allowed to end a tag with the '/' character. This is only valid with XHTML documents.
    


    Validator.w3c.org

     Line 55, Column 30: NET-enabling start-tag requires SHORTTAG YES 
    		<col style="width: 100px;" />✉ 
    The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HTML 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HTML 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML. 
     Line 55, Column 31: character data is not allowed here 
    		<col style="width: 100px;" />✉ 
    You have used character data somewhere it is not permitted to appear. Mistakes that can cause this error include: 
    
    •putting text directly in the body of the document without wrapping it in a container element (such as a <p>aragraph</p>), or
    •forgetting to quote an attribute value (where characters such as "%" and "/" are common, but cannot appear without surrounding quotes), or
    •using XHTML-style self-closing tags (such as <meta ... />) in HTML 4.01 or earlier. To fix, remove the extra slash ('/') character. For more information about the reasons for this, see Empty elements in SGML, HTML, XML, and XHTML. 
     Line 56, Column 30: NET-enabling start-tag requires SHORTTAG YES 
    		<col style="width: 100px;" />✉ 
    The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HTML 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HTML 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML. 
     Line 57, Column 30: NET-enabling start-tag requires SHORTTAG YES 
    		<col style="width: 100px;" />✉ 
    The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HTML 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HTML 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML. 
     Line 58, Column 29: NET-enabling start-tag requires SHORTTAG YES 
    		<col style="width: auto;" />✉ 
    The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HTML 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HTML 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML. 
    

    You can view the MS IE Test Center Unit tests at http://samples.msdn.microsoft.com/ietestcenter/

    You can view the W3C test suite (Unit tests) at http://www.w3.org/Style/CSS/Test/CSS2.1/20061011/

    You can post MS's formal issue tracking system at connect.microsoft.com to view the outstanding issues with IE8 RTW/RTM

    THE POINT IS

    if you want to be heard by the IE Developers, submit a formal test case that clearly states and demostates the issue. Redmond is a big place. You will never be heard unless you go through the right channels. No-one at Redmond will act without formalities (they have to accunt for their paid time).

    (Please note: this is a FORMAL issue tracking system. Any submissions you make should follow a documented test plan with (validated) publicly accessible examples.

    Here is a listing of Issues submitted for colgroup

    https://connect.microsoft.com/IE/SearchResults.aspx?SearchQuery=colgroup

    Regards.



    Rob^_^
    Wednesday, October 21, 2009 6:16 AM
  • Hi,

    Here is the computed style from the FX Developer tool.

    #buggedTable td, th (line 16)

    {

    border-top-width: 1px;

    border-right-width-value: 1px;

    border-right-width-ltr-source: physical;

    border-right-width-rtl-source: physical;

    border-bottom-width: 1px;

    border-left-width-value: 1px;

    border-left-width-ltr-source: physical;

    border-left-width-rtl-source: physical;

    border-top-style: solid;

    border-right-style-value: solid;

    border-right-style-ltr-source: physical;

    border-right-style-rtl-source: physical;

    border-bottom-style: solid;

    border-left-style-value: solid;

    border-left-style-ltr-source: physical;

    border-left-style-rtl-source: physical;

    border-top-color: black;

    border-right-color-value: black;

    border-right-color-ltr-source: physical;

    border-right-color-rtl-source: physical;

    border-bottom-color: black;

    border-left-color-value: black;

    border-left-color-ltr-source: physical;

    border-left-color-rtl-source: physical;

    overflow-x: hidden;

    overflow-y: hidden;

    white-space: nowrap;

    }

    Note the inclusion of white-space:nowrap;

    FX, Safari and Opera all use a local stylesheet (User\FX\Style\html.css) to prime the DOM with default rules before the page is rendered.

    Regards.


    Rob^_^
    • Proposed as answer by 13ace13 Saturday, October 24, 2009 3:02 PM
    Wednesday, October 21, 2009 6:59 AM
  • Hello:
    I'm quite the rookie, and found this blog when running into apparently the same issue with tables (which i thought was a png issue);

    I found a solution for my particular issue by specifying image height and width for images inside tables, specifically the png's i used for the header and corners of the box (i know there are prob better ways, please be gentle). 

    Nevertheless, adding the exact dimensions of the images in the html (<img src="botrightcorn.png" alt="vec surfboards" width="100" height="267" />) allowed ie8 to render this page correctly: vecsurfboards.com

    good luck.


    Saturday, October 24, 2009 3:06 PM
  • I actually ran the sample through the W3C validater and received no errors.  I'm not sure why you got different output.  Perhaps something was lost in the copy/paste (either by me posting it here or you copy/pasting it there).  In any case, the bug is in IE, not the markup.  Table cells randomly changing their width by doing nothing more than dragging a selection through the text is not something that markup should be able to cause in the first place.  And the "no-wrap" style was intended.  This table is meant to behave like a spreadsheet, so values that are wider than the column should be hidden. 

    Thanks for the link to Microsoft Connect, but there does not seem to be a way to submit new bugs, and in fact the description says that it's for the IE 8 beta.  It sounds like it's read-only at this point: "The Internet Explorer 8 Feedback website on Microsoft Connect will remain open and we will not delete any of the previously submitted bugs."  There is a link to post new bugs on the beta newgroups, so I'll give that route a try. 

    My frustration isn't just with the bug, it's that it took this long for anyone to say "ok, try submitting a bug report here."  Everything about IE8 seems to be full of fail, including support.
    Saturday, October 24, 2009 5:27 PM
  • I actually ran the sample through the W3C validater and received no errors.  I'm not sure why you got different output.
    Matt: Rob validated against HTML doctype while you're using XHTML. Those errors are not relevant to your issue.
    Monday, October 26, 2009 2:27 AM
  • hi,
    we also ran into this, is there any new info about this?
    thanks.
    Wednesday, February 24, 2010 8:23 PM
  • I'm also very troubled by this problem.

    Eventually, resolved, as shown below.(sorry... I'm korean...using google translate. :)

     

    table.style.display = 'none';
    
    setTimeout(function(){
    
    	table.style.display = '';
    
    }, 10);

    Monday, May 24, 2010 10:06 AM