On Wed, Apr 8, 2020 at 1:04 AM H William Welliver <[email protected]> wrote: > > Hi Chris- > > I haven’t looked at your branch (yet). Given that there are a number of > popular extensions to Markdown, perhaps rather than having a number of > different classes, we could have a flag that enables the various extensions > we support? That way, it would not inadvertently break things for folks who > weren’t expecting those syntaxes? >
Yes, agreed - I mentioned subclassing only because that's how I can add functionality without actually adding it to core, but it's definitely not something I'd want to do. (For technical reasons, I actually had to subclass the entire module. It works but it sure ain't pretty, hence this proposal.) With the proposed enhancement, it's governed by the flag "attributes" - set it to 1 to get the new functionality (otherwise an attribute block will be seen as just another paragraph of text). If there's actually a standard with a well-known name (which I couldn't find), I'd be fine with renaming this to something else, in the same way that a bunch of changes are governed by the flag "gfm" (Github Flavored Markdown). Flags are definitely the way to go here. ChrisA
