<div dir="ltr">My responses inlined:<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 3, 2013 at 11:36 PM, Michel Fortin <span dir="ltr">&lt;<a href="mailto:michel.fortin@michelf.ca" target="_blank">michel.fortin@michelf.ca</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Le 3-oct.-2013 à 11:38, Roopesh Chander &lt;<a href="mailto:roop@forwardbias.in" target="_blank">roop@forwardbias.in</a>&gt; a écrit :<br>



<div><br>
</div>Well, what I meant is that it&#39;s more maintenance work for everyone (spec writer and all implementers).<br></blockquote><div><br></div><div>We are talking about a case where certain characters (e.g. tabs) in the middle of some text is converted to a certain number of other characters (e.g. spaces) in the output, just like that. And nothing to justify or even explain this exists in the user-facing documentation. It surprises me that this does not seem to you like a problem worth attempting to fix.</div>

<div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
</div>Really? We be more concerned with how it *should* be interpreted instead of how it *is* implemented?<br>
<br>
I&#39;ll just open a parenthesis here. You know what made the HTML5 parsing algorithm a success? It&#39;s quite simple actually. It formalized all the clunky patchwork that browsers where doing and created a parser algorithm that everyone could use. That meant that parsing of the `&lt;title&gt;` element is idiotically special-cased, so is `&lt;script&gt;`, so is `&lt;plaintext&gt;`, etc. Why? Because browser vendors could not start from a clean state: their browser needed to be able to parse the thousands of millions of HTML documents on the web reliably, irrespective of how &quot;well-formed&quot; they were. The failure rate had to be tremendously small.<br>


</blockquote><div><br></div><div>Let me think this analogy through:</div><div><br></div><div>Before HTML5, there was no consistency in how different browsers handled *badly-formed* HTML.</div><div>With the HTML5 parsing algorithm, instead of &quot;clunky patchworks&quot;, the browsers could use a common algorithm that has been designed with most of the use cases in mind. However, switching to the HTML5 parsing algo wasn&#39;t easy (Webkit wrote over 10k LOC for just tokenising input and forming the syntax tree [1]). So for HTML5, as I understand it, handling as many current HTML documents as possible is a goal; minimizing the effort for browsers to modify their code to adopt it is a non-goal.</div>

<div><br></div><div>[1]: <a href="https://www.webkit.org/blog/1273/the-html5-parsing-algorithm/">https://www.webkit.org/blog/1273/the-html5-parsing-algorithm/</a></div><div><br></div><div>So to map your analogy to Markdown:</div>


<div>    HTML5 parsing spec -&gt; vfmd spec</div><div>    Web Browsers -&gt; Markdown implementations</div><div>    HTML documents -&gt; Markdown documents</div><div><br></div><div>For obvious input, most Markdown implementations agree. For non-obvious input, they behave inconsistently. For vfmd, it&#39;s desirable that it handles existing documents well. It&#39;s a non-goal to minimize the coding effort for switching to vfmd (thought that would be a nice-to-have).</div>

<div><br></div><div>However, there&#39;s another goal for vfmd that is placed at a higher priority: Provide a user guide for the syntax that is consistent with the parsing spec. The user guide can say stuff like this:</div>

<div>  (a) &quot;For blockquoting, start the line with &#39;&gt;&#39; followed by an optional space.&quot;</div><div>  (b) &quot;For code blocks, indent each line with 4 spaces or 1 tab&quot;</div><div><br></div><div>Let&#39;s say a user wants to place a code block inside a blockquote. After reading the above lines in the user doc, the user could write (.=space;_=tab;tabstop=4):</div>

<div><br></div><div><font face="courier new, monospace">&gt;.__code block</font></div><div><br></div><div>If we preprocessed tabs, this wouldn&#39;t be interpreted as said in the user doc. From the user&#39;s perspective, it would be like &quot;I wrote it as said, but things didn&#39;t happen as promised.&quot;</div>

<div><br></div><div>I believe stuff like can be solved only if we are aware of the tab characters while parsing. If you say we should preprocess tabs to spaces before parsing, can you come up with the right wording for the user documentation that would be compatible with the preprocess-tabs method of parsing?</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So a change in the treatment of tabs, while it might seem innocuous at first glance, is the kind of change that has the potential to break existing documents in various ways that are hard to predict even for an expert reviewing a document in text form (all whitespaces are look the same after all).</blockquote>

<div><br></div><div>I think we will be able to discuss this better with actual examples. You mention &quot;lists within blockquotes&quot; later in the mail, maybe you can elaborate on that.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div><br>
&gt;&gt; The more the spec deviates from what the parsers are actually doing, the more<br>
&gt;&gt; difficult it&#39;ll be to adopt for implementers for two reasons: implementation work<br>
&gt;&gt; and the potential to break our user&#39;s documents.<br>
&gt;<br>
&gt; Let&#39;s consider each of your reasons one by one.<br>
&gt;<br>
&gt; ### Reason 1: Implementation work<br>
&gt;<br>
&gt; vfmd can entice developers to adopt it on two orthogonal, sometimes<br>
&gt; conflicting factors:<br>
&gt;  (a) It&#39;s easy to adopt it<br>
&gt;  (b) It gives the best possible interpretation for any input<br>
&gt;<br>
&gt; vfmd anyway has a different parsing architecture from most current<br>
&gt; implementations (per my knowledge), so (a) wouldn&#39;t stand. Just satisfying<br>
&gt; (a) wouldn&#39;t be very persuasive either. If it wants a chance at being<br>
&gt; implemented, it&#39;s got to aim for (b), even if that can be a little<br>
&gt; detrimental to (a). It should be easy to adopt, but not at the cost of<br>
&gt; correctness.<br>
<br>
</div>But are you sure about B? I&#39;m not convinced it is so much better. Replacing tabs with spaces before parsing means that we interpret things the same way as a 4-spaces-per-tab-stop editor will display them, always. Even if you have an invisible stray tab somewhere, anywhere, if it looks right in your editor it&#39;ll work. On the other side, your algorithm assumes that tabs are always intentional; it will break if somewhere they&#39;re a stray tab that was not meant to be there. It&#39;s not that clear-cut to me which is better. It is just based on different assumptions, and will fail in different circumstances. Changing behaviour is more likely to fail with existing documents however.<br>

</blockquote><div><br></div><div>I guess anything that exists in the document should be considered as being put there intentionally. I don&#39;t think we should be trying to *fix* the user&#39;s document for him. (For example, we don&#39;t filter off unmatched asterisks assuming they were stray characters). It&#39;s futile to &quot;guess&quot; whether a character in the input is there by intent or by mistake.</div>

<div><br></div><div>And anyway, for HTML output, actual tab characters in the input matter only in code blocks/spans, not in normal text (i.e. whether it&#39;s tab or space, it would display identically in browsers (unless overridden in CSS)). </div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div><br>
<br>
&gt; ### Reason 2: Breaking existing documents<br>
&gt;<br>
&gt; Are you talking about list handling or for other parts of the syntax? For<br>
&gt; lists, for users using tabstop=4, the behaviour is the same, as we saw<br>
&gt; earlier.<br>
<br>
</div>It&#39;s not always the same, even for lists. Putting your list inside a blockquote changes things because it adds a two-column indentation. Some extension features I mentioned before may also be affected, making things harder to adopt for implementations that have to support extensions (pretty much all of them actually).<br>

</blockquote><div><br></div><div>Please give a few examples of inputs that would break. Maybe that way, I will be able to appreciate how adverse a change this will be, if made.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div>
&gt; For tabs within code blocks, the behaviour would be different, but<br>
&gt; I would be surprised if users *relied* on tabs within code blocks turning<br>
&gt; into spaces in the output.<br>
<br>
</div>Actually, *I* rely on tabs being converted to spaces within code blocks in many of my documents. It happens a lot that I have tabs in the code I copy-paste, and since browsers don&#39;t all show tabs in a consistent way inside a `&lt;pre&gt;`, it&#39;s much better if they get converted to spaces. But I didn&#39;t think tabs inside code blocks were into question here, are they?<br>

</blockquote><div><br></div><div>As far as I know, most browsers use 8 as tabstop by default, so it&#39;s fairly consistent. I didn&#39;t understand what you meant by &quot;I didn&#39;t think tabs inside code blocks were into question here, are they?&quot;.</div>

<div><br></div><div>Is there anyone else in this list who relies on tabs inside code-blocks to be converted to spaces?</div><div><br></div><div>BR,</div><div>roop.</div></div></div></div>