All notable changes to FrescoStrip are documented here. The format is based on Keep a Changelog and the project adheres to Semantic Versioning.
0.1.0 — 2026-05-24
Initial release. Extracted from fresco <= 0.5.9 where the same
component lived as Fresco.scroll_strip. Behavior is byte-for-byte
identical to the pre-extraction implementation — only the module
name and JS import path change.
Why a separate package?
- Keep
frescolightweight for the common viewer / canvas consumer (lightboxes, paged readers, document viewers, lookbooks) who never needed the strip's memory-windowing / per-image-overlay machinery. - Let strip mode iterate on its own release cadence — most strip- side changes don't touch viewer/canvas, and vice versa.
- Distinct mental models: viewer/canvas pan + zoom + rotate via CSS
transforms; strip is a flat
<img>list with native scroll. Two API surfaces, two changelogs.
Migration from fresco.scroll_strip
# mix.exs
defp deps do
[
- {:fresco, "~> 0.5.9"}
+ {:fresco, "~> 0.6.0"},
+ {:fresco_strip, "~> 0.1.0"}
]
end
# assets/js/app.js
import "../../deps/fresco/priv/static/fresco.js"
+import "../../deps/fresco_strip/priv/static/fresco_strip.js"
# template
-<Fresco.scroll_strip id="reader" sources={@pages} extensions={@ext} />
+<FrescoStrip.viewer id="reader" sources={@pages} extensions={@ext} />Three lines of consumer diff. Etcher (0.4.12+) detects the strip handle at runtime — no code change needed there.
Shared window.Fresco global
Both fresco and fresco_strip contribute handles to the same
window.Fresco.viewerRegistry. Peer libraries (Etcher annotations,
ML overlays, comment threads) call window.Fresco.viewerFor(id) /
onReady(id, cb) and get the right handle regardless of which
package mounted it. Order-independent — whichever package's JS
runs first creates the registry; the second piggy-backs.