fix(website): restore padding on Shiki code blocks - #924
Merged
Conversation
blove
enabled auto-merge (squash)
September 1, 2026 05:26
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
blove
force-pushed
the
blove/homepage-code-examples-visual-1bd306
branch
from
September 1, 2026 05:43
db69701 to
ef87550
Compare
Contributor
PR #863 deleted the global `.shiki` rules from docs.css on the finding that zero elements matched. That was true of docs and blog — rehype-pretty-code writes its background inline and never emits a `.shiki` class — but two TSX call sites highlight with Shiki's `codeToHtml` directly, which does: - components/landing/HighlightedCode.tsx (homepage Code tabs, /langgraph, /render, /chat) - components/solutions/SolutionCodeBlock.tsx (every /solutions/* page) Those <pre> elements lost their padding. The dark theme background rides inline on the <pre>, while the landing override put its 16px 20px on the wrapper <div> (which carries `shiki` too) — outside the dark box. The result was a light gutter with the code flush against the dark edges. Restores the padding as a `pre.shiki` base rule in global.css, and moves the landing override's padding off the wrapper onto `> pre.shiki`. The selector is pre-scoped deliberately: both call sites also put the class on a wrapper div, where padding lands outside the surface. SolutionCodeBlock's comment claimed Shiki emits its own padding — that wrong premise is what made the deletion look safe, so it is corrected too. Guarded in two halves, since neither is sufficient alone. The CSS half is a style contract (#926's registry — this is precisely the "comment explaining why a declaration must not be removed" that it asks for), mutation-tested by deleting the declaration and by renaming the selector. The markup half lives in HighlightedCode.spec.tsx: that Shiki still emits a `pre.shiki` carrying an inline background and no padding of its own, so the contract keeps guarding a rule something actually matches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
blove
force-pushed
the
blove/homepage-code-examples-visual-1bd306
branch
from
September 1, 2026 05:57
ef87550 to
608b229
Compare
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cause
PR #863 ("docs polish 2/3") deleted the global
.shikirules fromdocs.css:on the finding "zero elements matched, on docs and blog." That was true for docs and blog —
rehype-pretty-codewrites its background inline and never emits a.shikiclass. But two TSX call sites highlight with Shiki'scodeToHtmldirectly, which does emit<pre class="shiki tokyo-night">:components/landing/HighlightedCode.tsx— the homepage Code tabs, plus/langgraph,/render,/chatcomponents/solutions/SolutionCodeBlock.tsx— every/solutions/*pageThose
<pre>elements lost their padding. The dark theme background rides inline on the<pre>, while the landing override put its16px 20pxon the wrapper<div>(which carriesshikitoo) — outside the dark box. Measured before the fix: wrapper padding16px 20px,<pre>padding0px. The result was a light gutter with the code flush against the dark edges.Fix
global.css— apre.shikibase rule restoring padding and the mono font. Scoped topre.shiki, not.shiki, precisely because both call sites also put the class on a wrapper div.styles/landing.css— the landing override's padding moves off the wrapper onto> pre.shiki; it keeps the tighter16px 20pxscale.SolutionCodeBlock.tsx— corrects the comment asserting Shiki emits its own padding. That wrong premise is what made the deletion look safe.Verification (Chrome, dev server)
<pre>pad0px16px 20pxrgb(26,27,38)/langgraph,/render,/chat0px16px 20pxrgb(26,27,38)/solutions/compliance0px20px 24pxrgb(26,27,38)Docs pages still match 0
pre.shikielements with their own[data-rehype-pretty-code-figure] prerules intact — unaffected.Guards
Two halves, since neither is sufficient alone:
styles/style-contracts.spec.ts, using the registry refactor(website): finish the json-render rename; generalise style contracts #926 landed. This is exactly the "comment in a stylesheet explaining why a declaration must not be removed" that registry asks you to convert into an entry. Mutation-tested both ways it requires: deleting thepaddingdeclaration (failsdeclares padding) and renaming the selector wholesale (failshas a rule at all).HighlightedCode.spec.tsx: that Shiki still emits apre.shikicarrying an inline background and no padding of its own. Without it the contract could sit guarding a rule nothing matches any more — which is how fix(website): docs polish 2/3 — breadcrumb, tables, rails, mdx details #863 happened.nx lint website: 0 errors. Website suite: 440/440 pass.🤖 Generated with Claude Code