Markdown within block-level elements

Sun Sep 21 11:18:48 EDT 2014

Part of the argument against new Mark* packages is the further
fragmentation of the MD niche.

And this potentially breaks things when Flavour A is replaced with New
Improved Flavour B.

What if there is a configuration file that makes new implementations bug
compatible with The Original Markdown?

Now what happens:

1.  A package can be called Markdown Compatible if, with the choice of a
suitable config file it can produce the same results as the Original
Markdown.  This file should be provided by the implementor.

2.  A package can be called Common Mark Compatible, if , with the choice of
a suitable config file it can produce the standard Common Mark test
results. Also should be provided.

3.  A package owner could claim Common Mark compatible (Or MD compatible)
except for Foo.

4.  If there is a consensus of how to manage change, then periodically we
have Common Mark YEAR with a new standard of what it means to be Common
Mark compatible.

In this way new features can be created by those who need them but for a
new feature for anything that wants to be MD or CM compatible there is a
three value config item that can enforce CM, MD or My Special New Heart's
Desire.

Fortran was a mess for years.  Every compiler maker added features and
options, and we had galloping featuritis.  (No creeping...)  With Fortran
77 and later Fortran 95(?) standards were hammered out as to how the
language should behave.

I see being MD compatible as the equivalent of F77, and Common Mark being
the later F95

Respectfully,

Sherwood of Sherwood's Forests

Sherwood Botsford
Sherwood's Forests --  http://Sherwoods-Forests.com
780-848-2548
50042 Range Rd 31
Warburg, Alberta T0C 2T0

On 20 September 2014 08:21, <jakov at gmx.at> wrote:

> Fletcher wrote:
> >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.
>
> I agree very much. But I think that you take the what-ifs too serious.
>
> If you reconsider *only* my first idea: "<div markdown=...>" with values
> "off", "on" and "all" in my opinion you gain a lot of flexibility and also
> move towards common features.
>
> Does the markdown attribute in mmd go deep into the structure? Eg. Is
> there a difference between <div markdown=1>etc and <div>etc plus
> process-HTML command?
>
> A markdown=0 attribute would indeed suffice to inhibit what the process
> HTML command started.
>
> Jakov
>
>
> On 20. September 2014 15:44:34 MESZ, "Fletcher T. Penney" <
> fletcher at fletcherpenney.net> wrote:
>>
>> 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
>>
>>
>> ------------------------------
>>
>> Markdown-Discuss mailing list
>> Markdown-Discuss at six.pairlist.net
>> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>>
>>
> _______________________________________________
> 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/20140921/43655c14/attachment.html>