DJMcNab
commented
3 weeks ago 47 covers some of our thinking on this; it is not plausible to support running Masonry on the web for any production application. This is because the web does not allow text input, accessibility, scrolling and text actions (among others, I'm sure) to work as users expect without using the DOM (which Masonry would not use). We do intend to make Masonry work on the web, for those demo use-cases. But we will absolutely make this same message clear; that the use cases for that support necessarily exclude "production software".
If you wish to use Xilem on the web, I would recommend using xilem_web, which is included in this repository, and does properly support the web by controlling DOM nodes. Please note however that xilem_web development is entirely community driven, you'd be welcome to contribute.
As an addendum:
Accessibility would be nice but is non-essential at this stage.
I would encourage you to rethink this position; the use of canvas/wgpu based drawing does not just make accessibility impossible "at this stage", it makes it implausible in the future. In my opinion, it is not possible to develop a "production" application with no possible path to accessibility, so the path you are intending to take might not be viable.
fr-an-k
It doesn't appear to be currently possible due to https://github.com/linebender/parley/issues/70 (fontique's dependency on SystemFonts).
I'm guessing there is currently no easy way to work around this or use an alternative fontstack.
I also had to add this to Cargo.toml:
I intend to use this for (new) production software, so I already assumed I need my own heavily modified fork and then reconcile later. I'll probably use mcsdf for 2D + 3D font rendering.
But WASM support (without or without javascript host) will be very important so there should be a case (and example) for it:
Accessibility would be nice but is non-essential at this stage.