41 comments

[ 4.2 ms ] story [ 56.1 ms ] thread
Soon we’re gonna need Canvas rendering inside of HTML-in-Canvas
I see reliable rich text editing as more of a priority.
I read the title and said "shut the fuck up, don't do that." but then I read the rationale and it's fair. It's true there is no layout engine inside canvas, and that is a pain, but I'm not sure it's such a pain as to invite this recursive hell.
I immediately got "Pimp My Ride" vibes. Yo dawg, I heard you like HTML so I put HTML inside the canvas inside the HTML.
I suppose all we need to do now is to compile a browser into WASM and run that browser inside a canvas element of the main browser…
true horror is finding every element of the HTML page your on has been rendered in a Canvas
Sad to say, but the first thing I thought was "oh good, a new fingerprinting target."
This sounds really useful for being able to use standard web technology with webxr.
This could have a great utility, but for me HTML in canvas in HTML feels so cursed.

To make it make sense in my opinion canvas should already be a first class format for web browsers, so it doesn't have to be inside a HTML.

Then we would have a choice of HTML-first page with canvas elements in it, or a canvas-first page with HTML elements in it.

But what do I know.

From the very beginning in Sciter an Image can be constructed in two ways at runtime ( other than just getting loaded image reference):

1. By painting on it using Canvas/Graphics API:

    new Graphics.Image(width, height, painter(graphics) [,initColor]);  
Where _painter_ is a function used for paining on the image surface using Canvas/Graphics reference.

2. By making snapshot of the existing DOM element:

    new Graphics.Image(width, height, element [,initColor])
Such images can be used in DOM, rendered by other Canvas/Graphics as also in WebGL as textures.

See: https://docs.sciter.com/docs/Graphics/Image#constructor

I feel like this is bound to get kneecapped for the same reason as other canvas features, fingerprinting.
There is a real problem using canvas to replace HTML.

Not all but most HTML. I have not found a good solution for the issue of doing something like MDX in canvas. I have tried SDF, looked at 2D canvas Text, Troika, MSDF. You can get text, it is just that laying it out is very difficult. React three drei has the ability to put HTML into the threejs ecosystem, but there are issues about CSS and text that make that impractical.

For me the use case is very simple. I would like to take an MDX file and show it in a mesh. Laid out. Maybe I am missing something because I am new to the whole threejs thing, but I really tried.

A good article about text https://css-tricks.com/techniques-for-rendering-text-with-we...

And an example from the above article: https://codesandbox.io/p/sandbox/css-tricks-msdf-text-fks8w

This shows it can be done, I gave up trying to reproduce it in React-three-fiber.

Why? Personally, I think the use of 3D graphics produces an interface for users that is an order or magnitude better for users. The real question (and an interesting one to consider) is why are we still building HTML first websites?

Is that being made to make Flutter not being like Flash on the web?
I support this, as odd as it is. There’s times when you’re needing something drawn but can easily reuse an html element from elsewhere. Previously you’d have to render that to a bitmap offscreen and then copy that to a full screen quad or draw it on the canvas. Up until recently, even if you tried to z-index elements with position absolute it would be visually overwritten by the canvas (I think this is mostly fixed though).

I don’t know if this is the best solution but it’s better than previous hacks. IF you need to go that route. Basically html2canvas.

Where does SVG's `foreignObject` fit into this? It seems that SVG supports all of thelproposal already? As is evidenced by projects like https://github.com/zumerlab/snapdom that can take "screenshots" of the webpage by copying the DOM with inlined styles into a `foreignObject` tag in an SVG. Then of course that SVG can be rendered to a canvas.
How about a flag on the body element like:

    <body canvas="true"></body> 
This would make the entire visible page into a canvas-like drawing surface which also renders DOM elements as per usual. At some level there's a process which rasterizes the DOM - opening drawing APIs into that might be a better solution.

It's sort of the same thing as HTML in canvas conceptually, but architecturally it makes DOM rendering and canvas rendering overlapping equals with awareness going both ways. E.g., a line drawn on the page will cause the DOM elements to reflow unless told to ignore it.

Can it just be CSS on canvas - so you can do styling and layout nicely but not weirdness of an html sandwich?