When/Should we use CssClass property or Style property?

[Sky]

Hello:
Been doing ASP.NET steadily for a couple of months now, building server
controls -- but I am still looking at a couple of design philosophies of the
framework with...concerns....
The main one being the way controls are styled up -- and I would really
appreciate feedback from any and all, as to what makes sense to do.

Before ASP.NET we were just getting the gist that totally separating
structure from styling, via external CSS sheets, was the way to go. No -- or
as little as possible -- inline styling.

Designed for the IDE, not the Output?
Now -- we are back to controls that -- trying to emulate VB6 control
philosophy in the IDE, via Font.Color, Background, Height, Width, etc. --
and are outputing these values inline...

CssClass versus CssText
From what it appears Microsoft recommends to abstain from using the
Style[''] dictionary... (or create controls with a CssText public string to
offer direct Styling). If I think I understand their policy, they would
prefer that we create a Style class derived from their basic one, and add
all the public properties etc. Now, I know that I am thick as mud -- but
there is a BIG difference in time for programming up one lilttle public
string property, or dictionary ----- and progamming a subclass of a default
Style class that goes on and on and on, takes viewstate handling
implementation, a TypeConverter from hell, etc.....
I've wilted in front of the task, and not pulled one off (there are
literally hundreds of values possible in the style tree -- even microsoft
seems to have given up after the first 10 values or so for their basic
StyleConverter...)
Has anybody written a full implementation of a Style Typeconverter? If so
where?

AttributeMerge?
I assume their huge workaround was so that they could AttributeMerge -- but
then why not stayed with a case insensitive dictionary or something simple?
Not that I am really sure when and where to use this function -- as it seems
like it could be really a nightmare: For example -- You make a Control that
has a Panel, with another Panel in it -- you apply a border color of red and
a font-family of Verdana to the outerPanel, then the control merges the
attributes -- now the inner Panel would have a border of Red! Plus it now
has an inline style='font-family:Verdana' -- which is totally redundant as
it is on the outer panel. ... Any body have insights as to when to use
AttributeMerge? When is it useful? Can you AttributeMerge only specific
fields and not take border for example?

CssClass, Style dictionary -- and Styling.
One thing that I am not really getting here is that with Css you could
create a Skin quite easily -- and if you wanted to make body color blue --
change the css, voila!. But now we have controls that have inline code --
and it no longer is going to work...the CssClass will be applied first -
then overriden by the Inline Font.Color property.

Tentative Conclusion
From what I am seeing, the LAST thing one wants to offer on a custom control
is Font.Color, etc.... -- only offer a CssClass value. But this is totally
the reverse of what MS is preaching, and that makes me worry like hell.
As you can see - I'm pretty confused as to the intents/methodology of MS,
and I would really like as many opinions from others as possible on this
subject to sort me out.
It's highly probable that the way to do it is right in front of my nose, but
that I havn't seen it -- hence this shout out for help...

Thanks!

 

[Rick]

We have always considered inline styles to be bad. Not only does it
remove the ability to restyle a site quickly and from a central resource
but it also raises issues associated with accessibilty, cross-platform
support and a whole load of bugbears that you don't even think of.
Inline styles are ideal for WYSIWYG editors which are great for your
designers when they are dragging and dropping stuff all over the place
and making it look great on the design surface but as soon as your
client changes their corporate font six months down the line it suddenly
equates to a lot of work.

CSS is by far the better option, seperating the markup from styling in a
similar fashion to seperating the presentation layer from your business
logic and data access layer in the .NET architecture.

I'd be interested to hear of a web application where inline styling has
any real benefits over CSS, we can't think of one.

Dr Richard Edwards, .NET Developer
http://www.sift.co.uk

 

[Robert Koritnik]

When? Exceptions to the CSS. Seems to be the only reasonable way and even
that with limited use. I/we normally use defined CSS styles for input
controls (like textboxes, dropdowns etc.) and if we REALY need to change
that we do it inline if the exception is the ONLY ONE in the whole project.
Otherwise we define a new CSS class.