Skip to content
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

Earmark GFM Footnote Return to Article Link Text Rendered Incorrectly #1452

Closed
jwilger opened this issue Dec 28, 2021 · 6 comments · Fixed by RobertDober/earmark_parser#163
Closed

Comments

@jwilger
Copy link

jwilger commented Dec 28, 2021

When parsing a markdown document that contains footnotes with the option footnotes: true passed to Earmark, the link that is inserted at the end of the footnote by Earmark has the link text set to ["↩"] (https://github.com/RobertDober/earmark_parser/blob/5797a53a1d60003e5d0038c326bfd1e8b129c85f/lib/earmark_parser/ast/renderer/footnote_renderer.ex#L31).

When rendering the documentation as HTML via ex_doc, this link text is escaped, replacing the & with &, so that the literal ↩ is displayed in the text rather than the HTML entity that was intended.

It looks like ex_doc can take a verbatim: true option when rendering a tag (

def to_string({tag, attrs, inner, %{verbatim: true}} = ast, fun) do
) which seems like it would address this issue, but I'm not entirely sure how to get ex_doc to use that option in this case. Part of me wonders if that option shouldn't just be used for all text that is coming from the markdown processor, thus making any escaping of HTML entities the job of the markdown processor itself rather than the templating modules of ex_doc, but I'm not familiar enough with the ins and outs of the project to know if that would be a good idea or not.

@josevalim
Copy link
Member

@jwilger looking at the earmark code you linked, it is not set verbatim: true to that particular node, so maybe that's what we should do? Can you please send a PR to earmark_parser and see if it works?

@jwilger
Copy link
Author

jwilger commented Dec 28, 2021

In addition to looking into @josevalim's comment above, there's a somewhat kludgy workaround using CSS for anyone else who runs into this; just add the following to your mix.exs:

def project do
  [
    # ...
    docs: [
      # ...
      before_closing_head_tag: &before_closing_head_tag/1
    ]
  ]
end

defp before_closing_head_tag(:html) do
  """
  <style>
    a.reversefootnote {
      display: inline-block;
      text-indent: -9999px;
      line-height: 0;
    }

    a.reversefootnote:after {
      content: ' ↩'; /* or any other text you want */
      text-indent: 0;
      display: block;
      line-height: initial;
    }
  </style>
  """
end

defp before_closing_head_tag(_), do: ""

@josevalim
Copy link
Member

Closing this, as I believe it is not an ExDoc issue!

@marick
Copy link

marick commented Jun 8, 2024

If you, like me, find your way to this issue because footnotes render like this:

Screenshot 2024-06-08 at 09 03 26

... despite using markdown_processor: {ExDoc.Markdown.Earmark, footnotes: true} in mix.exs, two notes:

  1. @jwilger's workaround above continues to work in current ExDoc (0.34.0). You get the desired ↩️.
  2. However, the source of the footnote ([^1]) isn't styled to look like a footnote. The following works for me:
    a.footnote {
      font-size: 0.7em;
      vertical-align: super;
    }

... but beware: I know barely any CSS.

Screenshot 2024-06-08 at 09 00 46

@josevalim
Copy link
Member

We probably need to add the CSS to ExDoc? Would you like to send a PR?

bradhanks added a commit to bradhanks/earmark_parser that referenced this issue Mar 10, 2025
bradhanks added a commit to bradhanks/earmark_parser that referenced this issue Mar 10, 2025
bradhanks added a commit to bradhanks/earmark_parser that referenced this issue Mar 10, 2025
@bradhanks
Copy link

I submitted a PR to earmark_parser that I believe fixes this issue: RobertDober/earmark_parser#163

RobertDober pushed a commit to RobertDober/earmark_parser that referenced this issue Mar 11, 2025
RobertDober added a commit to RobertDober/ex_doc that referenced this issue Mar 21, 2025
this includes a fix for elixir-lang#1452 and an important fix for OTP-28
to avoid regular exprssions at compile time
josevalim pushed a commit that referenced this issue Mar 21, 2025
Fix for #1452 and avoiding regexes at compile time (for OTP-28)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

4 participants