Created attachment 193628 [details] Example file with para DF overriding implicit List style When a bullet and numbering is applied from the toolbar, an implicit list style is created, which can be seen in the Style inspector. Problem is that the settings in the B&N dialog can be overridden by paragraph direct formatting and after that, it is not obvious why changes made in the B&N dialog are not applied to the already direct formatted paragraphs - especially if all paragraphs are such. It would be better to somehow make it obvious that this dialog is editing a style and the user would then get a hint that the paragraph settings can actually be modified elsewhere too. I'm not entirely sure what would be a good solution here. For comparison when a list style is edited from the sidebar, the dialog title says "List Style: Bullet –" or similar. -> Maybe retitling the B&N dialog to "B&N style" could help. Another idea is to put some warnings to the Position tab that the "Indent at" and "Aligned at" values can be overridden by paragraph settings (by Before Text Indent and First Line Indent resp.) - not even the extended tip of the relevant boxes say this, maybe changing that could help. Or some info label in the dialog telling that "These settings can be overridden by the paragraph formatting" 1. Open attached document 2. Right click on the text, choose List - Bullet and Numbering 3. Go to the Position tab 4. Change the Aligned at or Indent at value, press OK -> Figure out on your own why the a) and c) paragraphs formatting changed but not b)'s. My other report about extending Spotlight to List styles also aims to solve this issue, although in an "after the deed" style. But it would be nice to have something during editing.
Created attachment 193629 [details] For reference: dialog title if a preset List style is edited from the Styles sidebar - makes sense
Created attachment 193630 [details] B&N dialog does not say this is a List style, but Style Inspector says this has a name 13404...
lovely topic, Gábor. Snake pit as well ;)
Looking from the other side, cleaning implicit list is not possible with Ctrl+M, and is one of the most exhausting task we have in editing the Guides.
We discussed the topic in the design meeting. The fact that list styles are an attribute of the paragraph is hard to understand for users. The convenience feature to create a list style on-the-fly when clicking the toolbar item almost impossible to understand for ordinary users. And obviously there are a lot of issues around this topic. Changing a label wont help here. For sure it helps if we remove the convenience functions and make the list style look like being applied separately from the PS. But neither we want to heavily cripple the application nor would it be accepted by users. Looks like this is a WF.
Renaming won't help - I agree. However, I don't see harm in the additional *info label*, as alternatively requested here. The problematic areas in general might ask for additional infolabels as a first step - that, IMO, should become the first instinct. See bug 159985, where we have already implemented something similar (just here it doesn't need to be dynamic).