Vanilla-flavored Markdown as basis for state machine spec

[roop]

@jgm Glad you consider that my comparison piece could be of help. You might also want to take a look at my other post too in case you hadn’t already.

@jgm

• I didn’t write the statement that said one of our goals was to make something easy to parse, and it wasn’t in fact one of my major goals in writing the spec.

If “ease-of-parsing” is not a goal of your spec, I urge you to reword that statement from the homepage (the one that says: “one of our major goals is to make Markdown easier to parse”) asap, since it’s misleading. (I’m surprised you haven’t corrected it already.)

Nevertheless, I felt that some parts of the CommonMark spec did seem to prioritize ease-of-parsing over readability / intuitiveness (e.g., the suggestion to use 
 within pre elements).

• I hadn’t realized that vfmd had a similar rule for HTML blocks; that’s interesting. I agree that, if we stay with this rule, making an exception for pre, script, and style blocks is a good idea.

I would consider it essential to make an exception for those tags. Do note that vfmd goes further and checks whether the pre / script / style tags are actually closed correctly as well.

• I think it makes sense for tight/loose to be per-list, since lists with some tight and some loose items look bad. Also, although a per-item distinction makes sense in HTML, it makes less sense in other output formats we might want to target, e.g. LaTeX.

In my opinion, a Markdown spec needn’t restrict itself to the common-denominator-only feature set. If it makes sense in HTML but doesn’t in LaTeX, then that particular feature can have an effect in the output HTML but not in the output LaTeX.

Even if “lists with some tight and some loose items look bad”, if that’s what the input suggests, that’s what we should interpret it as.

• As I mentioned, the new emph/strong rules restore the symmetry between **foo* bar* and *foo *bar**. We still skip over spans of four or more * or _ characters, but I will experiment with dropping this. One reason for including it is that people sometimes write ________ for a blank in a form etc. …

Great. I haven’t studied the updated spec, though.

I don’t understand what’s the problem with _____ for use in forms - wouldn’t the ___s be surrounded by whitespace on either side and therefore not interpreted as emphasis anyway?

• I’m not so concerned that CommonMark will yield bad HTML when bad HTML is fed into it.

Are you talking about the stuff under the “Span-level HTML” heading in my comparison piece? If so, I don’t think the inputs *foo <u>bar* baz</u>* and *<p>foo</p>* can be called bad input HTML.

• Alt text should probably be preserved as is, rather than processed as it currently is.

I think it’s quite obvious that the alt text shouldn’t be subject to any processing. I thought that was a bug in your code that seeped into the spec.

I don't have a strong opinion on the rest of the bullet points in your post. They can all have valid arguments either way, and I think it's best to just pick one and run with it.