fix font-weight CSS to use designated bold font #60
Conversation
📝 WalkthroughWalkthroughThis pull request modifies the custom CSS stylesheet to adjust font styling. Two new Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Entelligence AI Vulnerability ScannerStatus: No security vulnerabilities found Your code passed our comprehensive security analysis. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
app/styles/custom.css(2 hunks)
🔇 Additional comments (1)
app/styles/custom.css (1)
120-140: External font URL is accessible and valid.Verification confirms the external CDN URL returns HTTP 200, indicating it is accessible and functioning correctly. No issues detected with URL accessibility or validity.
| @font-face { | ||
| font-family: basiercircle; | ||
| font-weight: 600; | ||
| src: url("https://static.parastorage.com/services/santa-resources/resources/viewer/user-site-fonts/fonts/Avenir_Family_Pack/v1/AvenirLTW05-85Heavy.woff2"); | ||
| } | ||
|
|
||
| @font-face { | ||
| font-family: basiercircle; | ||
| font-weight: 700; | ||
| src: url("https://static.parastorage.com/services/santa-resources/resources/viewer/user-site-fonts/fonts/Avenir_Family_Pack/v1/AvenirLTW05-85Heavy.woff2"); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
Verify that font-weight 600 and 700 should both map to the same Heavy font file.
Both new @font-face rules reference the identical URL (AvenirLTW05-85Heavy.woff2), which means semibold (600) and bold (700) will render with the same visual weight. This is semantically unusual—typically, different font-weights should map to appropriately weighted font files (e.g., a Medium/SemiBold variant for 600 and a Bold/Heavy variant for 700).
Confirm this is intentional and that the intended behavior is for both font-weights to use the same Heavy font file.
🌐 Web query:
How does @font-face font-weight descriptor work when multiple font-weights reference the same font file? Will browsers apply different synthetic scaling?
💡 Result:
Short answer: Browsers treat each @font-face rule's font-weight descriptor as what weights that face represents, even if multiple rules point to the exact same font file. The font-matching engine will pick the face whose descriptor best matches the requested weight; if an exact weight variant isn't actually present, the UA may synthesize (faux) bold/italic. Browsers do not magically re-render the same file at different optical sizes — they either use the declared face, synthesize stroke-weight (faux bold/italic), or — for a variable font — interpolate along the font’s weight axis if the file supports it.
Key points and how browsers behave
- @font-face font-weight is used by the matching algorithm to choose a face for a requested weight. If you declare multiple faces (e.g. 400 and 700) that point to the same src, the UA will treat them as available faces at those weights. (w3.org)
- If the chosen face doesn’t actually contain a heavier/light glyph set, browsers often perform synthetic bolding/italicizing (implementation-dependent, looks different across browsers). You can opt out with font-synthesis:none (but support is spotty). (stackoverflow.com)
- For variable fonts (single file exposing a weight axis) the browser will interpolate genuine intermediate weights if the font file exposes that axis and you declare an appropriate weight range. For static fonts, there’s no true interpolation other than the UA’s synthetic tricks. (w3.org)
Practical recommendations
- Don’t declare multiple weight descriptors that point to the same static font file unless you know the file actually contains those weights (or is a variable font exposing weight).
- Ship proper weight files or a variable font to avoid inconsistent synthetic bolding across platforms.
- Use font-synthesis:none if you want to prevent UA fake bold/italic (and provide the weights you need). (nimbupani.com)
If you want, I can inspect a concrete @font-face snippet you’re using and tell you what will happen in current browsers.
Citations:
- 1: https://www.w3.org/TR/2013/WD-css3-fonts-20130212/Fonts.html?utm_source=openai
- 2: https://stackoverflow.com/questions/22522186/chrome-cant-estimate-bold-font-weight?utm_source=openai
- 3: https://www.w3.org/TR/2013/WD-css3-fonts-20130212/Fonts.html?utm_source=openai
- 4: https://nimbupani.com/fake-bolding-of-web-fonts.html?utm_source=openai
Both font-weight declarations (600 and 700) reference the same static font file, which will trigger synthetic bolding and cross-browser inconsistency.
When multiple @font-face rules point to the same static font file with different font-weight descriptors, the browser's font-matching engine assigns those weights to the face, but since the file is static, it cannot provide true intermediate weights. Browsers will synthesize (faux) bold/italic for weights not actually present in the file, with results varying across browsers. The practical recommendation is to not declare multiple weight descriptors pointing to the same static font file unless the file actually contains those weights.
Since "AvenirLTW05-85Heavy.woff2" appears to be a single Heavy variant, the font-weight 600 declaration will likely trigger synthetic bolding while 700 may match exactly. This creates rendering inconsistency.
Recommended fix: Either provide separate font files for each weight (e.g., a proper SemiBold for 600) or use a variable font that exposes the weight axis. If only Heavy is available, use a single @font-face rule without specifying font-weight and accept that both 600 and 700 will render identically without synthetic effects (or remove the 600 weight usage).
🤖 Prompt for AI Agents
In app/styles/custom.css around lines 130-140, two @font-face rules map
font-weight 600 and 700 to the same static Heavy font file which causes browsers
to synthesize weights and produce inconsistent rendering; fix by either (A)
replacing the 600 rule with a proper SemiBold/600 font file and update its src
to the correct file, or (B) if only the Heavy file exists, remove the 600
@font-face (or stop using weight 600 in CSS) and keep a single @font-face for
the Heavy (700) variant, or (C) switch to a variable font exposing the weight
axis and point both weights to that variable font file so the browser can render
true weights.
|
superseded by #61 |
No description provided.