Parsedown has also been moving towards compliance with CommonMark.

http://parsedown.org/

I haven't used Parsedown but I am glad things are moving to CommonMark -- it will shift the focus to performance, structure and extensibility instead of struggling with edge cases and Markdown idiosyncrasies.

PHP CommonMark's compliance is very current--CommonMark spec 0.13, Dec 15, 2014 and it will continue to keep up.

It follows the reference implementation very closely, has good support for extensibility and the code is very well structured. It's likely to become the de facto PHP implementation in my opinion.

Hooray, parsedown! Thank you for your hard work on this, it's my favorite of the PHP markdown parsers. I really like the philosophy and execution.

I like Parsedown its very fast!

https://github.com/thephpleague/commonmark/blob/master/src/U... What is the Point of abstracting away "empty?"

I guess because you're asking a question of the object - "is this empty?"

It already implements count() and the corresponding interface so it's possible to write count($collection) as if you're writing $collection->count(). It's a valid question why this type of object needs two methods for checking the same property.

PHP does not have an interface for empty. count and empty are not equivalent. empty should be called on the underlying array and not the object.

Is there a need for that much of abstraction in a simple markdown parser library?

What abstraction are you specifically referring to if I my ask?

I think parent post is just referring to the number of classes in the source.

It depends which bit you're talking about.

A lot of implementations in various languages go with static regex approaches, which is a bit shit. This uses an AST which helps out a lot.

By adding the customization elements, people can write "GitHub Tables" or any sort of other extra syntax in.

And by keeping the HTML Rendering separate from the parsing process, other PDF renderers or whatever else could be added.

Somebody could make a [Maruka](http://markua.org/) extension for example, which is just CommonMark + Extra tags + PDF / eBook / etc.

It's not madness, and it will be optimized over time. Fear not. :)

By abstracting to the extent that the author has it should be simple to add other syntaxes to the library (e.g. rST -> HTML)

Yes, but project is called CommonMark, so it's markdown only.

I appreciate that, we argued to death on the League internals about the focus of the package:

https://groups.google.com/forum/#!topic/thephpleague/cJECuC5...

https://groups.google.com/forum/#!topic/thephpleague/YBSnpS6...

rST > HTML is less likely, but CommonMark > PDF could definitely be a thing.

It does feel like a bit much.

Aha! The controversial "Standard Markdown" (is that what it used to be called?) has been renamed to "CommonMark", hopefully avoiding the controversy. (Controversial because Gruber didn't like them using the Markdown name in a standardization effort).

I'm glad. I hope to see implementations continue to spread.

Here's a whole update on the general state of markdown

https://philsturgeon.uk/markdown/2014/11/30/state-of-markdow...

Sorry to add a critic. If you want to make your PHP classes easy to extend, refrain from private and prefer protected. Otherwise, a developer that wants to extend one of your classes will need to also override (i.e. copy and paste) into her class all private members called from the members she really wants to override.