Repository navigation
Claude/hansmartens market positioning mlt89z - #689
Merged
hansmartensdev merged 3 commits intoSep 15, 2026
Merged
Conversation
Both hovers were doing harm rather than nothing. The secondary is an opaque brand-700 fill, and the band behind it is a gradient travelling brand-500 down to brand-900. The buttons sit low in that travel, where the ground is already near brand-700, so a brand-800 hover landed the fill within 1.08:1 of the colour behind it. The button did not darken on hover, it disappeared. Measured across all eight palettes: 1.49 at rest falling to 1.08 hovered, worst case, and no palette better than 1.10. The primary is near-white on a dark field and had nowhere brighter to go. Its hover mixed the foreground with white, which inside .invert-section means mixing a near-white with white: the fill moved by 1.7 per cent. There was a hover rule; it did nothing visible. The pair also wanted opposite directions to read at all here - lighter for the dark secondary, darker for the light primary - which no single hover convention gives you. Hover is carried by the arrow instead. Both buttons are .group and both arrows match `.group:hover [data-icon="arrow-right"]`, shifting 4px; a press is carried by `active:scale-[0.98]` on Button, and keyboard focus by the ring, which was checked against a screenshot rather than a computed style. Deleting the two rules is enough on its own. The rest-state declarations carry !important, so Button's own `hover:bg-foreground/90` and `hover:bg-secondary` cannot come through behind them. Verified on all eight palettes in light and dark: both buttons hold their colour under the cursor. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwJB1u6U3vdEZ9LrHRebST
Its brand-700 fill sits on a field travelling brand-500 down to brand-900, and the buttons land where the ground is already near brand-700. The fill was 1.47:1 to 1.61:1 against what sits behind it, so the button's shape barely read as a control - short of the 3:1 WCAG 1.4.11 asks for identifying one. The fill could not fix it. brand-600 reaches only 2.04 to 2.34 against the band; brand-500 clears 3:1 in five of the eight palettes and drops the white label to between 2.82 and 4.52, under the 4.5 it needs. brand-700 was chosen in the first place because white sits at 6.03 to 8.43 on it. So the edge does the work instead. A 1px white line at 35 per cent composites over the existing fill: no colour changes, the button only gains a boundary. Sampled off the rendered page, the edge reads 3.21:1 to 3.45:1 against the band across all eight palettes. 45 per cent is the same line with more room, at 3.91 worst, if a future palette needs it. The primary already carries a 1px border, so the pair now match. Scoped to the band. `.cta-btn-brand` is used on light sections too, including the contact form's submit button, where a white edge would be wrong. Three of the eight bands carry only a primary button and are unaffected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwJB1u6U3vdEZ9LrHRebST
Every other call to action in the theme ends in an arrow that shifts 4px under the cursor. The blog band's button carried only the GitHub mark in front of its label, so it was the one button on the site that did not respond to a hover. The GitHub mark stays where it is; the arrow goes after the text. No CSS was needed - Icon renders `data-icon="arrow-right"`, which the existing `.group:hover [data-icon="arrow-right"]` rule already matches. Both variants take it, so the button behaves the same either side of the glitch breakpoint: the band below 1024px and the LetterGlitch version above it. Checked on the blog index, the tag pages and a post at both widths - the arrow moves, the GitHub mark holds still. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwJB1u6U3vdEZ9LrHRebST
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
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
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.
What does this PR do?
A clear description of the change and why it was made.
Fixes # (issue number, if applicable)
Type of change
Checklist
pnpm lintpasses with 0 errorspnpm checkpasses with 0 errorspnpm buildcompletes successfullyScreenshots (if relevant)
Add before/after screenshots for visual changes.