Status
What works today
Implemented means code in this repository and a passing test that exercises it. Partial means part of it exists and the page says which part. Planned means designed and not built.
The HTML and CSS path
| State | Item |
|---|---|
| implemented | Running a Dioxus app written with HTML elements in a headless blitz-dom document (HtmlDom), with your stylesheets resolved by Stylo |
| implemented | Layout: block and inline flow, flexbox, grid, tables, position relative, absolute and fixed, z-index, min-width: fit-content, box-sizing |
| implemented | Decorations: background colours, borders per side, corner radii, box-shadow, opacity, visibility |
| implemented | Overflow: clipping, and scroll containers on either axis |
| implemented | Backgrounds: linear and radial gradients, background images, object-fit, through an app-supplied ImageResolver; nothing is fetched |
| implemented | Text: inline runs, white-space, text-transform, letter-spacing, generated content, with a replaceable TextMeasurer |
| implemented | Events: clicks with bubbling and the browser defaults; input, change and submit; select, checkboxes, radio groups, labels; uncontrolled fields |
| implemented | Keyed lists, a display-list diff and a plan diff that report only what changed |
| implemented | Theming with custom properties and prefers-color-scheme |
| implemented | <script> is never run |
| implemented | Box layout within 1px of VS Code for 324 of 326 boxes in three workbench regions, with VS Code's text sizes (dioxus-compose/tests/fr34_box_tolerance.rs, measured 2026-10-03 on macOS) |
| implemented | Eleven examples in samples/, each tested on the Host against hand-worked layout and through the same calls a renderer makes |
| partial | Drawing HTML screens on screen. The plan of drawing elements exists; the bridge that hands it to compose-rust's renderer (its AbsoluteBox) is not built, so nothing is drawn yet (#43; the bridge is written and waits for review and a build in #67) |
| partial | Text measured by Compose. Your measurer sizes single-font text; mixed fonts, table cells and form controls are measured by Parley. The synchronous measure call is being built in compose-rust (#43) |
| partial | CSS transforms: translate works; rotate, scale, skew, matrix() and transform-origin are not drawn (#46) |
| planned | CSS transitions and animations: opacity, transforms and colours in the renderer (#46); width, height and margins through the Host (#47) |
| planned | Keyboard events and focus on HTML screens, and following a system colour scheme change while running; both come with the renderer bridge (#43; written in #67; keys other than Enter, key release, focus gained and a system scheme event need compose-rust first) |
| planned | Zooming HTML screens the way VS Code does, starting from the system text size (#58) |
| planned | HTML and widgets on one screen (Mixing the two) (#59) |
The Compose widget path
| State | Item |
|---|---|
| implemented | The widget set, modifiers, events with key consumption, the uncontrolled TextField |
| implemented | LazyColumn and LazyRow windowing: the renderer asks for a range and the Host builds only that |
| implemented | Seven design systems behind one role-based contract, unified or following the host platform |
| partial | Streaming text: appended tails coalesce per frame, and there is no rsx!-level API for them |
| planned | The Markdown crate dioxus-compose-markdown, Markdown to widgets with streaming (#24; a draft in #68) |
Platforms for the widget path
The renderer and its builds are compose-rust's. What has been shown on each platform:
| Platform | State | Shown by |
|---|---|---|
| macOS (arm64) | implemented | Used by hand, Korean input included; one file with no Java runtime |
| Android | implemented | Sample apps run on an emulator |
| Web (wasm) | implemented | A screen draws in a browser and clicks reach Rust |
| Windows, Linux | partial | Build and start in CI; not used interactively |
| iOS | partial | Builds and starts in a simulator smoke test |
FAQ
- Can I bring my Dioxus web app?
- Its
rsx!and CSS are what the HTML path takes, so the screens lay out. They are not drawn until the renderer bridge lands, and anything that calls browser APIs or JavaScript has no counterpart here. - Does it run JavaScript?
- No. A
<script>element is inert. Behaviour is written in Rust. - Is there a webview anywhere?
- No. CSS is computed in Rust by blitz-dom, and Compose draws the result.
- Is it on crates.io?
- Yes, version 0.0.1, with both paths, on compose-rust 0.0.1. The 0.0.x releases are early and the API will change; see Getting started.
- Do I need Kotlin?
- No. The renderer arrives prebuilt through compose-rust, and your code is Rust only.