<div>Waylan Limberg<span dir="ltr">&lt;<a href="mailto:waylan@gmail.com">waylan@gmail.com</a>&gt;</span>wrote:</div><div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<font class="Apple-style-span" color="#666666">Just an FYI, but the section separator that Alan mentioned is actuallypart of YAML. In fact, IIRC without it the YAML parser would considerit an invalid document. I guess the point is that what marks themeta-data could be dependent on what format is used for meta-data.That might be hard to define in a Markdown spec if we leave it openfor any meta-data format.</font></blockquote>
<div><br></div><div>The idea I had in mind is that if Markdown were to define a syntax for a metadata section, Markdown parsers could ignore such sections. That way, a given document with metadata wouldn&#39;t <i>require</i>a particular preprocessor in order to render sensibly.</div>
<div><br></div><div>Sherwood Botsford<span dir="ltr">&lt;<a href="mailto:sgbotsford@gmail.com">sgbotsford@gmail.com</a>&gt;</span>wrote:</div><div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<font class="Apple-style-span" color="#666666">I would propose that all versions of MD support three flags -quirks and -standard -strict.</font></blockquote><div><br></div><div>Excellent. I don&#39;t think that all versions would need to support all three  a new implementation needn&#39;t provide a &quot;quirks mode&quot;, for example.</div>
<div><br></div><div>I suggest tweaking the flags slightly:</div><div><br></div><div><b>--quirks</b></div><div>Backwards-compatibility mode for the implementation in question. In quirks mode, two implementations may give different output for a given input.</div>
<div><br></div><div><b>--standard</b></div><div>Full support for all current language features as defined by the then-current specification. For any given input, every implementation should produce the same output, although the output may differ from that produced in quirks mode.</div>
<div><br></div><div><b>--quirks --extensions ext1 ext2  extN</b></div><div>Backwards-compatibility mode plus backwards-compatible versions of the required extensions.</div><div><br></div><div><b>--standard --extensions ext1 ext2 ... extN</b></div>
<div>Full support for all current language features as defined by the then-current specification, plus extensions that conform to the syntax which is to be included in the spec at some point in the future. Making language extensions opt-in initially would make it possible to test a language extension in the wild before its behaviour is set in stone.</div>
<div><br></div><div>For example, one might translate a particular document using <font class="Apple-style-span" face="&#39;courier new&#39;, monospace" color="#ffffff" style="background-color: rgb(102, 102, 102);">--standard --extensions footnotes</font> until, at some point in the future, footnotes become part of the specification. One could then switch to simply using <font class="Apple-style-span" face="&#39;courier new&#39;, monospace" style="background-color: rgb(102, 102, 102);" color="#ffffff">--standard</font>.</div>
<div><br></div><div>David</div><br><div class="gmail_quote"><br></div><div class="gmail_quote">On 16 August 2011 08:50, Waylan Limberg <span dir="ltr">&lt;<a href="mailto:waylan@gmail.com">waylan@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Tue, Aug 16, 2011 at 1:07 AM, David Chambers<br>
&lt;<a href="mailto:david.chambers.05@gmail.com">david.chambers.05@gmail.com</a>&gt; wrote:<br>
&gt; First let me say that this thread has me excited. There&#39;s a great deal of<br>
&gt; constructive discussion, and a surprising number of &quot;I agree&quot; replies.<br>
&gt; I&#39;ll add my two cents on the particulars that have been discussed herein.<br>
&gt; Metadata<br>
&gt; Just about every Markdown document I create includes metadata (for date,<br>
&gt; time, and time zone, and sometimes tags). I couldn&#39;t live without it, but as<br>
&gt; a user it doesn&#39;t matter to me whether these data are processed by the<br>
&gt; Markdown library itself or, as Waylan suggested, by &quot;a separate [] library<br>
&gt; (like YAML) which reads and removes the metadata&quot;.<br>
&gt; I think Alan&#39;s suggestion that Markdown should define syntax for a metadata<br>
&gt; section (while ignoring the contents of such sections) is an excellent one.<br>
<br>
</div>Just an FYI, but the section separator that Alan mentioned is actually<br>
part of YAML. In fact, IIRC without it the YAML parser would consider<br>
it an invalid document. I guess the point is that what marks the<br>
meta-data could be dependent on what format is used for meta-data.<br>
That might be hard to define in a Markdown spec if we leave it open<br>
for any meta-data format.<br>
<div class="im"><br>
&gt; Definition lists<br>
&gt; The fact that including more than one definition for a given term is an<br>
&gt; uncommon requirement should not preclude such use cases from being<br>
&gt; accommodated. Rather than thinking in terms of the &quot;rendered&quot; content (be it<br>
&gt; HTML, PDF, or some other format) we should first think in terms of what our<br>
&gt; content means and how best to express that meaning in a structured fashion.<br>
&gt; Definition lists are a good case in point. What is a definition? Text that<br>
&gt; explains the meaning of or describes some thing. There therefore exists some<br>
&gt; relationship between the definition and the thing it defines. Also, there<br>
&gt; may be several ways to describe one thing. What is the relationship between<br>
&gt; various definitions for a particular thing? Are they equally important? Are<br>
&gt; they sequential? Can they be grouped in some way? Can one description apply<br>
&gt; to more than one thing?<br>
<br>
</div>Valid questions. Interestingly, the HTML5 spec answers some of this.<br>
In fact, the HTML5 spec [1] calls `&lt;dl&gt;` a &quot;description list&quot; which<br>
expands beyond definitions. It states: &quot;Name-value groups may be terms<br>
and definitions, metadata topics and values, questions and answers, or<br>
any other groups of name-value data.&quot; And then proceeds to provide<br>
examples, one of which specifically provides two terms for a value. I<br>
don&#39;t see any reason why a markdown variant wouldn&#39;t support all the<br>
same use cases.<br>
<br>
[1]: <a href="http://developers.whatwg.org/grouping-content.html#the-dl-element" target="_blank">http://developers.whatwg.org/grouping-content.html#the-dl-element</a><br>
<br>
--<br>
----<br>
\X/ /-\ `/ |_ /-\ |\|<br>
<font color="#888888">Waylan Limberg<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Markdown-Discuss mailing list<br>
<a href="mailto:Markdown-Discuss@six.pairlist.net">Markdown-Discuss@six.pairlist.net</a><br>
<a href="http://six.pairlist.net/mailman/listinfo/markdown-discuss" target="_blank">http://six.pairlist.net/mailman/listinfo/markdown-discuss</a><br>
</div></div></blockquote></div><br>