If we think of styling/formatting in HTML documents, we'll notice that, like in LO, you have direct formatting - setting the style="..." attribute of a single element; and we also LO-like "styles" in the form of CSS classes. One interesting difference between CSS classes and LO styles is, that a single element can have _multiple_ styles applied to it at once. LO should also support this. In writer, an obvious example would be "Internet Link" and "Emphasis". Why can't I have a segment of text (within some paragraph) which is emphasized, and also contains an "Internet Link"? But this is also relevant for paragraph styles. Say, "Footer" and "Blockquote". I can put a blockquote in a footer if I want to, right? Same goes for page styles: There's an "RTL page" style; and you could have a page style with decorated margins. Surely it makes sense to combine them. Proper support for combinations of styles is important for encouraging the use of styles over direct formatting - as the unattainable combinations tend to make people use DF rather than generate the 2^n combinations they may be interested in. Related bugs: * Bug 115311 - UI missing for nesting character styles. Nesting is similar to just combining styles, but perhaps not exactly the same thing; also, I'm generalizing to other styles as well * Bug 149230 - Create sketches for ajlittoz's vision of a UI promoting the use of styles * Bug 127702 - Support setting quantitative font features relatively to underlying paragraph style. There would need to be an ever more expansive support for making style specs relative and partial. * Bug 108498 - Character styles not working against the underlying paragraph style. See discussion there regarding whether (character) styles need to be relative/differential and to what.
What you are looking for is near to the ODF attribute text:class-names. https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#attribute-text_class-names That is not implemented in LO. Currently you can only make a hierarchical tree of styles using inheritance. So I take this as enhancement request to implement the attribute "text:class-names".
I don't see what aggregation of several styles of the same category could mean for a style category like paragraph, where styles by definition define every single property (either directly, or by inheritance). While reasonable (and existent) for style category that allows some properties stay undefined (character), aggregating paragraph styles would simply make "last wins and overrides everything from previous ones" effect. So this must first define what changes would be needed to the architecture of the styles that *currently* define 100% of their properties, and what side effects would it mean to their effects and usability (I don't mean file format - it's unrelated, and is only a technical issue).
(In reply to Mike Kaganski from comment #2) > I don't see what aggregation of several styles of the same category could > mean for a style category like paragraph, where styles by definition define > every single property Well, not if you consider inheritance. > (either directly, or by inheritance). Ah, but that's the point. If we have styles A, B, C with B and C inheriting A, then applying B and C means applying both the changes B makes to A and the changes C makes to A. Naturally there's the question of conflicts. This can be settled either by order of application (i.e. search orders C,B,A or B,C,A with the A being implicit), or arbitrarily, i.e. the app doesn't guarantee which of B and C's changes would be used, and it's the user's problem. Since all styles inherit from the Default Style of their kind, we don't have the problem of multiple inheritance-roots. For a concrete example, think of Default Page Style, RTL page, and a DecorativeFrame style. Each of the child styles only defines what its name suggests. The composition would be "RTL, DecorativeFrame" (or the other way around, doesn't matter).
See also: https://ask.libreoffice.org/t/can-conditional-formatting-also-apply-multiple-styles-pertaining-to-different-aspects-of-a-cell-background-vs-font/86052. The cell styles defining 100% of their properties create much trouble very often, especially in conditional formatting feature, which requires much of redundancy in styles.
Writer is base on a layered model: paragraph, character, Internet Link, direct (from bottom to top). You may be surprised to note I grant special status to "Internet Link" character style. It has a unique property that any link created by Insert>Hyperlink receives an extra character style above the standard style. Since paragraphs are the basic unit of writing, I don't see what a "combining" style application could do on paragraphs. Semantically, a paragraph is "atomic". A paragraph style is applied over the whole extent of the paragraph. If your goal is to override a few parameters, you can do this with style inheritance. A paragraph style also defines a default character style. This default can be overridden by applying an explicit character style. The parameters which are in "transparent state" won't change those in the paragraph style. Unfortunately, this "transparent state" is not highlighted in any way in the UI. You can force it by pressing "Reset to Parent" but few users understand the result of it. Multiple applications of character styles is surely a desirable enhancement. Presently, only a single style can be applied which necessitates to statically combine the attribute into separate styles leading to a combinatorial explosion. However one must be careful in defining "multiple application". It is rather straightforward if set attributes are not conflicting (IOW no same parameters are set to different values). Otherwise, as Mike Kaganski states it under the "last wins and overrides everything from previous ones" effect, formatting result will depend on the order of application. What is non-deterministic must be avoided. Technically, it may become extremely difficult to recombine the <span>…</span> when editing the document in order to avoid fragmenting these sequences (with the ultimate result of getting single character spans). You mention in another bug report the inconvenience for character styles to be unrelated to the default defined in the paragraph style. I understand the present simplicity in character style inheritance as an easy track for developers. Character styles inherit between themselves. Top-of-hierarchy styles inherit from defaults defined in Tools>Options, LO Writer>Basic Fonts. Unfortunately, all computations involving %-sizes are made at creation time leading to static immutable sizes. On the contrary, in paragraph styles, the default character parameters remain "dynamic" and are recomputed when their base changes. Surely a first improvement in character styles would be to keep this auto-recomputation feature so that changing something in the ancestor cascades down to the children. And if dynamic behaviour is accepted and implemented, nothing could prevent from considering that the top-of-hierarchy character style inherits from the paragraph default style. This enhancement would solve a blatant difficulty when using two different font faces in the same paragraph (e.g. a serif one and a monospace one to "quote" computer output). More than often the x-heights are not the same. The Source Text character style (as an example) bears the monospace font face and the size should be adjusted to say 80%. Presently, the font size is computed when the style is modified, full stop. This makes the character style usable in a single paragraph style, like Text Body, but not in footnotes where the font size is usually smaller than in the narrative. This a serious hindrance to semantic styling. The workaround is either to reconsider the face choice (difficult due the restricted choice in open & free type faces or for aesthetic reasons) or to create "context-dependent" character styles which goes against the principle of "generic" semantic styling. There is also a difficulty with character styles I have no solution for. In typography, a portion of text can be "emphasised". This translates as using a different font variant. E.g. if text is Roman, use Italic; if text is Italic, use Roman. This can't be done presently: 1 - there is no provision to "probe" the ancestor style and set a different value for an attribute (this goes beyond simply toggling a binary attribute as font variants are numerous) 2 - a character style is unaware of what is presently active in the paragraph default character style because a character style doesn't inherit from a paragraph one (see above). Regarding pages, the biggest shortcoming is the absence of inheritance between styles. Personally, I don't see what "composite page styles" would do. If the goal is to modify geometrical aspect of an area within the page, there are two ways to do this: a frame or a section. A frame creates a secondary text flow independent from the main flow, so this is probably not what you are looking for. A section can modify margins (through its indent parameters) and number of columns. A section has no header/footer of its own. If you need such, then this is a role for a page style.
(In reply to ajlittoz from comment #5) > Writer is base on a layered model: paragraph, character, Internet Link, > direct (from bottom to top). 1. Writer is based on ODS. So whatever happens there, should generally be able to happen in Writer. And - ODS sometimes changes to accommodate new functionality, so even that is not set in stone. 2. Direct formatting can be applied to paragraphs and to characters, so I don't see how you placing it in a hierarchy makes sense. Also see below about Internet Link. > You may be surprised to note I grant special status to "Internet Link" > character style. It has a unique property that any link created by > Insert>Hyperlink receives an extra character style above the standard style. I gave Internet Link as a typical example, but given that it gets special treatment - I'll amend the example to side-step that particular situation (although it's still a valid example I encounter occasionally). Suppose I have character styles for: * Quoted text (as opposed to a paragraph-level block-quoting) * Published article title * Source code (again, not a full source-listing paragraph) * Emphasis. Now, if I want to: * Refer to a published article whose title contains an emphasized word (or in whose title I want to emphasize a word) * Quote some text which itself emphasizes a phrase or mentions a piece of source code. then I need to combine more than one of the relevant character styles. > Since paragraphs are the basic unit of writing, I don't see what a > "combining" style application could do on paragraphs. What about my example (of a blockquote in a footnote) was not clear? Or - do you believe it's invalid? > If your goal is to override a few parameters, you can do this > with style inheritance. No, I can't. Or rather, I can only do it by an enormous blowup of duplication: For supporting a combination of k styles out of N, I would need to define a style inheritance tree of depth k with node out-degree N, having N^k leaves. That's a tremendous amount of work already, not to mention how every change to one of the styles which is not arbitrarily chosen to be at the top of the hierarchy would necessitate changes to a large number of other styles at the same level of the hierarchy. And it's not just me who would need this: LO _already_ needs this. Even with the styles available by default, we're missing these duplicates: "Footnote Blockquote", "Endnote Blockquote" etc on the paragraph level, and some combinations of Page Styles etc. And let's not talk about triplets of styles, which occur less frequently but do actually occur. I would like to address the rest of your comment, but - I thought maybe we should focus on the motivating examples first. If you'd rather I answered the rest of your comment, please say so and I'll do that.