I think that we need an identification of the module including their container. At the moment there is not way to identify the container of a module, hindering certain operations of design of the module layout. For example: it is not possible to add in a page two instances of the same container with different colors.  
 
This identification lack produces an exponential proliferation of containers: the same box multiplied by each color header+background+borders+footer,  images for borders and squares, etc.  
 
I think that it would be more appropriate if a property could be added in "module settings" to assign a class or css that identify the whole module and allows to modify the appearance of the container from portal.css go.

Thanks for read it and for your comments,

Luis

Hello Nina, is my pleasure to converse with you. 
 
I will try to explain better, using my poor English:  may be the title should be Container Classes.
 
Let us suppose that in the Homepage we need two simple boxes with borders in the same panel for the modules moduleY and moduleB: one yellow and the other blue. At the moment we need to create and to name two containers: CYellow and CBlue. Both containers has the same structure, the only difference is the color of the border. I understand that we should make it today, but this means multiples container files and little flexibility.

My proposal to make the same work:

1. To create a neutral container CBox (CBox.html/CBox.ascx and CBox.css)
 
2. Add moduleY module to the page. In moduleSettings to assign the container CBox, and set a value cssYellow in a proposal field CSSStyle. 
 
3. Add moduleB to the page and set container to CBox too, but this time assigning to CSSstyle field a cssBlue value. 
 
4. Go to portalSettings cssEditor and add something as this: 

/* for containers CBox-Yellow */
.cssYellow TABLE {border-color:Yellow; background-image:...; padding-top:,..., etc}
.cssYellow .NormalTextBox { font-size: 15px,... }

/*for containers CBox-Blue */
.cssBlue TABLE {border-color:Blue; background-image:...; padding-top:,..., etc}
...

a brief comparison of the html generated looks like:

 
I believe that this approach is very simple and flexible to customize containers and I think that it represents minimum changes in code source.
 
This suggestion will also allow that the clientAPI knows who is the module-container and it will allow many other features.

I hope that you have understood my clumsy explanation and that the core team considers its benefits.

Best Regards,

Luis