Elements <ins> and <del> are wrapped in <p> tags about multimarkdown-4

[fletcher]

As I have expressed elsewhere, CriticMarkup by it's very nature will not work properly when applied to the HTML output. It's a feature designed for writing, not formatting. The idea is that the user should accept/reject all changes before converting to HTML (e.g. "publishing").

In simple cases CriticMarkup and HTML output works properly, so MMD attempts to do this. But in more complex examples it generates invalid HTML. There's no way around this, without writing an extremely complex parser that understands what you meant to write, instead of what you did write.

[mn4367]

For the mark-element I agree, that generating invalid HTML is probably 'too easy' (although by using pure HTML elements the user is responsible, not the tool), but for del and ins I don't see the reason. Maybe I wasn't clear enough, I didn't ask for a special syntactic handling, I only asked to avoid wrapping them in p-tags if and only if these elements are alone on a single line like in:

A paragraph.

<del>

Another paragraph.

A second.

</del>

And another.

The reason behind resorting to HTML tags in my case is that

{--

Another paragraph.

A second.

--}

produces invalid nesting of elements (the same is true for {++ ++} , {== ==} and {>> <<}).

For the pure HTML del- and ins-elements there is no need to to handle these elements with -a or -r (although it would be nice). MMD already doesn't wrap elements like for example aside, section, nav and main which have no meaning in MultiMarkdown, nevertheless I can use them, if I need to.

[mn4367]

May I ask an additional question regarding CriticMarkup? Is there a reason, why comments are never output to the HTML document? The CritcMarkup specification says that comments should be wrapped inside a <span class="critic comment"/> span.

[fletcher]

Ahh.. I misunderstood your original question. ins, del, mark are now recognized as HTML5 in latest commit.

As to the second.... CriticMarkup has two parts -- the syntax and how it is exported as HTML. The syntax is a great idea. How it is exported not so much (partially for the reasons as discussed above.)

MMD has built-in support for the CriticMarkup syntax, because I think it's a fabulous idea to allow collaborators to mark up the source text of a document with notes to each other (e.g. "Track Changes"). Even better is MultiMarkdown Composer's ability to compare two versions of a document and automatically generate the CM markup to convert one to the other.

I disagree with their approach to output, however. A comment in this context is not part of the output document. For example, the comment "Tom.... I really like this part!" would not be printed in the paperback copy of a book. It's comment intended for others writing and editing the book, not for those reading the book. Neither would strikethroughs, etc. The "expected" behavior for MultiMarkdown is either the -a or the -r option to generate the original, or the modified, version of a document.

They conflated two things --- the ability to annotate the source, and a means to provide additional markup to the output (e.g. highlights, strikethroughs, etc.) I like one of them (it's brilliant), but dislike the other (it needs work, and is much more complex than they thought when first creating this project, i.e. the difficulty in getting valid HTML output.) What MMD does currently when using -a AND -r is a bit of a compromise.

If you prefer the official CriticMarkup HTML output, then you can always use another CriticMarkup processor before passing the result through MultiMarkdown. Brett Terpstra has also done some interesting things with Marked in this regard.

[mn4367]

Thanks!

The use case you describe is exactly ours. We are using MultiMarkdown to create documents which are transformed via XSL and then are converted to PDF. Since we collaborate on the documents a lot CriticMarkup was really a welcome addition in MultiMarkdown. But sometimes we only exchange the PDF or even a printed version (based on HTML created with -a and -r) and we were missing the comments in this case because some people used the comments to explain why they proposed a deletion or addition.

Maybe it's worth thinking about a command line switch which enables output of comments to the document. The default behaviour as it is (e. g. ignore comments in output) is OK in my opinion, but maybe it should be documented.

Just to be curious, are you considering to support the syntax I used in my example in future versions, e. g.

{--

Another paragraph.

A second.

--}

?

Anyway, thanks again.

[fletcher]

I'll consider an option to pass comments through.

As to the example you use, it works with both the -a and -r options. Getting things to work with
-a -r is up to you. That's what I've been saying -- CriticMarkup is not designed for HTML.

;)

[mn4367]

I'll try my very best to use it properly ;), thanks.