See branch: rosuav/markdown-attribute-syntax
There's a not-very-well-known syntax supported by some Markdown parsers (including GitHub Flavored Markdown) that allows HTML attributes to be attached to a paragraph of text:
Text goes here blah blah blah {: someattr=value otherattr=otherval}
This is extremely handy for making small adjustments to the display of something, particularly with shorthands for class and ID, for use in CSS:
{: .someclass} {: #someid}
However, it's not well documented and I can't find a standard anywhere for it.
It is something that I personally would find extremely useful, and am currently implementing by subclassing the Markdown module and tweaking the parser.
Would anyone else find this of value? Conversely, would anyone find that this causes issues?
ChrisA
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?
Bill
On Apr 7, 2020, at 2:44 AM, Chris Angelico rosuav@gmail.com wrote:
See branch: rosuav/markdown-attribute-syntax
There's a not-very-well-known syntax supported by some Markdown parsers (including GitHub Flavored Markdown) that allows HTML attributes to be attached to a paragraph of text:
Text goes here blah blah blah {: someattr=value otherattr=otherval}
This is extremely handy for making small adjustments to the display of something, particularly with shorthands for class and ID, for use in CSS:
{: .someclass} {: #someid}
However, it's not well documented and I can't find a standard anywhere for it.
It is something that I personally would find extremely useful, and am currently implementing by subclassing the Markdown module and tweaking the parser.
Would anyone else find this of value? Conversely, would anyone find that this causes issues?
ChrisA
On Wed, Apr 8, 2020 at 1:04 AM H William Welliver william@welliver.org 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
On Wed, Apr 8, 2020 at 1:12 AM Chris Angelico rosuav@gmail.com wrote:
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.
Is there any interest in this feature? Conversely, are there any objections? It's almost 100% backward compatible (the chances that someone would have an attribute block that is actually meant to be text are very low), and it's a very helpful way to add a bit of styling to something while still basically being Markdown.
For details see branch: rosuav/markdown-attribute-syntax
ChrisA
While I'm indifferent to markdown itself, my problem with the markdown implementation in Pike is that it was implemented as an application with no programmatic way of controlling its behavior. That's why we moved it into the Tools module. A proper markdown module should be easy to extened and control from code.
pike-devel@lists.lysator.liu.se
-
Chris Angelico -
H William Welliver -
Martin Nilsson (Coppermist) ＠ Pike (-) developers forum