fix(chat): replace the shattered wordmark with a font-independent one - #84
Merged
ndemianc merged 1 commit intoAug 16, 2026
Merged
fix(chat): replace the shattered wordmark with a font-independent one#84ndemianc merged 1 commit into
ndemianc merged 1 commit into
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
…Monaco The wordmark from #82 shatters into disconnected bars in the editor. Reverted. WHAT I GOT WRONG. I claimed the art "cannot develop seams in any monospace font" because it is drawn entirely from `█`. Half of that reasoning was sound — `▀` above `▄` does leave a full cell of gap, which I verified — but the conclusion did not follow: whether `█` FILLS its cell is a property of the FONT, not of the character. Rendered across seven monospace families, the art is solid in SF Mono, Menlo, Courier New, Andale Mono, Consolas and the generic fallback, and shatters completely in Monaco. My harness ran SF Mono, so it looked perfect everywhere I checked, and none of those checks were the editor. The seam test I was so pleased with tested the right mechanism in the wrong place: one font, in a harness, instead of the font the webview actually resolves. The test guard went with it. It asserted "full blocks only", which encoded the false belief as a rule — it would have blocked the fix and waved through the bug. What survives is what this file can honestly check: the column/line bounds (real, and about layout rather than glyphs) and the accessible name. ASCII art has to be looked at in the target font; a static test cannot do it, so it no longer pretends to. The original 12x41 art is restored byte-for-byte from 8126086^. 33 tests in webviewCss, 34 suites green.
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment.
Pull request overview
Reverts the empty-state chat wordmark in the LevelCode AI webview back to the prior (figlet-style) mark to avoid the Monaco rendering artifact, and updates the CSS/webview test to stop asserting an untrue “full blocks only” rule while preserving layout and accessibility checks.
Changes:
- Restore the previous multi-line wordmark in the chat empty state (media/chat.html).
- Remove the “full blocks only” glyph guard from webviewCss.test.js, keeping container-fit + a11y assertions.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| extensions/levelcode-ai/test/webviewCss.test.js | Drops the incorrect “full blocks only” assertion; keeps width/height bounds and role/aria-label checks. |
| extensions/levelcode-ai/media/chat.html | Replaces the empty-state <pre.lc-ascii> art with the prior wordmark content. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Sorry, something went wrong.
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.
The wordmark from #82 shattered into disconnected bars in the editor. This reverts it and installs a mark that does not depend on the font filling its character cells.
What went wrong in #82
I claimed the art "cannot develop seams in any monospace font" because it was drawn entirely from █.
Half the reasoning was sound — ▀ above ▄ does leave a full cell of gap, and I verified that. The conclusion did not follow: whether █ FILLS its cell is a property of the FONT, not of the character.
My harness ran SF Mono, so it looked perfect everywhere I checked — and none of those checks were the editor.
Why this mark survives
It asks for neither property that failed:
Verified before shipping this time, which is the part I skipped: rendered in Monaco, SF Mono, Menlo, Courier New, Andale Mono, Consolas and the generic fallback, plus the real empty state in Monaco in both themes. Legible in all seven; Monaco leaves hairline gaps at the frame corners and nothing else.
The two numbers are one number
The mark is 32 columns where the old one was 41, so the container-query factor moves with it: clamp(5px, 3.6cqi, 13px) → clamp(5px, 4.6cqi, 13px).
41 × 3.6 and 32 × 4.6 both land the mark at ~88% of its container. The test now pins that relationship rather than either number, because changing the art without the factor is exactly how this breaks — widen it and it overflows, narrow it and it becomes a stamp floating in white space. The failure message reports the computed fill percentage.
The old guard is gone
It required "full blocks only", encoding the false belief as a rule. It would have blocked this fix and waved through the bug it was written for. That is worse than no test, and the replacement says plainly that ASCII art has to be looked at in the target font — a static test cannot do it, so it no longer pretends to.
Guards
Each bypass-verified by reverting the fix:
33 tests in webviewCss, 34 suites green.