org mode supports [1] setting the value attribute [2] of ordered list items to
change the numbering for the current and following items. Let's do the same. As
the attribute has no meaning for other types of lists [2] we'll just not
support it for those cases [3].
[1] https://orgmode.org/manual/Plain-Lists.html#Plain-Lists
[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/li#attributes
[3]
Org mode seems to instead set the id attribute for e.g. unordered lists
starting with `[@\d+]\s` - but I don't really see the value in that and will
skip that for now.
All tags are put on a line by themselves to help with visual
diffing. Apparently this extra cosmetic whitespace causes problems inside p
tags for ppl who want to use `white-space: pre`. Not much hurt for visual
diffing in removing cosmetic whitespace for just p tags and can't think of
anything that would break because of this right now. So let's do it and wait
for things to break.
now that i'm already looking at it due to the bug leenzhu found why not put the
</dt> on a separate line to match the convention - looks better to me; doesn't
change anything.
I didn't consider that all newlines in the pre block will be printed and we
thus shouldn't wrap html that has it's tags on separate lines (i.e. contains
superfluous newlines) - wrapping in a div less accurately represents
org-html-export but it provides the same information and gives us more freedom
in the return value of HighlightCodeBlock as well as allowing us to keep the
html tags on new lines (consistency).
also dismiss implementing ordered list bullet overrides for now, e.g.
1. [@10] foo
add it once someone needs it - for now it seems like needless complexity
see https://orgmode.org/manual/Checkboxes.html
We're deviating from Org mode regarding the assigned css classes but the chosen
classes feel better than (on, off, trans) and it's not like the export matches
1:1 otherwise.
While adding another test case from the goorgeous issues it became clear that
inline markup and html entity replacement were erronously applied to raw text
elements like inline code =foo=, src/example/export blocks, example lines,
etc.
To correctly handle those cases in both org and html exports a new
parseRawInline method had to be added.
Also some misc html export whitespace fixes and stuff
Also dismissed implementing colgroups for now - had it but didn't like the
added complexity for a very questionable benefit - i've actually never used
that feature of org tables...
... hopefully correctly
This will hopefully improve ease of developing (more granular test results) and
prepares us for adding example org->html renders for gh-pages
