Markdown within block-level elements
Fletcher T. Penney
fletcher at fletcherpenney.net
Sat Sep 20 09:44:34 EDT 2014
While I think Gruber has taken his "don't f### with it" stance towards Markdown a bit far by refusing to fix bugs over the last 10 years, I agree that part of what makes the Markdown concept (as distinct from the Markdown.pl implementation) great is that he didn't throw everything but the kitchen sink into it.
I may not agree with exactly where he set his feature threshold (e.g. not including the syntax for footnotes that seemed to be his idea), but I agree with the concept of being pretty strict on not adding new features.
The new features I have added to MMD in the last year have either been improvements on existing features (e.g. file transclusion is better than the old mmd_merge approach) or new features that I added only after **years** of requests for them and thinking about them (e.g. fenced code blocks -- and for technical reasons I'm still not entirely convinced this was a good idea).
I understand that new features would be useful for **some** people, but the important part is whether they would be useful for **most** people.
I don't believe this concept passes that test (and keep in mind that the users of this list are not a representative sample of Markdown users). It adds something that is rather complex (both in terms of syntax for users and new demands on parsers) that has a large payoff for the few, but no payoff for the many. In my opinion, this is antithetical to the expressed philosophy behind Markdown.
The question is not whether it is technically feasible (I'm quite confident I'm smart enough to figure out how to do it ;), but whether it is desirable.
F-
--
Fletcher T. Penney
fletcher at fletcherpenney.net
On Sep 20, 2014, at 6:15 AM, jakov at gmx.at wrote:
> Fletcher, how does MMD treat HTML elements? Does it just ignore the tags (possibly breaking the HTML) or does it parse the content of each element separately after identifying it as an element, eg. through recursion?
>
> If it is the latter, then calling the function with a markdown=on/off/all shouldn't be too complicated I guess.
>
> Head, code and pre could (instead of adding the complicated exclusion tag thing) just be excluded by default. Or instead have markdown="all" and markdown="intelligent" where the latter excludes the elements that usually don't make sense. But even this is only needed for convenience! Demanding the user to add a markdown=0 tag to the elements she wants to exclude should normally suffice.
>
> Regards, jakov
>
> On 19. September 2014 19:24:22 MESZ, "Fletcher T. Penney" <fletcher at fletcherpenney.net> wrote:
> I think my head just exploded.
>
>
> I speak for no one but myself, but I don't anticipate adding anything
> this complex to MultiMarkdown.
>
> MMD already enables a feature to turn on processing of Markdown inside
> all HTML, and I suspect that's as far as I will go with it.
>
> FTP
>
>
>
> On 9/19/14, 1:21 PM, jakov at gmx.at wrote:
> Good point. I'm not sure of it would be a good idea to add something like the following, but it could be a solution:
>
> <HTML markdown="all" markdown-exclude="head code pre #my-id . non-markdown-class">...</HTML>
>
> Regards, jakov
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20140920/a075c004/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4903 bytes
Desc: not available
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20140920/a075c004/attachment.bin>
More information about the Markdown-Discuss
mailing list