I really love the work done in the Css Adapter toolkit. What I don't get however, is why the adapters are loaded with class names? Why not make the adapters create clean, WACG compliant output and let the developer worry about the class attributes on the individual elements.

We stripped all class attributes and overloaded the adapters. This way, you have clean WCAG output, and layout is applied afterwards (allowing for seperation of layout and function as well).

Any thoughts on this?

Rinze

I can see where you're coming from. However, as far as .NET is concerned, all of the class names are semantically relevant. It's not like the class names are "blackBorder" or "redBackgroundOfAwesomeness". The class names are things like AspNet-Details-View, which is a completely semantically correct class name.

Now, if, for example, you have your DetailsView render in a dl/dt/dd structure (like we've changed our adapter to do) but have that dl render the same way as every other dl on the site, then yes, the class names become superfluous.

 Also, keep in mind that the adapters are meant to replace rendering for default controls directly with no code changes (other than an external CSS file, perhaps). If classes aren't included by default, that breaks. You have to go to every single one of your controls and add a class. For sites that have a lot of applications, that's a lot of time and a strike against the adapters. (Some things would be impossible without the class hooks. If IE's CSS selectors were up-to-snuff, it wouldn't be as big of a deal and it might be possible to get rid of all but the top-level class names.)

 Are the default classes really not WACG compliant? They should be semantically descriptive; although they do relate more to .NET concepts than web page concepts in general, it's still safe to think of a set of HTML elements as a "FormView" and make class names to match that.
 

I see what you mean. The class names (as far as I've checked) are semantically descriptive and thus indeed WCAG compliant. However, in general I think that there are many cases where styling is already in place and it is either automatically applied to the controls because of the container it is placed in, or the control has to add the specific class to the the control output. Everyone has a different way of applying style.

My menu for example, only needs a class on the <ul> and a class on the "active" <li> item. If I recall correctly, out of the box the adapters add a class to all list items....

I don't see how the rendering replace mechanism breaks when no classes are included by default. In the contrary even, because with the adapter in place, you know exactly the form the output will take, and thus how to apply styling. If an extra indentifier is needed, you can overload the control adapter and add it. I am still in doubt whether or not to allow the developer to use the control class attributes or to discard all of it using the adapter and enforce styling myself.  

I still vote for keeping it clean(er) :-)

Kind regards,

Rinze

Well, my uni throws away all styling information on controls except for CssClass and we do everything in .css files, like you do. You're right about ul li, and I'm sure there are more things like that that could be cleaned up, but at this point I doubt that will happen for backward compatibility reasons (since some people have probably already used those hooks in their stylesheets). You might talk to the guys over on CodePlex and see what they have to say. It would be nice to have the bare minimum markup and class hooks needed, but at least we all have the option of modifying the code if we need to do so. =)

Honestly, if it wasn't for IE we could just put one class on every top-level item for each control, and that would be so much nicer. IE7 does better, but the uptake hasn't been enough to start using the selectors that IE6 doesn't support. *frustrated sigh* And I'm not holding my breath on improved CSS (or anything else) support until Microsoft is showing us how wonderful Silverlight is while their browser keeps falling behind, when we could do similar things if they would just support all of the standards that are already there.

Some days I hate web development. =P

I only just discovered that the ongoing development of the css adapters was handed over to the codeplex project. I will certainly check the project site for the news and releases and maybe find out what there 'ruling' on this is.

Full css website development will always be an issue in IE, cause for years to come we'll have to add support for IE6. The damage has already been done. The only trick I know is to do the work once, and sell all your customers a variation of your flawless, ready to ship, 3 column layout .

Silverlight looks promising enough. You gotta love the fact that you can do client side c#. However, for corporate websites, I will probably apply it as much as I do flash (which, as you may have guessed, is never).

greets,

Rinze

 I totally agree!

I want a TreeView wich is clean!

I hate the way MS have forced their javascript and styles into the TreeView. I want to be able to use my own stuff.

Please, make it right, with the option to choose your own styles for  "selected, opened, closed" etc, and the option to display a totally clean, nested ul.

Does anyone know if this is done somewhere?? If so, please give me a holler!

Cheers!

 - jonah 

I just wrote my own treeview and menuadapter, based on cssfriendly. Just strip everything you don't like ;-)