{{ message }}
Repository navigation
fix(desktop): put the unsaved dot back on the left of the title bar path (#5467) - #5468
Merged
Merged
Conversation
…ath (#5467) `div.title > span` carries `direction: rtl` so that an over-long path clips from the left and leaves the filename readable (the GH#339 workaround). The save dot used to be the last child of that RTL block, and an empty atomic inline is a neutral: under an RTL base direction a trailing neutral resolves to the paragraph level, which laid the dot out at the visual left of the line. #5317 wrapped the breadcrumb in `<bdi dir="ltr">` to stop the Bidi algorithm reordering numeric path segments, and carried the dot into the isolate with it. Inside an LTR isolate the dot is simply the last item in logical order, so it moved to the right of the filename — a user-visible change that was never the point of that PR. Lay the title out with flexbox instead: the dot becomes a flex item preceding the breadcrumb, and the RTL clip context moves onto the `.path` box alone. The dot is back on the left, #5317's isolation is untouched, and because the dot now sits outside the clip box an over-long path can no longer swallow it — as it did before #5317. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…5467) Neither property had a guard: #5317 could move the dot without a test going red, and the Bidi ordering it fixed was never pinned either. Geometry is the only honest assertion here — the layout falls out of the Unicode Bidi Algorithm and of overflow clipping, neither of which jsdom computes — so these specs drive the real app under Playwright and compare boxes: the dot left of the first path segment, the dot still inside the clip box when a long path is truncated, and numeric segments in path order. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
Build artifacts for PR #5468: Run: https://github.com/marktext/marktext/actions/runs/35476604551 |
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.
Fixes #5467.
What moved, and why
div.title > spancarriesdirection: rtlso an over-long path clips from the left and leaves the filename readable (the GH#339 workaround). The save dot used to be the last child of that RTL block, and an empty atomic inline is a neutral: under an RTL base direction a trailing neutral resolves to the paragraph level, so it was laid out at the visual left of the whole line.#5317 wrapped the breadcrumb in
<bdi dir="ltr">— the right fix for the Bidi algorithm reordering numeric path segments (~/notes/2024/09/18/report.mdrenderedreport.md › 18 › 09 › 2024) — and carried the dot into the isolate with it. Inside an LTR isolate the dot is simply the last item in logical order, so it landed right of the filename. Themargin-right→margin-leftswap in that PR is the same change seen from the CSS side.The fix
Lay the title out with flexbox: the dot becomes a flex item that precedes the breadcrumb, and the RTL clip context moves onto a dedicated
.pathbox. #5317's isolation is untouched, and since the dot now sits outside the clip box, an over-long path can no longer swallow it — which it did before #5317.Before / after
Measured by rendering each revision's real template +
<style scoped>in Chromium:develop2024 › 09 › 18 › report.mdorder18 09 2024✗2024 09 18✓2024 09 18✓Real app, unsaved document:
Tests
packages/desktop/test/e2e/issue-5467-save-dot-position.spec.ts— the layout falls out of the Unicode Bidi Algorithm and of overflow clipping, neither of which jsdom computes, so the specs drive the real app under Playwright and compare boxes:Verified red on
develop(dot at x≈834 with the first segment at x≈366) and green with the fix.titlebar-selection-word-count.spec.ts,tabs.spec.tsandlaunch.spec.ts(17 tests) still pass, and the no-fileMarkTexttitle stays centred.🤖 Generated with Claude Code