refactor(dom): removes double buffering from DomBackend

[benoitlx]

Summary

This PR reworks the DOM backend to fix several bugs and simplify its implementation.

Details

• The new approach relies solely on the content provided to the draw function for rendering widgets and handling the cursor (hyperlinks are not supported yet).
• Removes the previous buffer and prev_buffer logic, reducing complexity.
• Fixes Bugs with Multiple Width Glyphs #135 for the DOM backend and makes feat(dom): multi-width unicode character support #121 obsolete.

Before	After

Test

• tested fullwidth glyph support with
  • modified demo2 example
  • kanash (benoitlx/kanash@db18a9d)
  • custom-test (https://github.com/benoitlx/ratzilla-test)
• tested cursor support with
  • user-input example
• simple test with
  • demo example

TODO

• fullwidth-glyph support
• cursor
• merge example from feat(dom): multi-width unicode character support #121
• hyperlinks support in order to fix Hyperlink in DOM backend does not update and disappears on window resize #137 (look at Deprecate Hyperlink widget #113 for direction)

Explanation

• rendering of the content:

  • Initialize the <span> elements once with the populate function (similar to the prerender function)
  • When new content is given to the draw function:
    • if it's a two width char render it and add width: 2ch to style attribute of the corresponding <span>, render a blank char to the following span with width 0.
    • otherwise just render the content

• resizing:

  • added a get_size function in utils.rs (that works like get_sized_buffer)
  • added a size field in DomBackend initialized to the output of get_size
  • reupdate the size so ratatui modify it's buffer size in the size function with get_size

• cursor:

  • added a last_cursor_position field to DomBackend
  • directly modify the style of the span at cursor_position and last_cursor_position

[orhun]

Nice, looking pretty good already. Let me know when this is ready for a review :)

[benoitlx]

I added the example from #121.

Also I removed this

if cell.modifier.contains(HYPERLINK_MODIFIER) {
    continue;
}

so that hyperlinks are rendered even if they are not supported after this PR. (the create_anchor function is unused for now)
If this PR is merged, I might submit another one to add proper hyperlink support.

I’m excited to hear your feedback!

[benoitlx]

Hi, let me know when you can review this. I have some time to work on changes if needed :)

[junkdog]

there's a slight perf regression - framerate is 10-15% lower

but also more stable framerate

[orhun]

Thanks for the PR!

I'm experiencing some issues while running this. (see the video that I attached)

[orhun]

I'm running from aeec0fe now and the unicode example looks like this (still):

Peek.2026-01-09.17-42.mp4

Only the DOM backend is a bit broken.

Environment:

• Mozilla Firefox 146.0
• rustc 1.94.0-nightly (f52090008 2025-12-10)
• trunk 0.21.14

[benoitlx]

I'm running from aeec0fe now and the unicode example looks like this (still):
Peek.2026-01-09.17-42.mp4

Only the DOM backend is a bit broken.

Environment:

* Mozilla Firefox 146.0

* rustc 1.94.0-nightly (f52090008 2025-12-10)

* trunk 0.21.14

Uhm, that's bad, I can't reproduce this issue. I'm using trunk and rustc with the same version you specified. However, I'm running Firefox version 146.0.1 (I can't install a specific version at the moment).

Do you have any other idea that can help me reproduce this bug ?

[orhun]

Okay I figured it out... nothing wrong with the code.

I had the Translate Web Pages plugin installed which automatically translates the Japanese characters which then breaks the layout...

I disabled the plugin and now it all works fine!

[benoitlx]

I disabled the plugin and now it all works fine!

Nice !

I will refactor the update_css_field function and write unit tests for it. I will request a new review when I'm done.

[orhun]

cool, thanks!

[orhun]

Looks pretty good!

Would love to get another review from @junkdog and it should be good to go :)

[benoitlx]

Everything should be fixed now, but let's see if junkdog will spot something :)
Thanks for your helpful review, Ohrun and Junkdog. It's not always easy to spot our own mistakes when writing code.

Also, no pressure, but when do you plan to publish the next release Ohrun?

[orhun]

Not sure, probably soon after we finish this one :)

[junkdog]

looking good!

[junkdog]

i noticed there's a very minor gap between full-size block chars

and blocks appear to overlap by a few pixels, but seemingly w/o breaking the layout anywhere.

i think both the above however are things that will be addressed once we have proper font handling for the dom backend.

[junkdog]

Also, no pressure, but when do you plan to publish the next release Ohrun?

i'm trying to wrap up beamterm 0.13.0 but it's maybe a week away.

[benoitlx]

i noticed there's a very minor gap between full-size block chars

Are the examples you are running available somewhere ?

i think both the above however are things that will be addressed once we have proper font handling for the dom backend.

Don't hesitate to ping me for things related to this backend in the future.

i'm trying to wrap up beamterm 0.13.0 but it's maybe a week away.

Nice !

[junkdog]

Are the examples you are running available somewhere ?

oh, that's just ratzilla's demo example.

Don't hesitate to ping me for things related to this backend in the future.

please do :) i don't think we have an issue for it (or maybe we do), i just know that canvas and dom backends have hard-coded fonts (and font cell metrics are more like guesses, but that might be partially fixed now).

it would be nice, if we in the future could just call Terminal::set_font(...), regardless of backend.