Release 0.0.2-beta.2

[liuyingjierun]

Ships the portable renderer, and corrects what the registry and the site were
saying about this project.

Added

• Window frames for a portable block, via renderPortable(…, { frame }). header is jsray-wp's own title bar — bold filename on the left, language on the right — so a block copied from the site and a block the plugin rendered read as the same product; macos is the three dots; minimal is a hairline strip. title and label fill them, and the chrome's colours are computed from the palette with the same arithmetic the plugin's stylesheet does in color-mix(), rather than a second set of colours that would drift. A frame costs 490 bytes for the hairline, 750 for the title bar and 1,060 for the dots.
• renderPortable() — HTML that carries its own styling. A third consumer of the token stream, beside render() and the terminal's ANSI writer, for the case a plugin cannot reach: code pasted into somebody else's site, where class="tk-keyword" resolves to nothing because jsray.css was never loaded. Every colour is written inline and the container carries its own background, padding and monospace stack, so the block depends on nothing outside the string it returns. Rich-text editors that strip <style> blocks and class attributes generally keep inline style, which is the whole basis of it — though what any particular destination allows is worth testing before relying on it. Two limits come with the approach rather than the implementation: the theme is fixed when the string is produced, so a pasted block cannot follow the destination's light/dark setting; and it costs about 40% more than the class-based form, roughly twelve times the source, which is nothing to paste and a lot to serve.
• A page to use it, at /paste.html. Pick a language, palette and mode, and copy. The copy carries both text/html and text/plain, so pasting into a code editor gives the original source rather than a screenful of markup.

Fixed

• A host styling code no longer shows through the block. The inner <code> carried its declarations at normal weight while the <pre> around it carried !important, and code { background: … !important } is one of the most common rules a blog theme ships: it painted a band behind every line, and its colour showed on any token the palette leaves unstyled. Both elements now take the same weight.
• An unframed block draws its own edge. On a host whose background is close to the palette's, a borderless rectangle had nothing to say where it started.
• A portable block now outranks the host stylesheet. Inline styles beat anything a destination writes at normal weight, but an author's !important beats inline — and themes ship pre { white-space: pre-wrap !important } to stop code scrolling on phones, which reflows the block and destroys its alignment. The container's own declarations carry !important for the 70 bytes it costs. Token colours do not by default; renderPortable(…, { important: true }) extends it to them, for about a quarter more bytes, and is worth reaching for only when a destination's CSS reaches into spans.
• The clipboard fallback writes the string, not the browser's idea of it. It used to select an offscreen contenteditable and let execCommand serialise it — but a selection is serialised from computed styles, so 2612 bytes of renderer output arrived as 6934 with 57 copies of a host declaration baked into the spans. It looked right, which is why nobody would have reported it. Intercepting the copy event and calling setData puts the exact string on the clipboard.
• highlightAll() no longer overwrites a portable block. The auto-scan matches pre > code, which is exactly the shape renderPortable() produces, so a portable block sharing a page with JSRay was re-rendered in class form — losing every inline colour on any page without jsray.css, which is most of the pages this feature exists for. The block now marks itself data-jsray-portable and the scan skips it. The failure hid well: on the paste page the class rendering picked up the site's own stylesheet and looked plausible, and because the scan runs once at DOMContentLoaded, editing the code afterwards repainted it correctly. A destination that strips data attributes still falls back to being re-highlighted in that site's palette — wrong, but legible.

Changed

• The palette fallback chain has one implementation. applyThemeToRoot carried the only copy of it; resolveToken is now shared with the portable renderer, because two renderers resolving the same palette by two implementations is how they come to disagree about a palette that predates a token key.
• The site build ships themes/ and the new page. The paste page fetches every palette at runtime for the same reason the Studio does — a second copy of the colours is a second thing to drift.
• The README says what the integrations are, because npm shows this file. The published page for @jsray/core@0.0.2-beta.1 still lists all three as "Coming soon"; all three are public with releases, and the table now links each one and says where it can actually be installed from — which is GitHub rather than its host's directory in every case. npm freezes a package page per version, so a correction only reaches the registry by publishing.
• repository and bugs point at the organisation's current name. They were published as github.com/JSRayCore/JSRay, which still redirects — but the frozen metadata is what every tool reads, and the org name it names no longer exists.
• The versioning doc says why Core counts its betas. It justified the counter mechanically — check:versions wants it, version_compare() orders it — which is true and is not the reason. Core is the kernel every integration renders through, so it earns more revision rounds before 0.1.0 than anything built on it, and those land inside one patch. The integrations bump the patch each time, so a counter would say nothing.

---

Install

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	jsray	59db547	Commit Preview URL Branch Preview URL	Sep 05 2026, 03:58 PM