Clean up default form CSS

Please re-roll against the latest dev version.

bdragon, maybe this can be applied to the dev version without the opera fix?

In my opinion, this module's form CSS rules are much too intrusive, and don't need to exist at all. Let's leave it up to themes to control the layout of forms.

I'm not to up on themeing, but the once provided by the module can be overridden, yes?

Or are you saying location IS overriding what the theme is trying to use, and so taking these out will help?

Can you provide a couple screen shot examples of before and after your patch in a couple different themes?

Thanks for helping us understand.

Also, can you make the patch against the 3.x-dev version? That is where the action is at to fix stuff.

Yes, I can override the CSS in my theme, but it's a hassle having to do so every single time that I install this module.

Sure, it might look fine in Garland, but the module should accomodate those of us who never use that theme. Check out the attached screen shot to see what it looks like with my particular custom theme, it's a mess.

I know not everyone will share my opinion, but I think that the module should mind its own business—If I want to display inline field labels in my node form, then I'll put that in my theme.

what does it look like in garland, or slate, or zen?

Hmmm What is The Right Way? What do other modules do? Do they ship with css that works for Garland, and expect people to change it for other custom modules? Or do they ship with non, and expect people who use Garland to add it in?

(not trying to be difficult, just figure out what The Right Way is)

Ultimately, the decision lies with the project maintainer, but I'll give my take on the issue here.

To me, The Right Way is to leave out any CSS that is tailored to any specific theme. Most serious developers will NEVER use Garland, and might not use Slate or Zen either. Either way, compatibility with these themes is irrelevant: modules need to be flexible enough to accommodate ANY theme. In my experience, this is the way that most modules work.

If a module provides its own css, any classes and ids should have their names prepended with the name of the module, then it is clear where the css comes from and it only applies to elements in that module.

Any css that the module has embedded in it should be defined in the css so that it is clear to themers what classes/ids the module uses.

What a module should *not* do is redefine existing classes or ids.

My 2 bits worth.

good discussion. Can someone ping another themer or two to comment, and then we can combine and make a new patch.

Closing old D6 issues as D6 is end of life