The generic directive syntax, being wholly new, does not have this semantic incompatibility problem. Reusing any existing syntax for semantically incompatible purposes is definitionally a breaking change. This is backwards incompatibility and a step away from interoperability. That is, by choosing this syntax, GitHub will cause other renderers to yield semantically incorrect output. They will continue to render the block as a, per Commonmark semantics. GitHub can alter its implementation to instead use a in this special case, but this does not solve the problem for renderers which do not implement this extension. The currently implemented syntax results in Markdown files which are backwards incompatible with other/older renderers, while the alternatives suggested here do not.Īs others have pointed out, using the element for this contradicts the semantic meaning of the element. I'm wondering how everyone feels about the fact that it would potentially break backwards compatibility? Almost every markdown render engine can do at least the basic render of whatever comes between the open and close of the block and the more sophisticated ones support specifying a language variant immediately after the opening blocks. I think this is the most flexible (should support a wide number of future usecases!) and also the most backwards compatible. Off of the top of my head, these plugins: The obsidian community has (at least partially) settled on triple backticks for this. It precisely prevents the need to increment syntax.īeta Was this translation helpful? Give feedback. I don’t see the need for parity, which is indeed impossible, when there is a syntax for these custom things. Given that there are already some solution out there, would we ever reach a point of parity or would we just increase the Markdown rendering clutter I envision that unknown directives can be either: a) displayed somewhat similar to how YAML frontmatter is displayed, so that their name and attributes are displayed, b) replaced with their contents, similar to how unknown HTML tags are stripped Once they would support the concept of generic directives it still requires to adopt the exact pattern and render it accordingly to achieve the same meaning. And I prefer going with standards, and as far as I know generic directives are supported in many places already and most likely to become that. I see a need for an arbitrary “component” syntax, to quell the ever growing need to add things. That is why, while I quite like the Obsidian syntax, and also quite like the current proposal, keeping on adding things just makes markdown like AsciiDoc, and AsciiDoc is already the best AsciiDoc out there. And humans will have other custom needs for their markdown too.
This is not the first nor the last feature GitHub adds. The inverse is also true: the things GitHub implements, are “forced” upon other markdown parsers due to the sheer popularity of GitHub. Markdown files are rendered with different Markdown parsers outside of GitHub that won't support that syntax to begin with Which is all the more reason to do it properly, ask the community for feedback ( 👍), and work with existing proposals. GitHub, by introducing a syntax, will change some readmes. Noteworthy, this has not prevented a) GitHub rebasing GFM on top of CommonMark, b) the recent additions of diagrams, footnotes, and math. I'm wondering how everyone feels about the fact that it would potentially break backwards compatibilityĪny change to markdown introduces those: as any character is valid markdown, turning them into constructs is breaking.
0 kommentar(er)
