Footnotes in preview window #937
Comments
|
Hmm... this looks like it could be a regression for handling of any I'll take a look. |
|
So I took a look at this and it seems this is happening due to the way the footnote links are formatted in combination with a local base path in the page. MM creates pages with a <!DOCTYPE html>
<html lang="en">
<head>
<base href="file:///C:/temp/"/>This allows projects - or even individual pages - to explicitly define a site root path from which site and page relative links work. MM by default uses the currently rendered document's folder which is in the same folder as the underlying document so all resources can be found. So far so good. Here's where it gets weird: The following 'normal' links work just fine navigating in the document for things like <ul>
<li><a href="[#header2](#header2)">Header 2</a></li>
<li><a href="[#header3](#header3)">Header 3</a></li>
</ul>
<h2 id="header2">Header2</h2>
<p>Header 2 text goes here</p>
<h2 id="header3">Header3</h2>
<p>Header 3 text goes here</p>Footnote links use the same link and Id syntax, but the naming of those links is <a id="fnref:1" href="#fn:1" class="footnote-ref"><sup>1</sup></a>.
More text here. This is <a id="fnref:2" href="#fn:2" class="footnote-ref"><sup>2</sup></a>
...
<hr />
<ol>
<li id="fn:1">
<p>This is a footnote<a href="#fnref:1" class="footnote-back-ref">↩</a></p>
</li>
<li id="fn:2">
<p>This is #2<a href="#fnref:2" class="footnote-back-ref">↩</a></p>
</li>
</ol>Exact same logic, but the browser apparently treats the second set of links differently. All of these URLs resolve to the base URL plus the hash: The former works, the latter does not. This only fails in the previewer because we're using local files. A rendered page on a server will work because it won't be a file link and likely you also won't have the I'm not sure how we can fix this - currently MM passes through hash links and just lets them process in the browser. But I can try to navigate the browser. The bigger issue is that with headers it's possible to navigate the editor fairly easily, which is really what we want. Navigate the editor and then have the previewer re-render at the new browser position. This doesn't work for footnotes because they are not explicit Markdown elements the parser tracks (it's an addin). So even the solutions I can possible work, they're not solving the entire problem either way... |
|
So looks like the issue here is that the id name needs to be escaped in the query code. MM explicitly navigates hashes in the page (because of base path fixups discusses above) and the following code using
With this in place the Footnote links in the Previewer can now navigate the footnote links. The next - and more difficult problem is that we can't jump to the exact link in the editor. There's no line number that can match the HTML to the editor at this point so the synced scroll (if enabled) will jump to the end of the doc or the last element that has a line number. |
Footnotes are working fine when I generate my document as a PDF, but when I'm editing, they misbehave.
Now click on the preview pane's little superscript-1, and you get this:
… and yes, I've tried clearing my cookies. That doesn't affect this result.
Thoughts?
The text was updated successfully, but these errors were encountered: