rails-markup 1.4.6 update
Released on 2026-08-24. Toolbar settings are now user-visible in the UI, the FAB is smaller by default, and the dashboard Close action behaves correctly outside the split-panel layout.
status: released · version 1.4.6 · source: nauman/rails-markup
What changed
| Area | Update | Why it matters |
|---|---|---|
| Toolbar settings | Added a visible settings control in the toolbar and persisted settings per endpoint. | UI preferences now override init-time defaults in a predictable way. |
| Toolbar size | Reduced the default FAB footprint and updated size labels. | Less visual weight; better balance on dense pages. |
| Toolbar badge | Moved the count badge to the panel toggle. | The FAB stays simpler and the panel affordance is clearer. |
| Dashboard close | Close now returns to the dashboard outside the split layout instead of blanking the page. | Avoids a dead-end full-page interaction. |
Usability audit
Strengths
- The primary annotation action remains one click away.
- The settings control is now always visible, so configuration is discoverable instead of hidden behind the panel.
- Runtime preferences persist per endpoint, which matches how the gem is normally mounted in multiple apps or environments.
- The toolbar still keeps a compact surface: one FAB, one panel toggle, one settings control.
Watch items
| Item | Audit read | Recommendation |
|---|---|---|
| FAB / panel balance | Good after the split. | Keep the FAB focused on annotation mode only; do not reintroduce auto-open behavior. |
| Settings density | Moderate. | If more options are added, group them into sections so the panel does not become a long list of chips. |
| Mobile spacing | Acceptable, but tight on small widths. | Re-check the 32px/36px/40px variants on 320px-wide screens. |
| Discovery of settings | Fixed. | Keep the gear visible in the always-mounted toolbar cluster. |
JavaScript collision audit
What is already good
| Surface | Current protection | Result |
|---|---|---|
| DOM scoping | Toolbar elements live under #rm-toolbar-root. |
Host pages are unlikely to collide with internal controls. |
| Naming | Internal IDs/classes are consistently rm-*. |
Reduces clashes with host CSS/JS. |
| Menu behavior | Custom menus avoid native <select> controls. |
Host enhancers like select widgets are less likely to rewrite the toolbar DOM. |
| Storage | Annotation state and toolbar settings use separate namespaced localStorage keys by endpoint. | One app’s settings do not clobber another’s. |
| Event handling | Toolbar interactions use delegated handlers on the toolbar root where possible. | Limits accidental interference with host DOM. |
Remaining collision risks
| Risk | Severity | Notes |
|---|---|---|
| Global document listeners | Medium | The toolbar still binds some document/window listeners for keyboard, scroll, visibility, and Turbo lifecycles. That is intentional, but it means the runtime must keep strict teardown discipline. |
| Host CSS leakage | Low | The toolbar is already heavily namespaced, but any future unscoped selectors should be treated as a regression. |
| Duplicate embedding | Low | If a host accidentally mounts the toolbar twice, the singleton guard should prevent duplicate roots, but the guard should stay tested. |
| Shared endpoint settings | Low | Settings are endpoint-scoped, so two mounts that intentionally share an endpoint also share preferences. That is by design, but it is worth remembering. |
Release summary
This release is a usability-focused polish pass:
- configuration is discoverable in the UI,
- the annotation FAB is less visually heavy,
- the dashboard close action is no longer a dead end,
- and the toolbar is still isolated enough to coexist with host app JS and CSS.
source: nauman/rails-markup · release v1.4.6 · audit note
Addendum
The installer now prompts for a nested prefix before /rails-markup when --mount-path is omitted. That keeps the code path honest for hosts that want /admin/rails-markup, /dashboard/rails-markup, or no prefix at all.