I'm pleased to announce that we have upgraded the CSS Friendly ASP.NET 2.0 Control Adapter kit.  The new release is Beta 3. 

All forms rendered by the adapters (think: membership controls) now implement a solution for the accesskey issue. It’s simple but incredibly effective… and totally addictive.

There are other things in beta 3 besides accessibility improvements. The TreeView adapter now restores the tree’s expansion state. That’s a huge usability improvement but more importantly it’s our first demonstration of an adapter that leverages the ASP.NET view state framework.

To get familiar with all the new features, please read the "what's new" section of the kit's home page at http://www.asp.net/cssadapters.  Also, try out the "quick cool demos" listed in that section.  They are:

Hi Russ!

 Thanks for all of the time and hard work you've put in to these adapters. I was pretty amazed with how fast version Beta 3 of the kit came out after Beta 2.

 I'm not sure if you're still considering it, but I would highly recommend rendering controls like DetailsView as a definition list. It makes a lot more sense than two spans semantically, and it's easier to get to each part with CSS. We're currently using it that way on my university's projects, and I'd be more than happy to give you the CSS we use to display the dt and dd on the same line (basically, floating with the dt clearing).

Another thing to consider is automatically generating labels in DetailsView (especially for DataBound controls). The solution we used is when there's exactly one non-text/non-literal control, output a label for that control using the HeaderText (in the dt in our case). Otherwise, display HeaderText normally without using a label. This is a relatively easy improvement that makes DetailsView form elements accessible. In my opinion, this should be the way it works by default on BoundFields. A case could probably be made both ways once you start using TemplateFields, since at that point you can input the labels yourself. Before modification, we had to use TemplateFields to input labels for every single DetailsView just to meet our accessibility requirements. It's much more efficient and less error-prone to handle all of that in the adapter.

 Anyway, thanks again! Looking forward to the final revision, and I'm sure you are too!
 

(Gah, I wish these forums had an edit button! =P)

 Just as a clarification, the main problem was that DetailsView doesn't output labels for BoundFields, meaning that we had to switch to TemplateFields for everything even though we didn't want any other changes to the look or functionality other than labels for form elements. The label change allows those of us who have to conform to things like section 508 the ability to use DataBound controls without modification.
 

Hi Falcon,

I'd like to take you up on your offer of sharing your markup and CSS.  Can you please post both here or send them directly to me (rhelfand@groovybits.com).  I'm trying to avoid major shake-ups in the next rev but if I can find a safe/stable way to integrate your ideas into the next rev I'll try mightily to do so.  Fair enough?

Hey Russ!

I tried e-mailing you the examples but your e-mail didn't like whatever character set Gmail tried to use to send it and it bounced back. (Not sure if that had to do with the attachments or what)

Anyway:

http://www.lemonrage.com/nate/css/cssadapterexample/index.html is an example of a dl dt dd adapted DetailsView. Forgive the incorrect IDs on some of the labels. I need to fix my automatic label generation in our adapter a bit.

Unfortunately, IE has major trouble dealing with floats correctly, even in version 7. A couple of the widths in the CSS are just so IE will display everything properly. Firefox, Safari, and Opera all behave correctly and deal with the floats correctly without the widths. I'm not sure of the best way to handle that, since the widths will probably need to change for different layouts for IE. The other 3 major browsers will be able to adapt to virtually any layout without any width changes.

Any ideas you have on that matter would be appreciated! =)

Hey, Falcon, thanks for posting this.  Indeed, I had thought you'd gone "dark" on me since I didn't hear from you recently.  Good to see you are still there!

My rule of thumb with floats is that I always assign them a width. Is that what you are finding that you need to do, too? If so, I guess I don't really consider it a bug in one or another browsers. It would be nice if you could somehow reliably say (in CSS) the width of this (block) floated element should be as wide as it needs to be and no wider... but I don't think it works that way. Ha ha.

Can you share your perspective and experience on this?  If you post some of your CSS and point out where you had to add explicit widths, we can talk about those cases specifically.

Haha! I apologize for taking so long to get these examples to you. I've been in the rush leading up to finals at uni for the past month or so. (And thanks again for the work you've done on the adapters! My fellow student workers and I were having to write a lot of code by hand since the controls output HTML we couldn't use. I asked my boss "What's the point of using .NET then?" one day...  and guess who got the project to adapt all of the controls? =P  Anyway, since then it's been a huge time saver to be able to use the built-in ASP.NET controls.)

Alright, here's the relevant part of the sample.css file:

/* This is the main "same line CSS" */

form dl, form fieldset dl, form div dl {
	float: left; 
	width: 100%;  /* Only necessary for IE */
	padding: 0;
	padding-bottom: 1px;
	}

form dt, form div dt {
	margin: 0 5px 5px 0;
	clear: both;
	float: left; 
	text-align: right;
	width: 150px;	/* To avoid IE bug, the width of dt is set below width of any column */
	}

form dd, form div dd {
	margin: 0 0 10px 0;
	float: left;
	width: 80%; /* Sigh. IE needs this width or it blows up. Firefox, Opera and Safari all behave correctly. */
	}

/* The same line CSS ends here */

 
The width: 100% on the dl and the width: 80% in the dd section are not needed for any other browser but IE. Without a specific width set, IE will not clear the floats even with clear: both set, which is incorrect behavior according to http://www.w3.org/TR/CSS21/visuren.html#flow-control:

 "When the [clear] property is set on floating elements, it results in a modification of the rules for positioning the float. An extra constraint (#10) is added:

• The top outer edge of the float must be below the bottom outer edge of all earlier left-floating boxes (in the case of 'clear: left'), or all earlier right-floating boxes (in the case of 'clear: right'), or both ('clear: both')."

The W3C spec says that floats with clears should be pushed downward. IE, without a specific width set, is putting some floats adjacent to other floats, which is clearly against the spec. By setting clear: both on the dt, which is the first element in every row, the dt and dd should be getting pushed to the next line by default, creating one dt/dd pair per row. This rule of CSS would make the problem of putting the dts and dds on the same line painfully simple, but IE needing the width means that the proper width would either have to be calculated or input by the user.

A bit old, but still relevant: http://agachi.name/weblog/archives/2005/06/09/clearing-floats-into-rows.htm and http://agachi.name/tests/clearing-floats-into-rows.htm

I've added http://www.lemonrage.com/nate/css/cssadapterexample/iefloatsample.html which when viewed in IE6 or IE7 shows what happens without a width set, but when viewed in any recent version of Firefox and Opera shows what should happen according to the W3C spec. =) It just has the width rules in the dl and dd sections removed.