I have spotted a formatting bug that occurs when you place indented (pre-formatted) text directly below a heading without a blank line.
For example, if you do:
==== Heading ====
Some sample preformatted item
You will find that Paragraph A and Paragraph B have no line-spacing between them. If you put a blank line between the heading and the preformatted text everything is apced properly again.
Futhermore, a heading will sometimes not have spacing above it. E.g., try this:
====== Level 1 Headline ======
===== sample =====
Here is a paragraph of some text. and then before we enter into the next section we would want a space between this paragraph and the heading...
==== Level 3 Headline ====
Now another literal.
Here is paragraph A.
==== Another L3 heading ====
This L3 heading has proper spacing above.
You will notice that there is more space above "Another L3 heading" than there is above "Level 3 Headline".
I repeated the results in Linux and Windows, on Firefox, Konqueror, and MSIE, using heading level 1, 2, and 3, and also using the Default, Roundbox, and Usable themes.
Confirmed. The problem is that a text coming directly after a preformatted block will miss the <p> tag around it.
The above description of "a heading will sometimes not have spacing above it" is exactly the same. It's the text above the heading that's missing the <p> tag again.
Also, it might help to know that there is no problem with <code>, though ...
Its a design failure which coincidentally, of all the core syntax modes ONLY affects the 'preformatted' syntax mode. The same failing could affect plugin modes.
The criteria for a syntax mode to be affected are:
- block mode
- no separate closing instruction
- actual pattern swallows any trailing eol character
Solution (messy) is to add two 'eol' instructions to the call stack after the instruction for the problem syntax mode. One 'eol' instruction replaces the missing eol, the second is required to trigger a full paragraph start if the syntax mode is used at the start of a section. This may result in an empty paragraph, but dokuwiki should clean those up.
I think as there is the workaround of using <code> instead, fixing this bug isn't too important.
IMO, if there are only dirty ways to fix it, it shouldn't get fixed. If there is a clean and not too complicated way, it should get fixed.
agreed with Anika