[eluser]paulopmx[/eluser]
[quote author="wardenik" date="1207801852"][quote author="paulopmx" date="1207801531"][quote author="wardenik" date="1207801197"][quote author="paulopmx" date="1207801008"][quote author="wardenik" date="1207800395"]Ok then, if it is not for styling, then where is the problem of dropping the declaration and using the header model derived from the table <thead> itself? [/quote]
As I explained in my previous post, I encountered differences among browsers on how they handle cells without width but with content. Allowing the user to set the width in the cell gives me an idea, on what he/she expects .[/quote]
But you know that you deny yourself this way.
This is *exactly* styling the output (i.e. hinting the style/layout) [/quote]
Styling the output yes, but not *exactly* of the td tag itself (i.e. styling is transfered on a div inside the td), which was the basis of your concern in the first place [/quote]
Erm, not at all.
I am not at all afraid about styling problems.
I just do not want ANY styling in the table model because it is simply not needed
What is done afterwards (i mean after () is run, and table is changed to divs) i don't care [/quote]
Ehem, then you don't have to, use a colModel.
Using a colModel, only requires you to put a table with either a class or an id. The thead, tbody, tr, or td with any styling is simply won't be needed .
What approach you take in using the plugin is really up to you. An approach is optional not required, but taking one approach does have a requirement. You want less html, then you are required to put in a little more settings through javascript, or if you want less javascript, then you are required to put in a little more attributes in your html.
Either way people care about the outcome, and in order for the plugin to know what they want, they have to tell the plugin what they want.