Skip to content

Roadmap #119

Open
Open
Roadmap#119

Description

@nicoburns
nicoburns
opened on Aug 15, 2024

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 Beta (Estimated August 2026)

  • Nested documents (enables: browser UI, iframes)
  • Initial imperative DOM access (Dioxus onmounted)
  • Text selection + user-select style (desktop platforms)
  • touch-action style
  • pointer-events style
  • 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)
  • Custom Widget API
  • <details>/<summary> support
  • <iframe> elements
  • Scrollable text inputs #339
  • Overlay scrollbars
  • Transparent window backgrounds (all renderers)
  • Android
    • Back button support
    • App icon support (cli)
  • Scrollbar styling: scrollbar-width and scrollbar-color
  • Scrolling behaviour: scroll-behavior and overscroll-behaviour
  • Implement standard scrollTo, scrollBy, and scrollIntoView #703
  • Events
    • use_window_event hook for access to raw Winit WindowEvents
    • <body> and <html> 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, pointercancel)
    • Touch events (touchstart, touchend, touchmove, touchcancel)
    • Drag & Drop (blocked on Winit release)
  • Rendering
    • WGPU 29 upgrade
    • clip-path Support the clip-path property #211
    • mask
    • filter
    • backdrop-filter
    • Font embolden (stem darkening)
    • border-style + fixes for border-radius edge cases
    • Backgrounds for inline spans
    • Text decoration styles: text-decoration-thickness / text-decoration-inset / text-underline-style / text-underline-offset / text-underline-position
  • Layout
  • Text/inline layout
    • Better white space collapsing
    • vertical-align
    • text-overflow

1.0

  • Devtools (Chrome Devtool Protocol)
    • Element tree + element picker
    • View layout metrics
    • View specified styles
    • View computed style
  • Layout
    • position:sticky
    • min-content / max-content / fit-content() for min- and max- size styles
    • Improve Flow layout (Block/Float)
    • Improve aspect-ratio handling
    • Table layout
    • contain: size and contain: inline-size
  • Text/inline layout
    • line-clamp
    • text-wrap-style
  • Font enumeration / fallback
    • More reliable font-fallback
    • Ability to match against fonts that aren't loaded yet
    • font-display
    • @font-face descriptors
      • unicode-range
      • Ranges for weight/width/style
  • Rendering
    • background-clip: text
    • Text shadow
    • mix-blend-mode
    • Better filter support on Vello backends
  • transform-box
  • Shadow DOM & Custom Elements
    • Shadow DOM
    • Style encapsulation
    • Slots
    • Declarative shadow DOM
    • Custom element registry
  • Built-in elements
    • <meta> refresh
    • <base> (base url)
    • <picture> and <img srcset> support
    • <select> (drop down)
    • Range input (+ output/meter/progress)
    • Color picker
    • Password input (Password masking #482)
  • Events
    • Trigger events in response to programmatic DOM manipulation
    • Animation events
    • Clipboard? (cut, copy, paste)
    • Composition / IME?
    • beforeinput event
  • Custom Widgets
    • layout method
    • accessibility method
    • Smarter paint invalidation (request_redraw)
    • Pointer capture
  • Accessibility
    • Richer accessibility tree
    • Text layout / text input
    • Handling accessibility events

Backlog

  • Devtools
    • Network
    • Console
    • Edit/override styles
  • Test automation
    • Webdriver? Playright?
  • System compositor integration
  • "actually native" font rendering
  • JavaScript suport
  • C bindings
  • Dylib compiliation mode (for faster iteration)
  • 3D transforms
  • First-party SVG (stylable/animatable)
  • Layout
    • Table layout (not emulated with CSS Grid)
    • Subgrid layout
    • Grid Lanes layout
    • Anchor Positioning
    • Fragmented (paginated) layout
      • multi-column layout
  • Text/inline layout
    • Vertical text (writing-mode)
    • Padding/border/margin on inline spans
    • Better text-transform
    • Ruby
  • Custom Widgets
    • Network / resource integration
    • WGPU-specific API
  • Elements
    • Lottie widget?
    • Video playback
  • Top layer and Popover API
  • Multi-window support
  • Better component library support
  • Merge with Dioxus Desktop?
  • Low-level DOM access
    • RcDocument
    • Ref-counted node handles?
    • Read data from dirty document (requiring extra resolves)?
    • Custom event handlers?
    • Abstraction?

More tasks are tracked in individual issues for each area of the engine:

HTML/Markdown renderer ("readme")

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

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
  • <title>
  • Details/Summary

Dioxus Native integration

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

Activity

  1. nicoburns
    pinned this issue on Aug 16, 2024
  2. nicoburns
    added
    enhancementNew feature or request
    and removed
    enhancementNew feature or request
    on Jan 20, 2025

  3. savanesoff commented on Mar 10, 2025

    @savanesoff
    savanesoff
    on Mar 10, 2025

    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?

  4. nicoburns commented on Mar 10, 2025

    @nicoburns
    nicoburns
    on Mar 10, 2025
    MemberAuthor

    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).

  5. Aworldc commented on Mar 30, 2025

    @Aworldc
    Aworldc
    on Mar 30, 2025

    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.

  6. nicoburns commented on Mar 30, 2025

    @nicoburns
    nicoburns
    on Mar 30, 2025
    MemberAuthor

    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.

  7. Aworldc commented on Mar 30, 2025

    @Aworldc
    Aworldc
    on Mar 30, 2025

    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.

  8. guivieiras commented on Jul 17, 2025

    @guivieiras
    guivieiras
    on Jul 17, 2025

    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!

  9. nicoburns commented on Jul 20, 2025

    @nicoburns
    nicoburns
    on Jul 20, 2025
    MemberAuthor

    @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.

  10. cody-herbst commented on Nov 28, 2025

    @cody-herbst
    cody-herbst
    on Nov 28, 2025

    @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?

  11. umajho commented on Dec 29, 2025

    @umajho
    umajho
    on Dec 29, 2025

    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)

  12. nicoburns commented on Dec 29, 2025

    @nicoburns
    nicoburns
    on Dec 29, 2025
    MemberAuthor

    @umajho It will probably be a case of as well of, rather than instead. The composition event API is much simpler to implement and will probably still be the short-term target. I'd love the implement the EditContext API, but I think the Rust layer (Winit etc) likely needs more work before that will be possible.

    I would also note that the path for implementing a custom text editing control in Blitz / Dioxus Native may look more like implementing a custom Blitz widget that uses Rust-level system APIs directly rather than using a web API for that purpose. That is, Blitz isn't sandboxed like the web is, so in some cases we don't need to expose an API ourselves, we just expose the underlying system APIs (or abstraction from Rust crates).

  13. akongG commented on Jan 23, 2026

    @akongG
    akongG
    on Jan 23, 2026

    This is truly a great project. I'm looking forward to using it in future projects to enable the use of Dioxus on mobile devices without relying on webview

  14. Codys-Wright
    added 4 commits that reference this issue on Apr 17, 2026

    examples: add text-overflow fixture

    4af6c18

    paint: plumb TextTruncation struct into stroke_text

    694dc8d

    examples: add text-overflow fixture

    4038f0f

    paint: plumb TextTruncation struct into stroke_text

    9cfbd6e

  15. shao-kang commented on Jul 29, 2026

    @shao-kang
    shao-kang
    on Jul 29, 2026

    I am building a project that provides rquickjs bindings for Blitz. It currently supports only basic DOM creation. As Blitz continues to evolve, I hope we can work together to expand and improve the project. The project uses QuickJS as its JavaScript engine and Blitz as its DOM rendering and layout engine. A layered bridge between Rust and JavaScript is used to incrementally provide compatibility with commonly used browser Web APIs. Its key difference from traditional Web runtimes is that QuickJS and Blitz run on separate threads: JavaScript computation and task execution do not directly block the rendering main thread, preventing expensive JavaScript work from stalling layout, painting, and user interaction.

  16. jellybobbin commented on Oct 14, 2026

    @jellybobbin
    jellybobbin
    on Oct 14, 2026

    This is truly a magnificent innovation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions