Note that I'm not talking about direct formatting here, but about character styles.
For new users, it's quite difficult to find that the only way you have to remove an applied character style is to apply the special character style called "default style" on top of it.
The "styles toolbar" have a button to apply this special character style and thus remove any applied character style, but its function is not evident at first glance and anyway that toolbar is not enabled by default.
I think a possible alternative is to add in the character style panel of the style editor a button called "remove character styles from selection" or something like that, being that button a shortcut to apply the default character style.
+1, but maybe more than just for Character styles?
It seems like there should be menu entry (either Style menu or a Format menu) for the existing UNO controls--".uno:DefaultCharStyle" and ".uno:DefaultParaStyle" used on the Formatting (Style) toolbar.
The menu entry(s) would provide reset to default Character style and/or default Paragraph style--i.e. a "Style" corollary to the 'Clear Direct Formatting' control.
And I would suggest this pair of actions also appear on the Sidebar Properties Deck, inside the 'Style' Content Panel or better in its Title bar, as a button action to "Clear (or Reset?) to Default". Likewise the same button actions should be added to the Title bar of the 'Style' deck.
Intent of reusing controls--menus, Properties deck, and Style deck--being to provide a consistent and obvious way to remove any assigned styles. It would provide a means to get a text selection or a full paragraph back to known state--i.e. no Direct Formatting, no Style other than document default.
(In reply to V Stuart Foote from comment #1)
> It seems like there should be menu entry (either Style menu or a Format
> menu) for the existing UNO controls--".uno:DefaultCharStyle" and
> ".uno:DefaultParaStyle" used on the Formatting (Style) toolbar.
So, the .uno:DefaultCharStyle is already on the 'Styles' menu--labeled 'Default Character' but uno:DefaultParaStyle is not; regardless addition to Sidebar decks is needed.
Please don't extend this to paragraph styles. Doing that would emphasize usage of Default paragraph style - which is bad.
(In reply to Mike Kaganski from comment #3)
> Please don't extend this to paragraph styles. Doing that would emphasize
> usage of Default paragraph style - which is bad.
Would it? Not so sure...
For most users now--majority of their documents are already going to be in default style(s) as that is what the document type templates open with.
While here, goal of having the controls prominent is to get the document content back to a known state--either selecting a word, a text run, a full paragraph, or the full document and resetting its style.
Seems the efficient work flow is to first set the selection back to the template defaults for paragraph and character styles (or to the default style(s) as modified in current document).
Making it ready to apply new style(s), in a second step if other than defaults is desired.
At risk of being off-topic here (since the request was about character styles(!)), I have to describe my PoV.
While the imaginary "Default character style" (internally = don't use any character style, and use what is defined in paragraph style) is perfectly reasonable in any sense (and would be most used in ~any stylistically consistent document), Default paragraph style (an actual style, which might - and often should - be modified - consciously) is a *root* of most pre-defined styles, and thus its direct use is wrong from the proper styles use PoV. Of course, using it is not wrong from the programmatic PoV, but its default use in templates is just an unfortunate implementation detail that needs fixing. So making means to directly use it even more prominent than now is a bad thing.
Specifically, using "Default paragraph style" in documents, and then starting use styles, would mean that a novice user has main text in that "Default style", and also applies, say, Heading N; also using headers/footers and tables automatically uses relevant styles in those elements. And when user then wants to edit the main style (Default!), this will propagate inherited settings to all the styles right and left - which might be (and often is) not what user needs. The inheritance levels are there for a reason: e.g., if user wants font face to be consistent across all used styles, user sets that in the lowest possible inheritance level; if user needs some paragraphs have indents or spacings, that wouldn't make sense to do at lowest level. Forcing users to start with base-of-everything Default style provokes each style edit to have too widescale (potentially destructive) consequences.
We have too much of that Default paragraph style usage in our controls/templates: being the default in the templates; being set when e.g. Alt+Enter'ing out of a table; resetting to it when using the "Clear formatting" item in style list in toolbar... please don't create another prominent way to promote logically inconsistent workflow! It goes against the overall architecture of LibreOffice being built around using styles; and it makes learning using styles much more difficult for beginners (who try simple things like editing the used styles, and suddenly see unwanted results all over the document, which would cause distrust in the tool).
Even without the "difficulty" and "distrust" feelings caused by unwanted large-scale changes editing the Default style, the obvious consequence of this in user learning is "understanding" that all styles should be "disconnected" from the Default style (user would need to re-define all the properties in inheritance tree leafs), thus making the inheritance concept less useful and more of a hassle ("Why is everything inherited from Default? It makes things so much harder!"). The very first encounter with the style inheritance concept, instead of giving a useful and handy tool to user, becomes "meet this useless and awkward thing that stays on your way" moment.
(In reply to RGB from comment #0)
> For new users, it's quite difficult to find that the only way you have to
> remove an applied character style is to apply the special character style
> called "default style" on top of it.
> The "styles toolbar" have a button to apply this special character style and
> thus remove any applied character style,but its function is not evident at
> first glance and anyway that toolbar is not enabled by default.
I can't find a "styles toolbar". Styles menu doesn't have that option
> I think a possible alternative is to add in the character style panel of the
> style editor a button called "remove character styles from selection" or
> something like that, being that button a shortcut to apply the default
> character style.
(In reply to Dieter Praas from comment #7)
> I can't find a "styles toolbar". Styles menu doesn't have that option
View -> Toolbars -> 'Formatting (Styles)'
At the first glance I agreed with the "clean CS" button idea. But this would lead the list in a nimbus state (no item selected), which is not achievable except this button. Feels wrong, is bad usability. Plus, it's a new UI control without some kind of whole concept behind that bothers me.
OTOH, thinking about multi-selection to make nested CS possible, it's not far-fetched to ctrl-click a selected entry and to toggle it off by that. And last but not least, if the selection goes over some part of the paragraph including Default and <Foo> CS, the Default entry is selected in the Styles menu and the styles sidebar list. In this situation it's absolutely not clear that clicking Default works similar to Clean Direct Formatting.
Hm, if something existing isn't good to use or will not be used regardless of whether it would be useful, then this is an indicator of bad usability of existing tools.
Instead of bringing more complexity to an already complex field of possibilities (here: the styles concept) with a new feature, we should allow users to better use existing features. The question is how to make this possible. More help texts? Tool tips? Another arrangement or naming of commands?
I'm talking about character styles only and I'm with Heiko in comment 9.
(In reply to Thomas Lendo from comment #10)
> More help texts?
Help is not very helpful:
and documentation is not very clear:
"Removing or replacing character styles
Sometimes, you will want to remove the character style formatting from some text, or change the character style to a different style. To do this:
3) Double-click the required character style, or double-click Default Style to remove the character style." (Writer 6.0 Guide Chaper 8, page 9)
Either Default style is a character style (in this case documentation should be changed) or "Default style" removes character style and therefor it is not a character syle itself (in this case name "Default Style" should be changed)
(In reply to Dieter Praas from comment #11)
> Either Default style is a character style (in this case documentation should
> be changed) or "Default style" removes character style and therefor it is
> not a character syle itself (in this case name "Default Style" should be
Default *character* style is actually a pseudo-style; a name for "no character style applied". While it might be good to document something about that, I don't think that renaming it is a good idea, because its current name creates some consistency with e.g. paragraph styles, where "default style" exists (and is actual configurable style). For user, it means something basic and simple. Or - if a rename is wanted - it could be something like "Character settings defined at paragraph level" - too long, although correct. You cannot even name it "Paragraph style settings", because "no character style" aka "Default character style" means both paragraph style setting, and *direct paragraph-level formatting* are used for character properties.
(In reply to Mike Kaganski from comment #12)
> Default *character* style is actually a pseudo-style; a name for "no
> character style applied".
After years of using LO and styles, I begin to understand the concept :-(
I've spent a lot of time while writing my PhD and defining a character style for each paragraph style. I would like to spare others this.
> While it might be good to document something about
> that, I don't think that renaming it is a good idea, because its current
> name creates some consistency with e.g. paragraph styles, where "default
> style" exists (and is actual configurable style).
Same name but different meaning? => Doesn't create consistency for me.
> Or - if a rename is wanted - it could be
> something like "Character settings defined at paragraph level" - too long,
> although correct.
What about "From paragraph level"?
(In reply to Dieter Praas from comment #13)
> What about "From paragraph level"?
or "From paragraph settings".
Makes sense to me.
(In reply to Mike Kaganski from comment #14)
> or "From paragraph settings".
+ pro: convenient, self-explanatory (Stuart, Dieter)
+ con: misleading, adding complexity (Thomas, Heiko)
+ (multiple) CS could be assigned per toggle on/off at the list item,
and we remove the dummy "Default" CS
=> suggest to resolve as WF
Just to add another perspective from a new user point of view:
A while ago I wasn't even aware of the concept of character styles, and so after I pasted in some text that happened to have a "Code" character style, I was confused about why Ctrl + M (Clear Direct Formatting) was changing the font to Liberation Mono instead of Liberation Serif: https://ask.libreoffice.org/en/question/186336/clear-formatting-keeps-reverting-font-to-liberation-mono-instead-default-style-liberation-serif/
Also somewhat relevant: https://ask.libreoffice.org/en/question/135708/clear-direct-formatting-ignores-character-styles/
(In reply to Ahiijny from comment #17)
> Just to add another perspective from a new user point of view:
The issue is clear. But the requested button to remove a CS is not the solution to a missing understanding (not blaming the user by this but design and workflow) or the awkward way to revert CS by setting Default. Rather feedback is key here- and the proposal is under https://design.blog.documentfoundation.org/2019/11/05/proposal-to-conveniently-highlight-and-inspect-styles-in-libreoffice-writer/
(In reply to Heiko Tietze from comment #18)
> (In reply to Ahiijny from comment #17)
> > Just to add another perspective from a new user point of view:
> The issue is clear. But the requested button to remove a CS is not the
> solution to a missing understanding (not blaming the user by this but design
> and workflow) or the awkward way to revert CS by setting Default.
By the same token, a single "well placed/named/tool-tipped" button action is self documenting and would itself provide some insight for users.
> feedback is key here- and the proposal is under
Well, this should still probably happen, but inspection and highlighting is a much more complex/ambitious "solution" for Style visualizations, while this otherwise a simple requirement for a single .uno action to remove applied Character Style(s) from selection and _simply_ to restore the attributes provided by the applied Paragraph Style.
Simplicity for a UX solution now, and pursue more dev interest/effort to fully implement proposed visual manipulation of styles going forward.
How about the toggle idea? I mean you click on _any_ entry in the list to enable or disable this CS. We remove the Default CS and allow at the same time to have multiple CS selected. Intuitive? At least we don't clutter the UI further.
(In reply to Heiko Tietze from comment #20)
(Shift|Ctrl)+Click - as usual for multi-selection in list? (But no, that's bad, since simple click on the list then would reset all currently selected styles => bad)
Checkboxes to emphasize multiselection idea?
(In reply to Mike Kaganski from comment #21)
> (In reply to Heiko Tietze from comment #20)
> (Shift|Ctrl)+Click - as usual for multi-selection in list? (But no, that's
> bad, since simple click on the list then would reset all currently selected
> styles => bad)
Yes, it's a common interaction, eg. in file browsers.
> Checkboxes to emphasize multiselection idea?
That's one option. The other (simple) solution is to only accept click on item.