Roadmap

[nicoburns]

Milestones

0.1 Alpha (June 2025)

Initial crates.io release representing 18 months of work.

• Support for calc() values in CSS styles.
• object-fit and object-position properties.
• background-size, background-position, and background-repeat properties.
• Move DOM updating logic into blitz-dom
• Event handling refactor
• WGPU texture rendering (<canvas> support)
• Grid layout: named lines and areas

0.2 Alpha (Oct 2025)

• Incremental box tree construction (and other performance improvements)
• CSS Animations and Transitions
• WGPU 26
• Run WPT tests on every PR

0.3 Alpha (Dec 2025)

• Support for non-local z-index
• Floats (Implements CSS Floats (float and clear properties) #265)
• Nested documents (enables: browser UI, iframes)
• Devtools: Layout inspector
• border-collapse: collapse
• Intrinsic sizing keywords (min-content, max-content, fit-content())
• Direction
• position: fixed
• position: static

Backlog

The backlog is tracked in individual issues for each area of the engine:

• Tracking: Rendering #238
• Tracking: Layout and Text #256
• Tracking: Optimizations #255
• Tracking: Event handling #257
• Tracking: Form controls #258
• Tracking: Images and media (excl. SVG) #259
• Tracking: SVG support #260
• Tracking: Devtools & Automation #261
• Tracking: Accessibility #262
• Tracking: Architecture #263
• Tracking: Networking #273

DOM

• <title>
• <meta> refresh
• Details/Summary
• Popover API
• <template> elements
• Shadow DOM

Dioxus Native integration

• Integrate with CLI
• Better event handling (prevent default, generated events)
• Low-level access to DOM

HTML/Markdown renderer ("readme")

• List bullets rendering
• Checkbox rendering
• Live reload
• Clickable links
• Syntax highlighting
• Packaged/published binaries

Archived Roadmap Items

Architecture

• Rename crates
• Split "wrappers" out of dioxus-blitz crate

DOM

• Non-root viewport scrolling
• net crate for faster/async networking
• Web font loading (needs: net crate + fontique improvements)
• Background images (loading + rendering)
• Text input
  • Mouse selection
  • More hotkeys
  • Multiline input

[savanesoff]

Hi 👋

Really interesting project! 🚀

Very silly question: Does the browser run JS?

This would be very useful for running web apps on an embedded devices, like STBs, Vehicle Infotainment systems etc... where browser bloat is a HUGE issue!

Many companies take off-the-shelf Browsers like Chromium (bloated) or Cobalt (out of date entirely, but trimmed down) to develop Web apps (react, svelt based) with a heavy use of JS.

If not, is it in the cards?

[nicoburns]

Very silly question: Does the browser run JS?

If not, is it in the cards?

@savanesoff It's not a silly question. The answer is that no it doesn't, but that it might be on the cards.

Architecturally we are setup for a JS engine (or engines!) to slot in (and we do already implement event handling and dynamic DOM updates) It's not a development priority for us in 2025 (we are prioritising the "core" renderer and the dioxus and rust APIs), but it could become one later (or sooner if there is an interested party that could bring development resources to work on the feature).

[Aworldc]

Very silly question: Does the browser run JS?
If not, is it in the cards?

@savanesoff It's not a silly question. The answer is that no it doesn't, but that it might be on the cards.

Architecturally we are setup for a JS engine (or engines!) to slot in (and we do already implement event handling and dynamic DOM updates) It's not a development priority for us in 2025 (we are prioritising the "core" renderer and the dioxus and rust APIs), but it could become one later (or sooner if there is an interested party that could bring development resources to work on the feature).

I am looking at doing this with boa, but I'm very new to the project and am having a hard time locating the rust apis that I could build it on. Like I found blitz_html::HtmlDocument.as_mut<BaseDocument> and blitz_dom::BaseDocument.query_selector but that's it.

[nicoburns]

I am looking at doing this with boa, but I'm very new to the project and am having a hard time locating the rust apis that I could build it on. Like I found blitz_html::HtmlDocument.as_mut<BaseDocument> and blitz_dom::BaseDocument.query_selector but that's it.

You could take a look at the dioxus-native crate. That's the code we currently have that does the most around dynamic updates and interactivity. But yes, there's a lot that would need to be built out to make this work. Including, I believe, reference counting for DOM nodes.

[Aworldc]

I am looking at doing this with boa, but I'm very new to the project and am having a hard time locating the rust apis that I could build it on. Like I found blitz_html::HtmlDocument.as_mut<BaseDocument> and blitz_dom::BaseDocument.query_selector but that's it.

You could take a look at the dioxus-native crate. That's the code we currently have that does the most around dynamic updates and interactivity. But yes, there's a lot that would need to be built out to make this work. Including, I believe, reference counting for DOM nodes.

Ah cool, will have a look at.

[guivieiras]

Hey!

I'm currently using Dioxus to build a desktop app that uses <video> tags, but on linux the overall webkit2gtk experience is very underwhelming. Plus having different webviews between OSes wll always lead to inconsistencies.

I spotted this project and was wondering about the current plan for media elements:

• Roadmap timing: Is built-in <video> / media playback targeted for the 0.3 Beta or more likely post-Beta?

• blitz-media crate: The backlog mentions splitting media decoding into a blitz-media crate. Should we understand that as the path toward supporting <video> / <audio> elements?

• Interim guidance: If full <video> support is still a ways out, what's the recommended workaround today (custom native player, decoded frames to <canvas>, platform video widget, etc.)?

Thanks! Amazing progress so far!

[nicoburns]

@guivieiras I think the issue to track here is gfx-rs/wgpu#4386. You could also look at this Bevy issue (bevyengine/bevy#5221) which links a few possible solutions. Audio is easier. You shouldn't need Blitz support at all for that. You can just use a Rust library for playing audio (e.g. https://github.com/RustAudio/rodio).

Your options today are:

• Somehow decode frames to a WGPU texture and use the Blitz support for displaying it from there.
• Use a winit child window. Render the video to that window's surface. Position the window in the correct place.