[Consolidated proposal] Features to deprecate

[joshbruce]

Over the years the community has added features to Marked based on issues and user feedback; while not always a bad thing, sometimes it can cause a project to go beyond sustainable scope for itself (as we kinda saw). To try to rein things back in a bit, there are some features we may want to deprecate because they take Marked beyond its intended scope; thereby, making it more difficult for a small band to maintain.

This Issue is for capturing those suggestions, which will most likely be implemented during the 0.5.0 and beyond releases:

• ??

Use comments to discuss, will update the task list as we gain consensus and whatnot...that way we don't add too many issues that are future-planning.

[joshbruce]

Think we should deprecate header ids being handled by Marked. I don't think any of the supported flavors of specifications actually has this functionality and it's something that can be better performed as a secondary pass on the DOM, in my experience. Also, could be something a user could add as extended functionality to reduce our maintenance overhead.

Tagging @UziTech and @Feder1co5oave to make sure y'all see the ticket.

[Feder1co5oave]

My vote goes to deprecate the pedantic option 😆
I know chjj was in love with it, but it just doesn't make sense now that we have commonmark. Would be curious to see how many users actually enable it.

[joshbruce]

That's fair re pedantic. I don't know how many people know the Daring Fireball spec is even still out there. How different is it from CommonMark though?? Don't we get most of it "for free" by virtue of having CommonMark. Might be an extend + override path.

Pedantic = All these properties
CommonMark = Has Pedantic + these properties - these Pedantic properties.
GFM = Has CommonMark + these properties.
MultiMarkdown (this is totally made up at this point, just an example) = Has GFM

Know what I mean??

[Martii]

@joshbruce

Re:

Think we should deprecate header ids being handled by Marked.

I believe we currently utilize extending header ids to our own flavor for easier document traversal.

Will we be supporting syntax highlighting of languages such as c or r?

We have the ability to utilize the full compliment of languages however most ppl use js and diff (sometimes it automatches on html and css which is utilized as well). We match GitHubs implementation as close as possible which includes other identifiers of that nature.

[joshbruce]

Hey @Martii thanks for showing up!

Just to make sure I'm following, don't think we've interacted much, so pardon the bumps in communication, really glad to see a new face (though I feel like I should know you...been a lot of peopling for me recently, sorry).

we currently utilize... and We have the ability to utilize

https://openuserjs.org or are you taking on the voice of the marked community ?? (perfectly cool if you're taking on the voice of the community, I sometimes take on the voice of products...just wanna make sure I'm following the pronouns) 😉

own flavor for easier document traversal

Own flavor of Markdown or own flavor of marked?? We have a lot of forks that stand as separate products but credit marked as the inspiration.

(I guess what I'm asking is, would deprecating this feature break something for you and your users because you are dependent directly on marked...or is this a rationale for not deprecating...or something else entirely?)

We match GitHubs implementation as close as possible which includes other identifiers of that nature.

Again, just want to make sure I'm fully tracking you here. Are you saying you match the expected behavior based on using GitHub's text editor, saving, and how it is rendered on the final page? or, are you saying you follow the specification itself (https://github.github.com/gfm/)?

[Martii]

@joshbruce

Are you saying you match the expected behavior based on using GitHub's text editor, saving, and how it is rendered on the final page? or, are you saying you follow the specification itself (https://github.github.com/gfm/)?

These almost go hand in hand... so towards the goal of both.

https://openuserjs.org or are you taking on the voice of the marked community ??

Again a little bit of both here... messenger only from observation... I would have to say more towards forum i/o. Our establishing owner initially built his own software even before most packages existed to bridge any gaps that currently exist between forum software and non-forum software. He and his initial founding teams established a set of extending methods of this package marked and I'm the active maintainer (and co-owner since I have a bit of wisdom behind me I believe). One contributor went the exact opposite methodology and I'm somewhere in-between using custom versus outsourcing discrete methods such as marked.

Own flavor of Markdown or own flavor of marked?

Just extending existing methods for right now. We utilize this packages npmjs.com address for npm i but we do define some custom functions that we'd like to keep.

As I mentioned at an earlier point about a month ago we've been investigating alternatives to marked (Note: I always put packages in emphasis and use markdown and markup as respective counterparts) but prefer to keep the status quo on such a critical feature for communication and security (we have a term that all code must be blocked/fenced for example which most ppl follow)

As Code usually speaks better than explanations (especially when different terminology that means hopefully the same thing comes into play) our current extendings are at https://github.com/OpenUserJS/OpenUserJS.org/blob/master/libs/markdown.js . I've put most additional features on hold/tracking since there are some other technical issues with how our system runs but in general it works well for us. These extensions (which should be well commented and named for easier skimming) are what we currently utilize. Bringing up the c code fence coercion again... if that goes for some reason that's not something I'd like to see be removed. e.g. one never knows what "progress" will bring. Adaptability is a goal when a package is chosen along with how well the maintainers interact with others. (no ones perfect but there can be consistent good and consistent bad... this project case is consistent good from what I've observed so we prefer to continue here :)

I do understand the need to compartmentalize and modularize though for easier systems management but having the current feature availability present is a plus. Sometimes progress moves too quickly without gauging all the consequences ... a factor of knowing wisdom over knowledge/intelligence. (dating myself of course here ;)

Hope some of this explains our wishes for this issue and answers your questions.