The specification explicitly allows nesting of <text:span> elements. Thereby character styles are put on top of each other without introducing an inheritance. Files where this is used work fine and in using hard formatting it works fine too. Only in using styles it fails and the surrounding style is removed. In testing for https://ask.libreoffice.org/en/question/144399 I noticed, that nesting is possible using shift+doubleClick in version Version: 6.1.0.0.alpha0+ (x64) Build ID: facfc2951ea9f4745edd4a6fb1cf97697f33f40a CPU threads: 8; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2018-01-14_00:42:04 Locale: de-DE (de_DE); Calc: CL But that seems to work accidentally. So my request is, that a UI is added to put a character style on top of another by nesting <text:span> elements. There is likely a better method than shift+doubleClick, especially as accessibility has to be considered too.
Created attachment 139970 [details] Illustration of the issue "Suddenly..sidewalk" are formatted with Strong Emphasis, "disappeared" in the middle with additional Emphasis using shift+click and "the trash... in the" below as well in Emphasis but without shift, meaning it's replaced. The request is solely technically driven and I recommend to not do that. The redesign complicates the UI significantly with benefit in only a very few situations but serious disadvantage for most users. If we need to support these nested styles (my suggestion would be to remove them from the file format), the easter-eggy shift+click thing is good enough. But we should give better feedback as discussed in bug 90646, whereas I would prefer the inspector from bug 112852 comment 10. We should also not forget the "inconsistency" (actually I like it) mentioned on ask.libo that the Default style that is never nested.
(In reply to Heiko Tietze from comment #1) > The request is solely technically driven and I recommend to not do that. > ... > If we need to support these nested styles (my suggestion would be to remove them from the file format), the easter-eggy shift+click thing is good enough. I strongly disagree. The ability to nest character styles is extremely important for complex documents. It's the only sane way to represent semantic or formatting considerations that are orthogonal to each other. Style support is a widely touted feature of LO (and rightly so), but these kinds of limitations (can't nest character styles, can't inherit page styles, graphic styles not available in Writer, character styles not available in Impress...) prevents it from realizing its potential. Undocumented features are just as bad as not having the feature at all, unless you have unlimited time to tinker. I was extremely excited to learn that this might already work, because if true it's one less reason that I might need to use LaTeX. I never would have discovered it if not for Regina's exploration. Personally, I think a second "apply" button that nests rather than replaces existing styles would be an unobtrusive way to make nesting available. At the very least, the double-click feature should be confirmed and added to the help text.
(In reply to Kenneth Hanson from comment #2) > I strongly disagree. The ability to nest character styles is extremely > important for complex documents. It's the only sane way to represent > semantic or formatting considerations that are orthogonal to each other. Can we find a good example? Something like but better than: * in-text citation with highlighted words. "And she said:<i>Though shalt <b>NEVER</b> format directly!</i>, and went away." (<i> and <b> as html-like illustration of character style 'cite' and 'emphasis'). In the example you get NEVER in italic from cite plus bold from emphasis but I think a direct formatting would be fine here just for simplicity of the UI. When you present Change and Apply (or Add) I doubt that users understand that. Visualization could be done via tree where the second style is a children of the first (still not easy to understand).
Nested character styles are really cool. I also often wished that such feature is available in LibO. Good to hear that it's possible and that's also possible with buttons in the "Formatting (styles)" toolbar. But how long? How should nested styles be handled in the UI? LibO isn't prepared for this. How should nested styles (=several styles at once) be shown in the Styles sidebar? Or in the menu or context menu? There, character styles are now implemented as radio buttons (only one can be selected) which must be changed to checkboxes (more than one can be selected at once). And what's with the default character style? Does it override all nested character styles or only the "last/topmost" one?
Created attachment 141502 [details] Mockup for nested styles including comments Basically, the idea is to provide a multi-selection in the character styles list (same idea was suggested back in OOO times). Such a modification involves questions on single/double click activation of styles (bug 94427), requires a way to indicate overridden properties (done per style inspector, see bug 112852), which in turn is relevant for bug 90646. And also how paragraph styles are filtered (bug 114886, bug 69551). See comments in the mockup for details.
Very nice mockup. I see the benefit of a list box instead of buttons for all kind of styles (paragaph, character, list ...). For the average users it's more intuitive and clear. But with any style change you have to do an additional mouse click. That's bad for users that heavily use styles. Also I think the small paragraph and character boxes are negative for heavy style users. Is this really so much better for the average users? Will they better understand the difference between paragraph and character styles, when they are arranged/visible at one sidebar deck at once instead how it is now?
(In reply to Thomas Lendo from comment #6) > But with any style change you have to do an additional mouse > click. That's bad for users that heavily use styles. Like today, the selection changes with the context. So if you are in a table you get table styles selected. So no additional click needed. > Also I think the small paragraph and character boxes are negative for heavy > style users. True, we loose some space even taking into account that mockups are not proportional and the UI may have more space on average screens. We focus on the Benjamin users, which definitely benefit from the combination. And the supposed way for expert users who need a lot of paragraph styles at once is to collapse the character styles panel. We could also discuss to collapse the inspector by default.
(In reply to Heiko Tietze from comment #7) > supposed way for expert users who need a lot of paragraph styles at once is > to collapse the character styles panel. We could also discuss to collapse > the inspector by default. The possibility to collapse paragraph/character/inspector panel (which should also persistent across sessions) is an important feature for Eves. The filter options 'Preview...', 'List used styles...' and the filter drop-down list is also important for character styles - or work the filters for both panels at once? If yes then the position can be enhanced to show that. Is it desired to show how styles are nested? A new filter checkbox 'Show nested styles' can show only nested styles in a hierarchical way to see which is on top of what style.
Curious about Csongor's opinion.
(In reply to Heiko Tietze from comment #9) > Curious about Csongor's opinion. Thanks, Heiko. :) Before going into further details, I would like to clarify for the readers like me, who do not read carefully at first, that we are talking about the character styles only, not the paragraph and other styles. Well. There are some bullet points to agree/disagree with. 1. I agree that having the option to build a hierarchy of character styles is a great thing. We should not get rid of it, even if most of the users don't use it. One source of the power of LO is that it is extremely feature-rich. I would like to keep this and not make it "more streamlined" or "simpler" in terms of the feature set, like many "modern" software does. (The easiness of usage, however, is a different thing, I admit.) So let's keep features and based on this, let's figure out how to make it easy to use. 2. I agree that the UI for such complex document structures is not easy. 3. How should we indicate what styles are turned on at the actual character? I re-read my proposal in https://bugs.documentfoundation.org/show_bug.cgi?id=112852#c9. The illustration after that comment may be not the best but I still think that such a tool could explain well how the rules with higher importance override the rules of lower importance. The strike-through notation in the Developer Tools of the modern browser, I think, does this job very well. In order to make my earlier proposal easier to understand, I created a new illustration with a lot of verbal explanation within the document. Please, check it. Some keywords and highlights from the attachment so that it can be indexed: - applying more character styles (current and desired behaviour) - cascade - description of how the Style Explorer should work - greyed out and strike-through - toggling rules - drag-and-drop reordering of the character styles - "Select Similar", "Select Similar to Left" and "Select Similar to Right" toolbar buttons - "Extend Selection to Neighbourhood", "Extend Selection to Left Neighbourhood" and "Extend Selection to Right Neighbourhood" toolbar buttons
Created attachment 141973 [details] Explaining Cascaded Character Styles via Style Explorer
(In reply to csongor from comment #11) > Created attachment 141973 [details] Thanks a lot, great to have different proposals. I would prefer to not show all style properties (e.g. Default: Blinking=No), rather what's different to the used paragraph style, i.e. direct formatting. Your temporarily on/off feature sounds like an overkill to me and clutters the UI a lot with all these checkboxes (could be solved with a context menu, though). And last but not least it's not easy to understand the hierarchy without indentation. Admitted that your layout is more flexible and readable. Maybe we put some arrows in front of the list items pointing from bottom to top. But that's all my two cents and the discussion is open. (In reply to Thomas Lendo from comment #8) > The filter options 'Preview...', 'List used styles...' and the filter > drop-down list is also important for character styles - or work the filters > for both panels at once? If yes then the position can be enhanced to show > that. Correct, missed that. So we better group paragraph and character together as both are toggled with the kind of style anyway. And to clean up the UI I would think about moving the checkboxed options from paragraph styles into a context menu. > Is it desired to show how styles are nested? A new filter checkbox 'Show > nested styles' can show only nested styles in a hierarchical way to see > which is on top of what style. You mean in the character styles list?
(In reply to Heiko Tietze from comment #12) > (In reply to Thomas Lendo from comment #8) > > The filter options 'Preview...', 'List used styles...' and the filter > > drop-down list is also important for character styles - or work the filters > > for both panels at once? If yes then the position can be enhanced to show > > that. > Correct, missed that. So we better group paragraph and character together as > both are toggled with the kind of style anyway. And to clean up the UI I > would think about moving the checkboxed options from paragraph styles into a > context menu. But context menus are not very accessible/visible -- neither for normal users nor for impaired users. > > Is it desired to show how styles are nested? A new filter checkbox 'Show > > nested styles' can show only nested styles in a hierarchical way to see > > which is on top of what style. > You mean in the character styles list? Yes, I mean character styles. But when paragraph and character styles will share the same checkboxes, then no new checkbox is needed as paragraph styles already include a checkbox for hierarchical view.
I like Csongor's proposal very much! One thing though. The character's "Default Style" itself doesn't define anything at all. There are no settings there IIUC. And it is not always there at the bottom of the character properties hierarchy. Actually, Character-related settings of *Paragraph properties* are there, and those properties are what is being overridden by higher layers. And the Paragraph properties consist (from top to bottom in terms of Csongor's proposal) of paragraph's Manual formatting, and Paragraph style. The ability to *disable* (uncheck) some direct formatting or styles looks like an extension to ODF (at least I don't know how to disable that at the XML level). I'd suppose that deleting makes sense, an well as dragging style to reorder, and possibly dragging styles from style pane if they can be shown simultaneously. Possibly the default character style still makes sense as a (greyed out) single-line entry right above the Paragraph properties, to make it consistent when the last applied non-default character style gets removed, that one would still stay (instead of appearing only in that case). Possibly it also makes sense to delete direct formatting of paragraph's character-related settings from the character settings explorer. That would make it more universal. And of course, being able to launch the related style's editor dialog is something intuitive.
*** Bug 127754 has been marked as a duplicate of this bug. ***
*** Bug 128553 has been marked as a duplicate of this bug. ***
Don't remember the state in 23018 but with v7.3 at least it is possible to make one CS inherent from another by drag and drop at the Stylist. We also have the "Inherit from" field in the Organizer tab. And the nested CS takes attributes from the parent. So all works similar to PS. Regina, resolve WFM or am I missing a point?
(In reply to Heiko Tietze from comment #17) > Don't remember the state in 23018 but with v7.3 at least it is possible to > make one CS inherent from another by drag and drop at the Stylist. But that's not what this bug is about. It's about applying more than one character style to the same piece of text, not about styles inheriting from each other. See your own comment here: https://bugs.documentfoundation.org/show_bug.cgi?id=127754#c2