Created attachment 167528 [details]
Writer file showing problem with Table Styles
Version: 188.8.131.52 (x64)
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Open the attached writer file.
1. Put the cursor in the table, then set the Table Style to "Default", say (from the sidebar Table Styles or the Table Toolbar).
2. Now try to turn off the Table style.
RESULT: You can't. One essential item is missing in the "Table Styles" list—an OFF button.
WORKAROUND: Convert the table to text, remove the direct formatting, then recreate the table.
So, OP is correct. There is no Autoformat style that has no formatting. However, an UNDO takes care of the problem of a regret-having-appled-autostyle situation, so I doubt if there really is any value in adding such a style, especially since it would still wipe out any original formatting you may have had.
It is also easy enough to use table properties to remove borders from something simple like the default style.
So in my opinion, three work-arounds is enough to solve a user-generated problem, but I'll notify UX about this.
(I think OP probably understands this, but table styles are not like paragraph styles. You can't just attach and de-attach a style. Instead, they just copy their settings to your table, and that is the end of the style action. Making changes to the style won't affect your table in the least.)
The font-size, for example, of the table text may change when you apply a table style, but the INDICATED paragraph style still remains "Table Contents/Heading". This is unexpected.
If the Table Style changes the text properties, I would expect this to be related to the application of a new paragraph or character style—which the user should be able to verify by placing the cursor in the relevant cell and viewing in the sidebar.
IMV, making these text properties hidden is a potential source of confusion for the user.
One other thing. A table style is not a style in the sense that a paragraph style is. IMV. So, should they share the same sidebar? And would it be better to use another term like "Table format" to indicate the difference?
Is this a duplicate of Bug 133198 - Unchecking the formatting checkboxes in Autoformat dialog has no effect for the current table ?
It should be handled in the same way as the also missing 'no list' item in the list styles of the Styles sidebar and menu.
Insert > Table allows to use "None", while Table > Autoformat doesn't have this option. Neither the Stylist at the sidebar. The "None" table style would be similar to Default Character Style, meaning no style is applied, with a very special handling.
> "However, an UNDO takes care of the problem of a regret-having-appled-autostyle situation"
It is worse than that. Just an "undo" is not a "workaround". If you want to revert later on, you can't "undo" anymore. There should be way to remove any automatic Table autoformatting anytime. You can't leave the user stuck with irreversible autoformatting.
> "It is also easy enough to use table properties to remove borders from something simple like the default style."
It is indeed easy enough to remove borders, but the issue is that these are *automatically reapplied* as soon as the table is changed (row added or deleted)!
This is *not* a duplicate of Bug 133198. The matter here is that, once an autoformat has been applied, it is impossible to remove that again later. The issue there relates to eliminating specific aspects from an active Table "Autoformat Style"
There really should be a possibility to remove table autoformatting. Currently, once applied, the user is locked in.
Prototype for implementation of a "No Table Style" is in bug 101965 regarding "No List Style". Interesting easyhack.
Actually, I would argue against this approach to addressing the issue. Instead of having a "turn off style", we should have _all_ tables _always_ have a style, and make table styles into proper styles like Paragraph, Character and Page styles. Then there would be no inconsistency between creating the table and what you can set the style too.
Elaboration in bug 152711.