Question

I have a common markdown content, without any specific attributes. When rendering markdown to HTML, I want to see some CSS Classes on HTML nodes.

Let's say :

• All H1 nodes : .title-main
• All Table nodes : .table
• All Table Row nodes : .table .table-row

Is this possible without creating custom renderer ?

It could be awesome to be able to configure using the environment :

$config = [
  'html_classes' => [
    'h1' => '.title-main',
    'table' => '.table',
  ],
];

The use case is : I'm using a bought theme that request some css class. I don't want to change markdown original content, and I don't want to change theme.

Thank a lot for your awesome job on this package !

Regards,

• [x] Add base Node object which uses double-linked list
• [x] Cleanup deprecated methods calls
• [x] Add NodeWalker
• [x] Simplify inline parsers
• [x] Cleanup code

This PR includes major refactoring of current commonmark implementation

Changes

• Double-linked list based AST
• Simplified Delimiters and Inline parsers: instead of storing position, we now can store InlineNode.
• Ability to modify AST in runtime by using NodeWalkers
• AbstractInlineContainer replaced with InlineContainer interface

NodeWalker

NodeWalker can be used to change AST in runtime. Each node has walker method, which will create node walker for given node. Here is example of how to capitalize all emphasis in document:

$doc = 'Hello *world*';

$ast = $parser->parse($doc);
$walker = $ast->walker();
$inEmphasis = false;

while (($event = $walker->next())) {
    $node = $event->getNode();
    if ($node instanceof Emphasis) {
        if ($event->isEntering()) {
            $inEmphasis = true;
        } else {
            $inEmphasis = false;
            // add Emphasis node's children as siblings
            while($node->firstChild()) {
                $node->insertBefore($node->firstChild());
            }
            // remove the empty Emphasis node
            $node->detach();
        }
    } else if ($inEmphasis && $node instanceof Text) {
        $node->setContent(strtoupper($node->getContent()));
    }
}

$html = $renderer->renderBlock($ast); // <p>Hello WORLD</p>

Given that @philsturgeon nearly wet his pants in excitement about this repo, I figured I'd check it out. I've been using cebe/markdown as a base parser - with extensions for leanpub's garbage - and while I'd like to switch to this, I haven't been able to figure out where I should hook into to add custom directives.

Any thoughts on how I might go about this?

So this is more of an open-ended question of sorts.

Are there any plans for providing a PECL compatible extension of this project?

It'd be nice to have the power/speed of https://github.com/commonmark/cmark that mimic this project's APIs.

I've found https://github.com/krakjoe/cmark, but it seems to be a completely custom and standalone implementation.

Our approach to configuration has a few shortcomings:

• No support for providing default values, overriding them during MD->HTML conversion, and then rolling back before subsequent conversions
• No support for validating types
• Too many ways to set, get, and override configurations, some of which support /-delimited paths and others that don't
• ConfigurationAwareInterface potentially allows people to pull configuration values out immediately instead of hanging onto the ConfigurationInterface object and lazily checking values later - the latter is recommended, but we don't document that anywhere.
• It's basically a free-for-all

The current approach works well enough for 1.x, but it's going to prevent some features like #442 being able to override configuration values (without causing weird side effects)

I'd therefore like to revisit how we implement, handle, and document Configuration within this library for v2.

See #253, this is still WIP. That was easier than I thought, however I think it will require some more thinking. I'm pushing it "as-is" so that we can progress on what to do:

• what name for the option controlling "allowing unsafe links"?
• do the constants on the Environment class make sense to you?

Feel free to send any other comment about the code, including small coding style stuff, I don't mind at all.

The new html_input option allows 3 different behaviors:

• strip HTML input
• allow HTML input
• escape HTML input

• [x] Option to disable parsing of _
• [x] Option to disable parsing of *
• [x] Option to disable rendering of emphasis
• [x] Option to disable rendering of strong
• [x] Tests

Is this something you would be open to taking into core? If so, I'll write some tests for it. (Any suggestions for how the tests should be organized?)

My use case is that I need custom renderers for images and depending on the image URL, these renders will render the image as an iframe for YouTube, Vimeo, etc. At present I use the Sundown renderer and I have stuffed all these renderers into one big file but would like to move over to this lib and cleanup the mess while I'm at it.

I also imagine that a lot of contributors can then share their own YoutubeRenderer (or generic VideoRenderer). This would make extensibility a lot more fun and build an ecosystem around it. Maybe even give way to an extensions repo.

Based on your suggestion in #32, I currently render my custom Renderer as

$environment->addInlineRenderer('League\CommonMark\Inline\Element\Image', new MediaRenderer());

However, this only allows attaching a single renderer. It would be nice if the renderer can work sort of like conventional event handlers with the possibility to either chain the output as input to other renderers or stop propagation. The easiest approach would be to have symmetric input/output for renderers that would make chaining a breeze. Currently the input/output is (AbstractInline, HtmlRenderer)/HtmlElement.

Description I'm implementing a Jira ticket format parser as an InlineParserInterface. I think I'm in the ballpark, but I've stumbled with this: I can't apply the transformation if the ticket name is between backticks, and I think the reason is that backticks are implemented as InlineParserInterface too.

If I'm understanding the docs, backticks would be ideally implemented as DelimiterProcessorInterface:

• Do you think it would be reasonable to allow transformations to happen inside backticks?
• It would be a problem in terms of backwards compatibility?
• I think I could try to make a PR. I'm still not familiar with this package internals, so I would do my best.

Example

test FOO-123 <!-- this will output 'test <a href="https://foo.atlassian.net/browse/FOO-123">FOO-123</a>' -->

`test FOO-123` <!-- this will output '<pre>test FOO-123</pre>' -->

Did this project help you today? Did it make you happy in any way?

Of course. This is allowing me to do a cool view of our changelog for our non-programmer co-workers! I'm very thankful to have such control over the parsing, and I would love to contribute back if I can.

Given that this project has now consolidated a ton of these rando extensions into itself, I think the last two remaining popular extensions should follow suit:

• [x] https://github.com/webuni/commonmark-attributes-extension
• [x] https://github.com/rezozero/commonmark-ext-footnotes

x-ref: https://github.com/rezozero/commonmark-ext-footnotes/issues/7

Not that this really needs any explanation, but for posterity sake I suppose: https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/

Description

I would like to customize the extension https://commonmark.thephpleague.com/2.3/extensions/attributes/ so that you can limit the attributes of the user by configuration. Currently I give the user too much freedom once the extension is activated because e.g. I only want the user to be able to set values for bootstrap pull-left as class.

If restricted is true (default: false that there is no BC), then only the keys in the configuration are allowed. If false, then only the values of the specified keys are restricted.

Example

'attributes' => [
    'restricted' => true,
    'class' => ['multiple value', 'allowed'],
    'id' => 'allowed_value',
    'title' => function ($value) {
        if (strlen($value) > 10) {
            return true;
        } else {
            return false;
       }
    },
    // Allow the key and accept any value in case the restricted is true
    'font' => null,
]

Did this project help you today? Did it make you happy in any way?

No response

Version(s) affected

2.3

Description

In RTL languages the smart punctuation should be reversed so 'رہیں' generates ’رہیں‘ instead of the desired ‘رہیں’.

It's possible to change up the config to reverse the open/close but language detection (especially for bilingual setups) would be very useful.

I really liked how v1 had no external dependencies. In v2 we opted to pull in some dependencies instead of reinventing the wheel. I think this was a good decision, but do we truly need everything in that dependency tree? Maybe yes, maybe no. Let's explore if it's reasonable to reduce that footprint in any ways that don't negatively impact users or maintainers. (We don't want to just remove things for the sake of removing things). This way involve some major-version-level changes to league/config as well.

We'll either confirm that we have exactly what we want/need, or we'll find areas to make small improvements.

There are several rendering-related ideas I'd like to explore for v3:

• [ ] Avoiding recursion (parsing and AST iteration already avoid recursion)
• [ ] Using an OutputWriter object
• [ ] Investigate performance of writing to a php://memory stream instead of concatenating strings
• [ ] Allowing renderers to determine what to render (à la Symfony's NormalizerInterface) so that renderers could potentially handle multiple node types without needing to tell the Environment in advance
• [ ] Better support for multiple render formats (html, md, xml)

Whether these actually get implemented will depend on how the testing goes.

#419 and #511 require the ability to render the AST to Markdown. If we also add the ability to parse HTML into the AST then we could replace league/html-to-markdown with this package! Using an intermediate AST would also help with some of the issues/challenges in the other library.