-
Suggestion
-
Resolution: Won't Fix
-
None
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
Scott F. was nice enough to suggest that I post this for consideration for a future release that addresses macros.
To summarize, disconnected numbering in Confluence today (2.5.4) can be problematic both in terms of keeping numbering from reverting to "1." and in terms of keeping indentation correct. This is particularly a problem for documentation being created in Confluence because such doc is so dependent on ordered lists.
We've successfully implemented three macros that address this issue by exposing HTML numbering a little more directly. The macros are:
macro | definition |
---|---|
setnumlst | <ol start=$param0 TYPE=$param1><li>$body</li> |
lst | <li> |
endnumlst | </ol> |
Thus something like:
{setnumlst:3|A}Is this the third item in the list?{setnumlst}
Would appear as:
C. Is this the third item in the list?
and would be independent of any other numbering.
Here's a little more elaborate example:
You can inspect an existing key by:
{setol:1|1}Opening the key schema file.{setol}
h5. Inspecting a Key Schema
!dsp30:images-datasrvc^Inspecting a Key Schema.gif|thumbnail!
----
{endol}
{setol:2|1}Double-clicking on the key element.{setol}
h5. Elements in a Key Element
!dsp30:images-datasrvc^Key Elements in a Key Element.gif|thumbnail!
I'm attaching a picture of the result - the nice thing is that it isn't dependent on careful wikimarkup line spacing, etc.
Thanks for considering this.
Although we've installed and used these macros, I wouldn't say that they have been extensively used by any means. If I discover any problems going forward I'll update this. Also, the names are probably problematic but I couldn't think of anything better. Cheers,
- relates to
-
CONFCLOUD-9023 Improve control over numbering on Confluence pages using html macros
- Closed
Given that this issue has been open for more than four years and with very little customer traction and demand, I'm going to resolve this as "Won't Fix", as we cannot see ourselves implementing this in the foreseeable future. If circumstances change, we will reopen the issue where appropriate.