.markdown-body: whitespace inside <a> wrapping <img> renders as underlined space
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- scss
- Domain
- frontend
Research direction
Start in src/markdown/images.scss and locate the existing .markdown-body block. Reproduce the multiline HTML anchor-and-image example from the issue, then apply the proposed styling there. Done means the whitespace inside the anchor no longer renders as an underlined gap while spacing between adjacent badges remains unchanged.
Written by the indexing model from the issue text.
Description
Description
In .markdown-body, an anchor wrapping an image renders an underlined space when the <a> and <img> are written on separate lines. The newline and indentation between the tags is a text node inside the anchor, so it inherits the link's text-decoration and paints as an underlined gap.
This is the standard way badge rows are written in READMEs, since centering requires an HTML wrapper (<p align="center">) that markdown cannot express.
Reproduction
GitHub passes inline HTML through unchanged, so whitespace authored between the tags survives into the DOM. Compare the two ways of writing the same badge, as returned by POST /markdown with mode=markdown.
HTML form:
<a href="https://example.com/a">
<img src="https://img.shields.io/badge/build-passing-green.svg"/>
</a>
emits:
<a href="https://example.com/a" rel="nofollow">
<img src="https://camo.githubusercontent.com/..." style="max-width: 100%;">
</a>
The newline and indent on either side of <img> are text nodes inside <a>, and are underlined.
Markdown form:
[](https://example.com/a)
emits:
<a href="https://example.com/a" rel="nofollow"><img src="https://camo.githubusercontent.com/..." alt="build" style="max-width: 100%;"></a>
No text node inside the anchor, no underline. Markdown is not special here, it simply cannot express the whitespace.
Proposed fix
One rule, in src/markdown/images.scss, inside the existing .markdown-body block:
a[href]:has(img) {
display: inline-flex;
}
Making the anchor a flex container drops whitespace-only anonymous children, so there is nothing left to underline. Spacing between badges is unaffected, since that whitespace lives between anchors rather than inside them.
:has() is baseline across all supported browsers.
Scope
Any README using multi-line <a><img> badge blocks, which is the common form for centered badge rows.
- winsiderss/systeminformer#3006: a contributor hit this independently and collapsed every tag pair by hand. The maintainer's first response was to ask whether it was the same thing he had seen on another README.
- orhun/git-cliff#809: the same manual workaround, which I authored. Closing
</a>on the same line as<img>is not how anyone would naturally write nested HTML, so the file carries an inline<!-- </a> being on the same line as the <img> tag is intentional! -->comment. Without it, the next person editing that block may put the closing tag on its own line, correctly indented, matching the surrounding style, and silently reintroduce the bug.
So a workaround exists, but it requires every repo to keep non-idiomatic markup indefinitely, where the idiomatic correction is the thing that breaks it.
Originally raised on the community feedback board in March 2025 (https://github.com/orgs/community/discussions/154640) with no response. Filing here since this repo owns the file. The rule is free to use without conditions.
- Dominant language
- SCSS
- Stars
- 13k
- Forks
- 1.3k
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 27
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from primer/css
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
t/bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
bug ready-for-dev
Difficulty 1/5 1-3 hours Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 92/100