Timothy Leverett

@pid Thanks for the response. I've already been using the `{custom:...}` solution, but I figured I'd call out the possibility for improvement around this feature.

It looks like the regex used to parse metadata is greedily matching to the last colon when a non-greedy match should be used instead: https://github.com/showdownjs/showdown/blob/95255984ad80acf745ed74605bd3ad8357dc9b33/src/subParsers/makehtml/metadata.js#L31 ```js /^([\S ]+): +([\s\S]+?)$/gm.exec('title: Lorem:...

Navigating to a document is a link behavior. Not all modals are stand-alone documents, but in my very specific case it is, and I need to perform some non-default functionality...

Please don't pin on the specifics of opening a modal for this issue. It's just a single example of why I feel `` is not well behaved. There are a...

@rlivsey per the spec, [anchors may not have interactive descendants][1], so I'd recommend taking a different approach for that particular issue. Years ago I used to be a proponent of...

I think the proposal has merit, however I noticed that the API is somewhat unusual: > `elementInternals.type` should only be set once. If `elementInternals.type` has a non-empty string value and...

> If we break up the features and support them individually on `ElementInternals`...developers will not have a way to get all the behaviors of a built-in at once. Bitwise flags...

> I'm wondering if that makes it hard to customize the `type` based on the custom element's attributes? Either version of the proposal would make that approach impossible/inadvisable due to...

These sorts of questions can be hard to answer because experienced programmers will look at the API and say "_of course_ it's organized like this, _that's just how it's done_."...