We often offer a couple of CSS table classes for the editors but the editors find it difficult to use.

When inserting a table the editor must go to the advanced tab and select a class from a list of classes.

The list contains all classes from the common.xml even the ones that is not relevant for tables. This list should only show table designs.

The list shows the class names witch are often generic names. It should show the labels provided in common.xml.

The label _Class_ makes no sense for the editor hoping to find _Design_.

Why is there a distinction between _Class_ and _Id_? The editor will not understand it. For the editor it is not important if the developer created a design using a class or an id.

When changing a table design you can either use right click Manage Table -> Table Properties (and get the problems described above) or use the status bar below the visual editor input field.

To use the status bar you must place the cursor in one of the table cells. Then the status bar displays the elements of the current context in this case table, tbody, tr and td. To enable the styling dropdown in the toolbar (for the table) you must click twice on _table_. No one would naturally click twice. Everywhere else one click is enough. Using the status bar is not intuitive in the first place especially not for editors who do not understand what table, tbody, tr and td means. Sadly this is the only way to activate the styling dropdown in the toolbar (for the table).

This really needs to be improved…

heard !!

In Composite's defense, their Visual Editor is still superior though, compared to so many other CMS's editors, but that of course doesn't mean it can't be better.

> The list contains all classes from the common.xml even the ones that is not relevant for tables. This list should only show table designs.

Could you post a sample common.xml and info and what version you run? I just tried setting up a starter site on 3.2 and I only got the expected table classes "heavy" and "light" and not other classes.

> The list shows the class names witch are often generic names. It should show the labels provided in common.xml.

That is a bug - this is also true for other dialogs like Image Properties - I have logged it here: http://compositec1.codeplex.com/workitem/1238

> The label _Class_ makes no sense for the editor hoping to find _Design_.

I'd rather handle this by ensuring the class selector in the dialogs have the little "palette with colors" icon on it, so the user can easily associate it with the same selector on the main toolbar. With a painters palette, the association should be secured for users looking for design.

> Why is there a distinction between _Class_ and _Id_? The editor will not understand it.
> For the editor it is not important if the developer created a design using a class or an id.

There is a distinction because class and id are two very distinct things, it is fairly important what field is set. Typically an end user should never care about the id field, so it is placed on the "Advanced" tab.

I guess what is needed is to make the two fields even more distinct and move "Class" to the main dialog, since users would like to have easy access to this field.

> When changing a table design you can either use right click Manage Table -> Table Properties (and get the problems described above)
> or use the status bar below the visual editor input field .... Using the status bar is not intuitive in the first place especially not for editors...

The required double click you describe - I tried a 3.2 starter site with Firefox and could not reproduce this need for a double click. Could you describe this in more detail so we may repro this?

But it is true that the need to single out "table" in the element selector at the bottom is a rather tricky maneuver and too hard for users. If you can describe some way we could do this better, so users find this easier, please share. Personally I find it hard to do without making the toolbar weird in some way.

But on the bright side - if we move the class selector for a table to the primary Table Properties tab and put the little palette icon in there, end user life should be vastly improved.

We don't use table designs named "heavy" and "light". Typically the end users want something like “green” and “red”. Because customers often change their colors/minds we use generic class names like “Design01” and give it a suitable label like “Green”. Then we just need to change the label in common.xml and the CSS color codes to replace a table designs on a site (instead of doing risky string replace).

Since there is a “label” on formats in common.xml it should be used in the Table Properties window in the same way as in the "palette with designs/formats". It is a good idea to move the selector to the Basic tab (and to keep ID on the advanced tab).

The problem with common.xml showing classes that is not relevant for tables must have been some kind of caching problem. I can’t reproduce it today.

The problem with singling out "table" in the element selector at the bottom has been like this for years. You need to click twice to highlight the table and activate the "palette with designs/formats ".

If the Table Properties window is improved then there is no need to change the element selector at the bottom (exept for the need for two clicks).

@wysocki was able to repro the double click issue - logged here http://compositec1.codeplex.com/workitem/1239