Add target_blank to RenderOptions for links

[haylinmoore]

No description provided.

[kivikakk]

Hi there! Thanks for this contribution, it's very tidy.

I'm just a little hesitant to accept adding an option for this purpose. I kind of feel that this kind of manipulation/transformation should be done outside a Markdown processor, rather than adding an option for each user's usecase.

When we see this kind of request in similar libraries in Ruby we tend to suggest postprocessing, especially since there's a pretty low threshold of different things you want done to your document post-Markdown before it becomes worth postprocessing anyway. What do you think?

In other words: what you're doing now honestly looks ideal to me, from an API designer point of view, but I'm missing the API user point of view and that's you. In light of the above, I'll happily add if you're happy to reaffirm this is what you want!

[digitalmoksha]

@kivikakk I tend to agree with you for these types of manipulations. I'm well aware of all the little things that can be done with post-processing. We add target as well during post-processing, as well as about 25 other things.

I do have a question for you: which is going to be faster? Is it better to use something like kuchiki or maybe selma - convert the comrak HTML into another tree structure and operate on that and reconvert to HTML? Or take comrak's AST and either add information into the AST and pass to the standard HTML writer, or some combination of AST manipulation and a custom HTML writer?

[kivikakk]

It would indeed be faster to such things in Comrak; reparsing the HTML and constructing a new tree is (relatively) expensive. But I would heavily weigh up the complexity that would be added in service of such performance against the actual gains. Unless you get to a very high level of throughput, you will simply not notice the difference in speed or compute. You would notice the difference in a clunkier API, i.e. feeling like you're restricted by the fact that you want to do arbitrary DOM transformations without something that understands the DOM at all.

(imo, if that level of performance was truly a concern, you'd probably use something with streaming output, rather than building up an AST.)

[digitalmoksha]

feeling like you're restricted by the fact that you want to do arbitrary DOM transformations without something that understands the DOM at all

Yeah that makes a lot of sense. No sense hamstringing yourself unless you really have to.

[kivikakk]

No response from the author in over a month so I'm closing!