Joe Brinkman wrote
One of the big challenges in an environment like DotNetNuke is that a page is comprised of many different pieces, all written by different developers, designers and admins. The DNN core obviously cannot write a single stylesheet that serves every module and skin, and skinners have no way to know the requirements of the individual modules.
While there is a lot of truth in that statement, there is also a problem with consistency in using certain styles even just within the core modules, not to mention 3rd party developers.
One thing that clients often tell me is that they want every submit button in every module to be styled the same. And to be honest, any designer who didn't think so as well shouldn't be designing. The frustration is that the class "standardbutton" has existed for years and everyone just ignores it. Clients want consistency from the login module to the blog module to the search input module, etc. They want an overall theme and style and the really frustrating thing is that the basis for doing so is already partly in place if the developers (core team and third party alike) would just take a moment to review all the standard default classes that would help make that happen.
I don't expect developers to do my work for me, but I certainly don't enjoy having to constantly find new and improved ways to override the hodge-podge of misplaced, misused, or lack of use to apply common classes where they should obviously be applied. As it stands, DNN in any version has one style for the login button, another style for the blog's search module button, text links for the blog module's post comment area, and yet another set of options for the general search input module buttons, then this whole set of foreign icons in the forums modules. And that is truly frustrating when developing a skin for a site that only uses core modules that you would think would have a set of standard styles applied consistently throughout but doesn't. It seems like there aren't many developers around who use this standard set of style classes to any real degree at all, and they are right there easy to find. I do agree that third party modules are going to need their own set of classes in certain instances, but completely ignoring the standard classes altogether is downright unforgivable!
But, it's also true that third party modules using default classes inappropriately or illogically is also a problem, and a much more serious problem. One client had a problem with a third party module that wanted to use the "body" tag style as the background for a module and then apply their own text color completely ignoring the "NormalText" class and the client ended up with black text on dark brown background and couldn't read anything in the module. I tried nested clases, etc. and never did find a good solution because of the develper's own personal styling choices that were hard coded.
It would probably be helpful for developers to have a cheat sheet that lists default styles and appropriate uses for them, including DNN's core team. It would make the end users much happier and the skin designers ecstatic to have even just a little more consistency from one module to the next, especially in the core modules! I refuse to modify the core code for a client due to the problems it creates in upgrading later, so I, like a million other designers, spend hours trying to find the right hack and nested css class combinations to bring about a more uniform and consistent style and design for the client's website.
That's my 50 cents worth, and my vote for stronger consistency and easier ways to override css classes that don't make sense for every situation. And therein lies the problem, I suppose, that not every solution makes sense for every situation. But still, simple things like a submit button or submit link style should be consistent and should apply in every situation as that is what almost every client wants at the most basic level of their website design...
And for those developers who beg to differ, I have done some major custom programming for several clients and keeping in mind the standard css classes when coding things was not that difficult and in the end made it easier to make changes to the look of design elements while keeping those changes consistently applied to the core modules as well as the custom modules. It can be done, and it's not that difficult for anyone who is experienced with DNN to do so.