Problematic whitespace needs removing

[Ashtagon]

The standard list syntax generates the following html code:

<li class="level1"><div class="li">
List item text here
</div></li>

Note that there are carriage returns before and after the actual rendered text.

I'm doing some advanced manipulation of the way lists render using css, and that whitespace is causing a problem.

Digression: The normal rendering for a list is:

• one
• two
• three

I want it to render as:

one; two; three

I am using the wrap plugin to generate custom css code. I use content:after css to insert semi-colons, and set the display of each <li> element to inline. The carriage return whitespace before and after the text in the html code gets rendered as a space when display: inline is set, because that whitespace is no long at the beginning or end of a block.

My custom css for use with the wrap plugin is:

div.dokuwiki div.wrap_compact  ul li { display: inline; }
div.dokuwiki div.wrap_compact  ul div.li { display: inline; }

div.dokuwiki div.wrap_compact  ul li:after { content:";"; }
div.dokuwiki div.wrap_compact  ul li:last-child:after { content: none; } /* no semi-colon after the last list item */

Is there a css-based solution to this problem, or can this only be fixed by forcing the dokuwiki engine to stop generating the superfluous carriage returns. If the latter, how would I edit the php code to fix the problem?

ETA: I ran a test in which I saved the generated html page to my desktop, edited out those whitespaces manually, then reloaded it. The resulting page displayed as expected, with the extra space characters removed. This confirms that it is those carriage return characters that are getting rendered as spaces.

First reported at forum: https://forum.dokuwiki.org/post/46068

[zioth]

Whitespace is rendered in inline and inline-block elements. While an inline <li> is an unusual thing to do, inline-block is common.

You can work around the whitespace in CSS by having a negative left margin which is as wide as a space character, but that's going to render slightly differently with each font, so fixing it in the doku engine would be better.

Then again, fixing it in doku might mess up templates that unknowingly depend on that extra space.

[selfthinker]

DokuWiki was created (2004) before the glorious Firebug existed (2006). Back in the day adding a couple of new lines was the only way to keep code readable and therefore maintainable. But nowadays with code inspectors being the normality, I would vote for getting rid of a lot of new lines in the DokuWiki output.
Yes, that might potentially break a few templates, but I would be willing to risk that.

[splitbrain]

@selfthinker I'm fine with removing superfluous whitespace. PR welcome.

[Ashtagon]

The only superfluous whitespace that needs to be removed in order to solve this problem is the whitespace generated immediately before closing tags.

More specifically,

<li class="level1"><div class="li">
 List item text
</div></li>

Could be generated as:

<li class="level1"><div class="li">
 List item text</div></li>

This should be the smallest change necessary to fix the problem. I've no strong opinion on whether other whitespace should be removed. It may be useful for those who want to be able to inspect the code by eyeball though. The key issue is to remove any superfluous whitespace that actually gets rendered by the web browser.

[zioth]

All spaces matter in inline elements, so the leading spaces would also have to be removed.

[Ashtagon]

There are no superfluous space characters in the code. The code contains superfluous carriage returns, which the html parser then (correctly according to standards) renders as a space character.

If keeping the generated code human-readable is considered important, perhaps the carriage returns could be generated before the opening tag and after the closing tag, rather than how it is at present (after the opening tag and before the closing tag).

[ssahara]

Hi @Ashtagon, I have just come here from a forum thread titled "how to remove unwanted space rendered by line break char in multiline paragraph".

As I wrote today at the forum thread, superfluous carriage returns / linebreaks can be removed using a render type plugin components. For your convenience, you may try my LineBreak2 plugin package. I do not know well whether it will be a practical solution for your issue.

Anyway, removing \n in cdata() calls will concatenate two lines before and after the \n. Please think of how the following strange wiki source will be rendered in the wiki page.

This is a long sentence that is intentio
nally folded using line break at any len
gth. The line break char ''**\n**'' at t
he end of line will be removed and conca
tenated with next line.