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 (Estimated Mar/Apr/May 2026)

• Support for non-local z-index
• Floats (Implements CSS Floats (float and clear properties) #265)
• Box-level direction: rtl
• Nested documents (enables: browser UI, iframes)
• border-collapse: collapse
• Initial imperative DOM access (Dioxus onmounted)
• Text selection (desktop platforms)
• Winit 0.31 upgrade
• Mobile (Android/iOS) support #323
• Image cache
• Fix rendering CJK fonts on Apple platforms
• Delay rendering until critical assets have loaded (Fix FOUC)
• clip-path Support the clip-path property #211
• position:static and position:fixed
• min-content / max-content / fit-content()
• Events
  • Mouse events (dblclick, auxclick, mouseover, mouseout, mouseenter, mouseleave)
  • Scroll events (scroll, wheel)
  • Focus events (focus, blur, focusin, focusout)
  • Pointer events (pointerdown, pointerup, pointermove, pointerover, pointerout, pointerenter, pointerleave)
  • Touch events (touchstart, touchend, touchmove)
  • Drag & Drop
  • Clipboard? (cut, copy, paste)
  • Composition / IME?

0.4 Beta

• Scrollable text inputs #339
• Programmatic scrolling
• <picture> and <img srcset> support
• Multi-window support
• Merge with Dioxus Desktop
• Devtools
  • DOM tree
  • Layout
  • Computed style
  • Specified style view/edit
• Widgets
  • Custom elements / Shadow DOM
  • Custom Widgets
  • select / drop down
  • Password input
• Low-level DOM access
  • RcDocument
  • Ref-counted node handles?
  • Read data from dirty document (requiring extra resolves)?
  • Custom event handlers?
  • Abstraction?
• Accessibility
  • Richer accessibility tree
  • Text layout / text input
  • Handling accessibility events
• Test automation
  • Webdriver? Playright?

Backlog

• Text/inline layout
  • vertical-align
  • text-overflow
  • Integrated (Taffy/Parley) baseline alignment
  • Better white space collapsing
  • Backgrounds for inline spans
• Rendering
  • mask
  • background-clip: text
  • filter
  • background-filter
  • Font embolden (stem darkening)

More tasks are 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
• LaTeX / math rendering
• 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.

[cody-herbst]

@nicoburns Hello, I'm interested in helping out if you need an extra pair of hands. Happy to take on smaller or larger tasks depending on what you need. The events issue seems pretty cool if you need any help there?

[umajho]

Hello.

The 0.4 Beta milestone listed the Composition Event for IME support.
Since there is now a better API called the EditContext API, would you also consider implementing that API?

Data carried with a CompositionEvent are very limited. You can only extract a single string representing the whole editable text from the IME with it.
With the new EditContext API, you can get much more information. (such as where the cursor should be, how the editable text should be partitioned and what style each part should have)