I'd imagine that the table/img element in a skin gets some styling, so when modules display tables or images, the view is consistent throughout the site.

Is this assumption true? and if so, do I style the table/img element itself, or are there specific classes I should style?
I've noticed that for a button, I should not style the html buttons themselves, but instead style a class called 'CommandButton' and assign that class to all buttons.

Also, sometimes you'll want to display tabular data, without showing the table itself. The CSS-purist will say I shouldn't use tables for that, but tell that to the content-manager who uses the wysiwyg editor. Is there a class that is used for that within dnn?
The same is true for images: in general you'll want to style your images in a consistent way (with padding and some nice border), but sometimes you might not want to style an image, e.g. when inserting a smiley.

Ideally different levels of table classes (major table, minor table and invisible tabel?) and image classes would exist, just like the 6 different header classes, but I think that's asking too much.

So: Should I style the html tables and images in general, or use some specific classes? (which ones?) And are there other table/image classes to style, for example for an invisible table?

That's a nice way of working, I'm trying to avoid having to style everything, containers indeed take care of that. Although a container feels a bit like sneeking style back into the content.

However, in my specificsituation this approach would not even work. I've made a module which displayed a list of properties and their values, followed by a table with dates.
For the first part I use a table without borders, padding, colors, etc. to align the data properly, for the second part I use a table, because it's a table.

My original question was wether DNN already defines those hiddentable and fancytable class names and what a default table looks like.

I've now found a styleguid as part of the DNN7 awesome cycles site. There is styling for tables included: A table without any styling is styled as a hidden table, while the visible table in the styleguide gets the 'tableDefault' class. Who thought that not showing the table by default and calling an alternate table style (= not the default) 'tableDefault' was a good idea? Now when inserting a table, the content editor needs to change the class to actually display the table as a table. It's easier to misuse a table than to use it the proper way. And the class name... This is such a horrible approach that I'm very unlikely going to do the same.

In the skin I'm going to style the html table element in some basic way, style the tableDefault class exactly the same, make a class 'hiddentable' which defines a table without any visual formatting and optionally create some containers to define fancier tables.
And I'll probably also define a container where tables are hidden for modules that use both default tables and 'TableDefault' tables and expect the firs kind not to show.