Re: Markdown within block-level elements

[Fletcher T. Penney]

On 9/20/14, 10:21 AM, ja...@gmx.at wrote:

Does the markdown attribute in mmd go deep into the structure? Eg. Is
there a difference between etc and etc plus
process-HTML command?


The `` does not recurse into nested HTML constructs 
(unless they also specify `markdown="1"`).  The command line option does.



F-

--
Fletcher T. Penney
fletc...@fletcherpenney.net
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[Sherwood Botsford]

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,  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: "" 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 etc and 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" <
> fletc...@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
>> fletc...@fletcherpenney.net
>>
>> On Sep 20, 2014, at 6:15 AM, ja...@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

Re: Markdown within block-level elements

[jakov]

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: "" 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 etc and 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" 
 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
>fletc...@fletcherpenney.net 
>
>On Sep 20, 2014, at 6:15 AM, ja...@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"
> 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, ja...@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:
>> 
>>  ...
>> 
>>  Regards, jakov
>> ___
>> Markdown-Discuss mailing list
>> Markdown-Discuss@six.pairlist.net
>> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>
>
>
>
>
>___
>Markdown-Discuss mailing list
>Markdown-Discuss@six.pairlist.net
>https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[Fletcher T. Penney]

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
fletc...@fletcherpenney.net 

On Sep 20, 2014, at 6:15 AM, ja...@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" 
>  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, ja...@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:
> 
>  ...
> 
>  Regards, jakov
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[jakov]

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" 
 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, ja...@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:
>>
>> ...
>>
>> Regards, jakov
>
>-- 
>Fletcher T. Penney
>fletc...@fletcherpenney.net
>___
>Markdown-Discuss mailing list
>Markdown-Discuss@six.pairlist.net
>https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[mofo syne]

somehow I think it might be easier to declare 'classes' and 'id' to use markdown

e.g.

!settings

EnableAll: yes

Include:

Exclude:
   head
   code
   pre
   #my-id
   . non-markdown-class

!

On Sat, Sep 20, 2014 at 3:21 AM,   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:
>
> ...
>
> Regards, jakov
>
>  Sherwood Botsford  wrote:
>>I find that my usage is tag dependent.  In general I want markdown:
>>
>> on
>>  off
>> on
>> on
>> on
>> off
>> off
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[Fletcher T. Penney]

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, ja...@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:

...

Regards, jakov


--
Fletcher T. Penney
fletc...@fletcherpenney.net
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[jakov]

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:

...

Regards, jakov

 Sherwood Botsford  wrote:
>I find that my usage is tag dependent.  In general I want markdown:
>
> on
>  off
> on
> on
> on
> off
> off
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[Fletcher T. Penney]

On 9/17/14, 5:46 PM, Alan Hogan wrote:

I just wanted to share a few short observations regarding Markdown within 
block-level elements, which I (and the Common Mark project) wish to be enabled 
by default.

1. I believe this to be a very desirable feature for writing Web content. (See 
item #6 for specific motivation. Generally and intuitively, I expect everything 
in my markdown document to be subject to Markdownification, with the exception 
of indented, fenced, or back tick-delimited code and content within (not 
between!) HTML tags. )


I’m not sure that everyone shares your expectations.  I expect HTML to 
be left alone unless I specifically say otherwise.


As for Markdown per se, the decision is Gruber’s.  As for everything 
else, that’s the beauty of open source — if you don’t like what exists, 
create your own.  The necessary downside to this is the Tower of Babel 
effect where different “Markdown variants” are not equal to each other.



2. If your parser/converter does allow this, *please* make sure it is HTML5-aware. There should 
not be this much difference between a  and a .  Just look at how many 
implementations consider  to be plain text, wrapping it in paragraph tags!

   <http://ajh.us/bbmk-title-in-div>
   vs
   <http://ajh.us/bbmk-title-in-header>


This is where robust test suites are helpful.  In my mind, the most 
valuable part of the Common Mark effort thus far is a robust test suite. 
 The problem is that the test suite doesn’t differentiate between 
*fixing* Markdown (e.g. the known bugs and inconsistencies) and 
*changing* Markdown (e.g. rewriting the rules and expectations into 
something different).  This means that authors of other tools (e.g. me) 
have to dig through 100’s of “failed” tests to see which ones are true 
failures and which ones are differences of opinion.




3. Michel Fortin came up with a clever solution to allow this at authors’ 
discretion way back when, but it is not popular, and most other flavors ignore 
the markdown=“1” flag altogether. It is usually echoed into rendered HTML by 
other flavors. It is One More Thing for an author to memorize, so I don’t love 
the writing experience with it, either. I would like to see Markdown within 
block-level elements to be the default.

   <http://ajh.us/bbmk-title-in-header-extra>

4. This won’t be a surprise to anyone, but the differences between flavors here 
is causing me real problems as an author. I am currently writing in iA Writer, 
previewing with Marked, managing changes with GitHub, and publishing with PHP 
Markdown Extra. Naturally, these all give different results, decreasing (a) my 
confidence as an author and (b) the utility of Markdown, since I am forced to 
write more raw HTML to get consistent and desirable output.



The more you use tools that deviate from Markdown, by definition the 
more this will happen.  MultiMarkdown and PHP Markdown Extra both 
support this feature, so three of the four tools you mention should 
support this feature — though it may be limited to the iA Writer Pro 
version only according to their website?


http://support.iawriter.com/help/kb/general-questions/how-can-i-preview-markdown

If GitHub Flavored Markdown doesn’t support this feature, it would seem 
to be a reasonable feature request, and then this would work everywhere 
for you.




5. Look for Common Mark, a.k.a. “stdmd 0.1”, in Babelmark.

   <http://ajh.us/bbmk-title-in-header>

   Note that it gets the output right: It interprets the  tags as 
block-level tags inside of which I wrote more content. The only other packages to do 
so were Haskell markdown package 0.1, cheapskate 0.1, and pandoc 1.13.



Again “right” is a subjective term here.  It’s only right if you’re 
using the CommonMark syntax.  If you’re using Markdown, then some of 
what you call “right” is actually “wrong.”  But if you prefer the 
CommonMark approach, then by all means continue to use it.  That’s the 
beauty of choice.




6. For those curious, the reason I want to wrap an  and a  inside of a 
 is that, with the removal of , it arguably remains the best way to 
semantically represent some instances of the “subtitle” concept HTML never really provided for. It’s a 
pattern recommended in the HTML5 standard.

Thanks for your consideration.
Alan Hogan
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss



--
Fletcher T. Penney
fletc...@fletcherpenney.net
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[Sherwood Botsford]

I find that my usage is tag dependent.  In general I want markdown:

 on
  off
 on
 on
 on
 off
 off

The various table MD extensions mean that I almost never use a table tag
anymore.

My div tags allow me to unobtrusively put some page structure with css
classes into my documents.  My average page has about 10 structural divs in
it.  It's a nuisance and an eyesore to turn on markdown in each one.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[Aristotle Pagaltzis]

* ja...@gmx.at  [2014-09-19 13:15]:
> For easy copy pasting, backwards compatibility etc (as others just
> pointed out), markdown=0 should imo be default for any HTML element.
> As in PHP markdown, let markdown=1 interpret inline stuff inside that
> element.
>
> Then let markdown=2 make the child element inherit markdown=1 and so on, eg.:
>
> 
> Inline markdown *here*.
> .first level child: markdown is *on*
> ..second level child: markdown is off again.
> ..
> .
> 
>
> So the concept is, that the number given will be counted down before
> inheriting it.

I think there is a Markdown converter that supports something like that
already. I saw someone mention it on this list a while ago, anyway. It
seems like a smart solution.

> Markdown=all (or similar) would inherit through all levels. To escape
> inheritance, put markdown=0 there again.

That one I hadn’t seen before. Makes a lot of sense too.

> To simplify things, one could also leave out the counting down thing
> and only have three States: off, on*, all levels*.

That’s certainly how you want to introduce it in the syntax description.
I’m not sure if it would cover enough ground without supporting counted
levels. Still, you don’t lose any use cases by not supporting them, you
just make some documents more noisy. So the best approach is probably to
just try the simple form and see if you miss counted level support.

> If you want to have an all markdown document, wrap it into an element
> with markdown=all (or all-block). However, there might be situations
> where you don't want to output any extra element; I'm not sure whether
> a pseudo-element like  (or  ?) would be
> a good solution to this.

In the spirit of “the simple form is probably enough” I would just punt
on that.

Great, now you just need to convince some sufficient number of Markdown
converter authors/maintainers to support this extension. :-)

Regards,
-- 
Aristotle Pagaltzis // 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[jakov]

>The rule allows you to retroactively introduce Markdown to any system
>that was designed to handle HTML, without breaking any existing
>content.

> ... [further good reasons for this rule]

May I toss in an idea (I'm not sure if I stumbled upon it or thought it up 
myself):

For easy copy pasting, backwards compatibility etc (as others just pointed 
out), markdown=0 should imo be default for any HTML element. As in PHP 
markdown, let markdown=1 interpret inline stuff inside that element.

Then let markdown=2 make the child element inherit markdown=1 and so on, eg.:


Inline markdown *here*.
.first level child: markdown is *on*
..second level child: markdown is off again.
..
.


So the concept is, that the number given will be counted down before inheriting 
it.

Markdown=all (or similar) would inherit through all levels. To escape 
inheritance, put markdown=0 there again.

To simplify things, one could also leave out the counting down thing and only 
have three States: off, on*, all levels*.

(* php markdown extra intelligently doesn't produce block elements where 
inappropriate, e.g. inside an inline element and therefore has an additional 
"block" feature, 
seehttps://michelf.ca/projects/php-markdown/extra/#markdown-attr; this should 
also be applicable as "all-block")

If you want to have an all markdown document, wrap it into an element with 
markdown=all (or all-block). However, there might be situations where you don't 
want to output any extra element; I'm not sure whether a pseudo-element like 
 (or  ?) would be a good solution to this.

Just an idea, I'd really like to hear your thoughts on it.

jakov___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[Aristotle Pagaltzis]

* Alan Hogan  [2014-09-18 03:10]:
> I do not understand why the rule existed in the first place.

Which implies that it must not make sense?

The rule allows you to retroactively introduce Markdown to any system
that was designed to handle HTML, without breaking any existing content.
And if the Markdown processor needs to be jammed at multiple different
layers, you can do that, because the HTML rendering of a Markdown source
is always wrapped in block-level elements, so you can pass the output of
a Markdown converter back through it (or through another converter, if
you happen to be stacking plugins in a CMS, say) without destroying it.

Without the rule, you would have to choose between Markdown and HTML.
The rule makes Markdown embrace-and-extend.

> Break things. Bump the major version. Be part of an ecosystem that
> actually works.

Markdown is Gruber’s and not anyone else’s. There is no “ecosystem”
about that.

Regards,
-- 
Aristotle Pagaltzis // 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[Michel Fortin]

Le 17-sept.-2014 à 21:07, Alan Hogan  a écrit :

> On Sep 17, 2014, at 4:57 PM, Michel Fortin  wrote:
> 
>> I'll just point out that the markdown="1" trick should be credited to John 
>> Gruber.
> 
> Thanks. Sorry for getting that wrong.

It's normal to get it wrong. I wrote the first implementation in an 
experimental branch of PHP Markdown, John [suggested a syntax][1] different 
from mine, I adopted it. The experimental branch later became PHP Markdown 
Extra.

[1]: http://six.pairlist.net/pipermail/markdown-discuss/2004-August/000669.html 
"
Syntax: Markdown processing within block-level HTML"


>> CommonMark interprets it "right" according to your intent, but the Markdown 
>> spec by John Gruber is very explicit about block-level HTML elements:
> 
>> I think the spec makes it clear that the content of `` should not be 
>> parsed with the Markdown syntax. As for whether the spec is right or wrong 
>> in that choice, that is another debate entirely.
> 
> Indeed. To be clear, I am aware of Gruber’s rule (although I forget it from 
> time-to-time as an author), and was hoping to provoke some discussion with 
> the aim of, yes, rallying around the Common Mark decision here. 
> 
> I do not understand why the rule existed in the first place.
> 
> Apart from historical reasons, are there other good reasons to avoid Markdown 
> processing within block-level elements?

I can't find the reference, but if I remember right the idea was that HTML 
blocks would often be copy-pasted snippets for embeded videos or similar 
things. In other words, if you paste some HTML in the middle of your text, you 
likely don't want Markdown to interfere with it, it should just work.


> And as far as those historical reasons go, I hope it’s abundantly clear how 
> very silly it is for a hundred non-interoperable implementations to claim the 
> motivation of “compatibility" to shun the change needed for consensus.
> 
> Break things. Bump the major version. Be part of an ecosystem that actually 
> works.

PHP Markdown adheres as much as possible to what John Gruber intended Markdown 
to be, based on the spec as well as the code and comments in Markdown.pl, plus 
all the posts John has made while he was still participating on this list and a 
few private emails here and there.

The Markdown Extra variant adds some features and makes only one very small 
breaking change (disallowing middle-word underscore emphasis). Even though the 
most notable features in it have been praised by John (on this list), I feel 
"Extra" needs have a distinct name to signal that it's not purely Markdown.

If I write another parser that breaks a few more things (for instance if it 
implemented CommonMark), I'll use a new name to avoid the confusion while 
keeping the old parser around for those who needs it. That however wouldn't 
solve the problem of non-interoperable Markdown implementation unfortunately, 
it'd just create one more parser.


-- 
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[Waylan Limberg]

> On Sep 17, 2014, at 9:07 PM, Alan Hogan  wrote:
> 
> 
>> I think the spec makes it clear that the content of `` should not be 
>> parsed with the Markdown syntax. As for whether the spec is right or wrong 
>> in that choice, that is another debate entirely.
> 
> 
> Indeed. To be clear, I am aware of Gruber’s rule (although I forget it from 
> time-to-time as an author), and was hoping to provoke some discussion with 
> the aim of, yes, rallying around the Common Mark decision here. 

As far as I am concerned, CommonMark is not Markdown -- more like a (much) 
younger sister. So when we are talking about Markdown, the behavior of 
CommonMark has no bearing on the matter IMO. Until Gruber changes the rules, 
those rules describe the only thing that is Markdown.

In fact, Babelmark has become completely useless to me now that it includes the 
output of CommonMark. I can't point users at Babelmark and say "that's the way 
they all do it." And of course, when debugging my implementation, now I have to 
separate the actual Markdown parsers from the non-Markdown parsers every time 
I'm comparing behaviors.

To be clear, I like a lot of things about CommonMark. Personally, I would take 
changes a little further and call it "inspired by Markdown." I look forward to 
when it grows up and can be a true sister to Markdown.

> 
> I do not understand why the rule existed in the first place.
> 
> Apart from historical reasons, are there other good reasons to avoid Markdown 
> processing within block-level elements?

Ever have something that you don't want parsed as Markdown text, but you also 
don't want inside a `` tag (a math equation that will get processed by 
JavaScript in the browser comes to mind)? Wrapping it in a `` tag is the 
easiest way to do that. Straightforward  and simple. Or how about when you 
paste in some carefully crafted HTML, like a `` or `` element? You 
definitely don't want Markdown parsing that. With the current default behavior, 
you never have to worry. 

Yes, I think CommonMark offers a very nice compromise (relying on the existence 
or not of blank lines) but there are way to many existing documents that would 
break if the behavior was changed. The only way we can change is if we leave 
Markdown behind and use a new, *different* language. For example, if tomorrow 
GitHub swapped out their Markdown parser for CommonMark, how many of their 
customers' README files would suddenly be broken? I imagine there would be an 
outcry! As a longtime implementer of the most popular implementation in a 
certain language, I can't do that to my users.

When the creators of CommonMark embrace it for what it is -- a new sister 
language, I'll be happy to join the discussion. And I might even use it in 
place of Markdown in certain situations. But until then, I have no interest in 
pretending it is something it is not. To be clear, I like much of  the spec; it 
improves on many of Markdown's weaknesses, but I can't be a part of something 
that claims to be something it is not. I realize it's not my call, but I would 
prefer that any discussion of CommonMark be kept off this list -- this is a 
list for discussing Markdown. I've been quietly contemplating the situation 
until now, and now that I've shared my opinion on the matter, I won't bring it 
up again.

Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[Alan Hogan]

On Sep 17, 2014, at 4:57 PM, Michel Fortin  wrote:

> I'll just point out that the markdown="1" trick should be credited to John 
> Gruber.

Thanks. Sorry for getting that wrong.

> CommonMark interprets it "right" according to your intent, but the Markdown 
> spec by John Gruber is very explicit about block-level HTML elements:

> I think the spec makes it clear that the content of `` should not be 
> parsed with the Markdown syntax. As for whether the spec is right or wrong in 
> that choice, that is another debate entirely.


Indeed. To be clear, I am aware of Gruber’s rule (although I forget it from 
time-to-time as an author), and was hoping to provoke some discussion with the 
aim of, yes, rallying around the Common Mark decision here. 

I do not understand why the rule existed in the first place.

Apart from historical reasons, are there other good reasons to avoid Markdown 
processing within block-level elements?

And as far as those historical reasons go, I hope it’s abundantly clear how 
very silly it is for a hundred non-interoperable implementations to claim the 
motivation of “compatibility" to shun the change needed for consensus.

Break things. Bump the major version. Be part of an ecosystem that actually 
works.

Alan Hogan___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Markdown within block-level elements

[Michel Fortin]

Le 17-sept.-2014 à 17:46, Alan Hogan  a écrit :

> 3. Michel Fortin came up with a clever solution to allow this at authors’ 
> discretion way back when, but it is not popular, and most other flavors 
> ignore the markdown=“1” flag altogether. It is usually echoed into rendered 
> HTML by other flavors. It is One More Thing for an author to memorize, so I 
> don’t love the writing experience with it, either. I would like to see 
> Markdown within block-level elements to be the default.
> 
>  <http://ajh.us/bbmk-title-in-header-extra>

I'll just point out that the markdown="1" trick should be credited to John 
Gruber. It was his plan to incorporate this into Markdown at some point (and if 
I recall well, one of the 1.0.2 betas had the feature enabled, but it was 
removed in later betas because it had issues).

I do agree that it is overly verbose. Perhaps we should have an alternative 
simpler syntax. I though of this the other day (notice the `*`):


Header!
--
Subtitle



> 5. Look for Common Mark, a.k.a. “stdmd 0.1”, in Babelmark.
> 
>  <http://ajh.us/bbmk-title-in-header>
> 
>  Note that it gets the output right: It interprets the  tags as 
> block-level tags inside of which I wrote more content. The only other 
> packages to do so were Haskell markdown package 0.1, cheapskate 0.1, and 
> pandoc 1.13.

Here is the conflict. CommonMark interprets it "right" according to your 
intent, but the Markdown spec by John Gruber is very explicit about block-level 
HTML elements:

> Note that Markdown formatting syntax is not processed within 
> block-level HTML tags. E.g., you can’t use Markdown-style *emphasis* 
> inside an HTML block.
>
> -- <https://daringfireball.net/projects/markdown/syntax#html>

Of course, Markdown.pl doesn't treat `` as a block-level HTML element 
as this element didn't exist at the time. HTML5 brought us a couple of those 
block-level elements, and some Markdown parsers have been catching up while 
others ignored this completely.

I think the spec makes it clear that the content of `` should not be 
parsed with the Markdown syntax. As for whether the spec is right or wrong in 
that choice, that is another debate entirely.

As a new flavor, CommonMark is free to deviate from the Markdown spec. But for 
my part I don't intend to implement a change that'd break who knows how many of 
a ten year legacy of documents with HTML snippets in them.


-- 
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Markdown within block-level elements

[Alan Hogan]

I just wanted to share a few short observations regarding Markdown within 
block-level elements, which I (and the Common Mark project) wish to be enabled 
by default.

1. I believe this to be a very desirable feature for writing Web content. (See 
item #6 for specific motivation. Generally and intuitively, I expect everything 
in my markdown document to be subject to Markdownification, with the exception 
of indented, fenced, or back tick-delimited code and content within (not 
between!) HTML tags. )

2. If your parser/converter does allow this, *please* make sure it is 
HTML5-aware. There should not be this much difference between a  and a 
.  Just look at how many implementations consider  to be plain 
text, wrapping it in paragraph tags!

  <http://ajh.us/bbmk-title-in-div> 
  vs
  <http://ajh.us/bbmk-title-in-header>

3. Michel Fortin came up with a clever solution to allow this at authors’ 
discretion way back when, but it is not popular, and most other flavors ignore 
the markdown=“1” flag altogether. It is usually echoed into rendered HTML by 
other flavors. It is One More Thing for an author to memorize, so I don’t love 
the writing experience with it, either. I would like to see Markdown within 
block-level elements to be the default.

  <http://ajh.us/bbmk-title-in-header-extra>

4. This won’t be a surprise to anyone, but the differences between flavors here 
is causing me real problems as an author. I am currently writing in iA Writer, 
previewing with Marked, managing changes with GitHub, and publishing with PHP 
Markdown Extra. Naturally, these all give different results, decreasing (a) my 
confidence as an author and (b) the utility of Markdown, since I am forced to 
write more raw HTML to get consistent and desirable output.

5. Look for Common Mark, a.k.a. “stdmd 0.1”, in Babelmark.

  <http://ajh.us/bbmk-title-in-header>

  Note that it gets the output right: It interprets the  tags as 
block-level tags inside of which I wrote more content. The only other packages 
to do so were Haskell markdown package 0.1, cheapskate 0.1, and pandoc 1.13.

6. For those curious, the reason I want to wrap an  and a  inside of a 
 is that, with the removal of , it arguably remains the best 
way to semantically represent some instances of the “subtitle” concept HTML 
never really provided for. It’s a pattern recommended in the HTML5 standard.

Thanks for your consideration.
Alan Hogan
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss