Wiki block quote formatting interfering with lists
By wyoung on 2018-09-17 17:25:31 [link]
Take a look at point 2 on the front Fossil page. The second paragraph is indented under the first. This is happening because the wiki formatter is choosing to treat this second paragraph as a
<blockquote>, which in turn is where the extra indentation comes from.
I suspect the extra indentation is an recent effort to make forum posts with quotes more readable, but as you can guess from my recent patch, I think that's not wrong. My patch goes further still.
I think the problem here is the wiki formatter, not the CSS. There's no good reason to consider this second paragraph a block quote.
I hacked around this same problem last night in my recent edits to
www/forum.wiki by removing the white space between two HTML-tagged paragraphs. That should work on the index page as well, but...ick.
By wyoung on 2018-09-21 04:05:24 [link]
To be clear, this problem means either:
Fossil 2.7 can't be released until it's fixed; or
[2190f86c32]must be backed out, else it'll cause the new style to be applied to that second paragraph called out above.
Incidentally, while doing my recent browser compatibility testing, I discovered that the wiki formatter is generating
<p> tags without
</p> and vice versa. Since the fix for the block quote problem is to style list items as
<li><p>...</p></li> when there is white space between items in the wiki markup source, solutions to both problems may be related.
(When the wiki markup source items are packed without white space, the current rendering is correct:
<li>...</li>, no paragraph tags inside.)
By wyoung on 2018-09-22 01:05:25
I've talked with drh, and we're going to let the wiki formatting issue slide, since there's a workaround available — i.e. take out the whitespace between paragraphs and use explicit
<p> tags — which has been applied to
He didn't want my
<blockquote> formatting to apply to all HTML content from Fossil, so it's now restricted to just the forum posts, which means it won't break existing wiki documents that are somehow relying on this bug in the wiki renderer.
So, for 2.7, this thread is as "solved" as it's likely to get.