-
Notifications
You must be signed in to change notification settings - Fork 977
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GitHub-Style Footnotes #2326
GitHub-Style Footnotes #2326
Conversation
* Reuse Client when checking urls and add timeout for requests
* Implement replace_re filter * Cargo fmt * add regex caching * cargo fmt * update docs, update unit test * rename replace_re -> regex_replace
Relative links in the entry content do not currently have a base URI, so will be resolved relative to the feed URI: Given an entry with the content: <a href="some-resource.bin"> And URIS of: * entry: https://example.org/blog/some-entry/ * feed: https://example.org/atom.xml The link URI will end up as: https://example.org/some-resource.bin rather than the URI that ends up resolved in the rendered page: https://example.org/blog/some-entry/some-resource.bin The atom and RSS formats allow for an xml:base attribute (itself specified in [1]) to provide a base URI of a subset of a document. This change adds xml:base attributes to each entry, using the page permalink. This gives us something equivalent to: <entry> <content xml:base="https://example.org/blog/some-entry/"> <![CDATA[ <a href="some-resource.bin"> ]]> </content> </entry> [1]: https://www.w3.org/TR/xmlbase/ Signed-off-by: Jeremy Kerr <[email protected]>
* Fix multi-ligual json index * multi-lingual search Fix cargo fmt
…tzola#2196) * Add search into the serialized config (getzola#2165) * Only expose index_format * Create config.search struct * cargo fmt
* Fix hard link panic and add better error info to std:fs errors * cargo fmt * Remove erroneously committed config change * Remove console import; Use with context to provide additional error info * improve error wording
* Add optional decoding="async" loading="lazy" for img In theory, they can make the page load faster and show content faster. There’s one problem: CommonMark allows arbitrary inline elements in alt text. If I want to get the correct alt text, I need to match every inline event. I think most people will only use plain text, so I only match Event::Text. * Add very basic test for img This is the reason why we should use plain text when lazy_async_image is enabled. * Explain lazy_async_image in documentation * Add test with empty alt and special characters I totaly forgot one can leave the alt text empty. I thought I need to eliminate the alt attribute in that case, but actually empty alt text is better than not having an alt attribute at all: https://www.w3.org/TR/WCAG20-TECHS/H67.html https://www.boia.org/blog/images-that-dont-need-alternative-text-still-need-alt-attributes Thus I will leave the empty alt text. Another test is added to ensure alt text is properly escaped. I will remove the redundant escaping code after this commit. * Remove manually escaping alt text After removing the if-else inside the arm of Event::Text(text), the alt text is still escaped. Indeed they are redundant. * Use insta for snapshot testing `cargo insta review` looks cool! I wanted to dedup the cases variable, but my Rust skill is not good enough to declare a global vector.
…atter (getzola#2237) * Prevent spans crossing line boundaries in class formatter * Add snapshot tests for classed highlighting
* sort page.assets by filename Uses .to_str() to sort files and subfolders. The .unwrap() may need work or be replaced by unwrap_or_default(). Given earlier checks in the function it should work however. * add tests for assets sorting * fix rustfmt * use existing loop instead of windows * also check the non-recursive test * use .zip() and add assert msg
* templates:atom: add support for multiple authors Atom 1.0 [0] support multiple `<author>` entries in the feed. This commit modified the template to generate as many `<author>` as the page's metadata contains. [0] https://validator.w3.org/feed/docs/atom.html#recommendedEntryElements * Test we can have multiple authors in ATOM feeds
The `rel` and `type` HTML attributes are needed in the `base_url` (or `section.permalink`) link so feed aggregators know that's the HTML page that corresponds to the atom feed. Note: The RSS template doesn't have this issue.
…fig file not present (getzola#2262)
* use fs canonicalize to prevent path traversal * fix cargo fmt
* Add ignored_static to config * Make handle ignored static files correctly * cargo fmt * Match on relative path rather than incorrect target path * path -> partial path for serve static ignore * remove debug println * copy static directory if there is no ignored globset * Update docs * Deduplicate code with additional Option argument * cargo fmt
…etzola#2287) The warning about unknown highlight languages was displayed even when code highlighting was disabled via `markdown.highlight_code = false`. This commit adds a condition to check this setting before issuing the warning, effectively suppressing it when code highlighting is disabled. Issue: getzola#2280
* Fixed "unnecessary mut" warning * Fixed minor typo * Use more than 8 threads for links checking if hardware supports it * Fixed failing azure Linux check * Avoid unnecessary HTTP requests to the same, already checked links
Can you clean up the commit history? |
I don't know, if this is out of scope for this change, but currently footnotes are generated like this: <div class="footnote-definition" id="bar"><sup class="footnote-definition-label">1</sup>
<p>baz</p>
</div>
<div class="footnote-definition" id="baz"><sup class="footnote-definition-label">2</sup>
<p>lul</p>
</div> I would like to render successive footnotes in a box, which is currently not possible. Is it possible to change the generated HTML to wrap successive footnotes inside a <div class="footnotes-list">
<div class="footnote-definition" id="bar"><sup class="footnote-definition-label">1</sup>
<p>baz</p>
</div>
<div class="footnote-definition" id="baz"><sup class="footnote-definition-label">2</sup>
<p>lul</p>
</div>
</div> That way, the |
I'm not a 100% sure, I understand you correctly, but all footnotes in this new style are wrapped in an |
I'm asking, if the old style of generating footnotes could be changed to wrap the footnotes in a |
For that you should open a new Issue imo. |
Ok, so it's out of scope, as expexted. I'll look into this. Another question: shouldn't the Github style footnotes use the same CSS class names as the old footnotes? |
Probably? If it makes sense |
I could do that, of course, but I don't think that's the best approach. As far as I can tell, quite a few markdown tools use the GitHub style with these classes. In my opinion, we should follow this more standard approach. |
do you have examples? |
Ah, sorry. I was thinking about a different thing and mixed up the classes you were referring to. I have now added the |
I also noticed that pulldown-cmark has added support for GitHub-style footnotes (pulldown-cmark/pulldown-cmark#654). So the code changed by this feature can be removed if and when pulldown-cmark publishes a new release. (The feature was added in June to the repository, the last version was published in May. It may take a while.) |
Oh let's wait for that then if you don't mind, we would switch to it at the next release of pulldown-cmark anyway |
Just a note that it looks like the upstream PR was merged. I would be very interested in having generated footnotes that use |
Curious to know if this would be merged soon? |
No, we'll update the library to add support when it's released |
FYI, it seems that there are now new releases available: https://github.com/raphlinus/pulldown-cmark/releases/tag/v0.9.6. |
Unfortunately those releases don't include pulldown-cmark/pulldown-cmark#654 yet. |
https://github.com/raphlinus/pulldown-cmark/releases/tag/v0.10.0 is now out and it has the relevant footnote issue included |
Sweet! That's a long list of changes, anyone interested in doing a PR? I think there are quite a few changes to make to the current parser |
With #2432 merged, can this move forward? |
It should probably on its own PR, with an option in the config.toml that will enable the pulldown-cmark flag. Closing this PR as it's now outdated |
Is someone in the thread willing to make a new version of this PR? |
I've started working on it, you can assign me to #1285. |
This PR adds the option of rendering footnotes at the bottoms in GitHub-Style, based on the implementation of notriddle.
Closes #1285.
For instance, the following markdown
Gets rendered to:
This style is disabled by default and can be turned off via the
markdown.bottom_footnotes
option in theconfig.toml
.