Roadmap
Big ticket items
- [x] Interaction (hover/click) for inline spans
- [ ] Event handling refactor
- [ ] Nested documents (enables: browser UI, devtools, iframes, dioxus for form controls)
- [ ] Devtools
Bug fixes
- [ ] Fix known memory leaks
- [ ] Anonymous nodes
- [x] Parley font names
Blitz "core" improvements
- [x] Non-root viewport scrolling
- [x]
netcrate for faster/async networking - [x] Web font loading (needs: net crate + fontique improvements)
- [x] Background images (loading + rendering)
- [ ] Text input
- [ ] Mouse selection
- [ ] More hotkeys
- [x] Multiline input
- [ ] More form controls
- [ ] Accessibility: incremental updates
- [ ] Accessibility: react to events
Layout
- [x]
calcvalues - [ ]
position: fixed - [ ]
position: static - [ ] Direction and writing-mode
- [ ] Floats (taffy + parley)
- [ ] Table improvements
- [ ] border-collapse
- [x]
table-layout: fixed
Rendering
- [x] Box shadows (blocked on https://github.com/linebender/vello/issues/640)
- [ ] Raw wgpu shader
Dioxus Native integration
- [ ] Better event handling (all event types hooked up, prevent default)
- [ ] Integrate with CLI
- [ ] More form controls
HTML/Markdown renderer
- [x] List bullets rendering
- [x] Checkbox rendering
- [x] Live reload
- [x] Clickable links
- [ ] Syntax highlighting
- [ ] Packaged/published binaries
Archived Roadmap Items
Architecture
- [x] Rename crates
- [x] Split "wrappers" out of dioxus-blitz crate
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?
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).
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.
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>andblitz_dom::BaseDocument.query_selectorbut 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.
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>andblitz_dom::BaseDocument.query_selectorbut 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.
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-mediacrate: The backlog mentions splitting media decoding into ablitz-mediacrate. 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!
@guivieiras I think the issue to track here is https://github.com/gfx-rs/wgpu/issues/4386. You could also look at this Bevy issue (https://github.com/bevyengine/bevy/issues/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.
@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?