Hacker News new | ask | show | jobs
by ha1zum 324 days ago
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.
5 comments
bapak 324 days ago
I don't see a problem with what you're saying at all. For reference, you can already have HTML in SVG in HTML in SVG.

If you have a canvas-first page, where do you store the title? Right, in <title>, so

    <!doctype html>
    <title>My canvas site</title>
    <canvas style="fill all">
In reality they should really just allow content in the canvas element and call it a day:

    <canvas type="html">
        <h1>Canvassing</h1>
    </canvas>
link
ha1zum 323 days ago
> you can already have HTML in SVG in HTML in SVG

It's kind of different because SVG and HTML are both XML-like text-based format, doesn't feel that wrong to mix them together. Unlike with canvas..

link
koolala 323 days ago
Oh god that canvas h1 code looks so sexy. Imagine if a canvas could dynamically resize too.
link
bornfreddy 323 days ago
Yes - and maybe you could call it something else, for example... div? ;-)
link
chii 323 days ago
but then what's the point of the canvas here? Unless if it was possible to mix and match canvas painting operations seamlessly with the declared elements...
link
bapak 323 days ago
This post is titled HTML-in-Canvas, so you can find the point in the link. A lot of people just want the freedom of canvas rendering/shading and the flexibility of HTML/CSS. Current options may force you to create a layout engine from scratch for example.
link
koolala 323 days ago
Opening it in WebXR!
link
socalgal2 324 days ago
canvas first sites suck. They can't use any system services as it would all be a privacy issue. They can't use the system dictionary for correction since to do so they'd need the contents of the dictionary or at least a way to query user customized corrections. Similarly they can't offer the system level accessibility but end up having to roll their own in which case, every app that uses canvas has a completely different UI.
link
nemomarx 324 days ago
That's basically how flash sites worked, and those were pretty common?
link
desiderantes 324 days ago
They said that those kind of sites sucked. Common or not.
link
yjftsjthsd-h 323 days ago
Yes, and Flash sites had severe usability issues.
link
jonplackett 324 days ago
I think you invented Flash, though saying that embedding flash in harm as also a pain!
link
Liron 324 days ago
What if you want an HTML-first page with a canvas in it, but then you realize you want some layout/styling for the text within the canvas? Seems unnecessary to propagate that situation up to the type of top-level page.
link
thrance 324 days ago
And then what if you realize you need a canvas-in-the-html-in-the-canvas? It's endless. Canvas-first makes sense, it's basically how it works everywhere outside of the web. Start with the smallest abstractions and build on them (html on canvas) rather than leave escape hatches to your big abstractions because they fail to cover every use cases (canvas in html).
link
sitkack 324 days ago
If you support the DOM and hitscan, then it doesn't matter. You can red pill Ouroboros yourself all day and not care. Every element a canvas, every raindrop an ocean.
link
lenkite 323 days ago
Well, folks said NO to WASM DOM Access. So it was inevitable that this would happen.
link
8n4vidtmkvmk 323 days ago
Wait, is that never going to happen? I was so excited when WASM was first announced, but then lack of DOM access killed it for me. It was supposed to allow us to use any language instead of just JS.
link
flohofwoe 323 days ago
You can access the DOM from WASM just fine, you just have to go through a JS shim because the DOM is a Javascript API (just like WebGL, WebGPU, WebAudio and any other API available in browsers).

In most DOM access libraries (like https://github.com/web-dom/web-dom) this Javascript shim exists but is completely invisible to the library user (e.g. it looks and feels as if WASM would have direct DOM access).

Why this topic is always brought up I really have no idea, at this point it feels like trolling attempts because from a technical point of view 'direct DOM access from WASM" simply doesn't make a lot of sense. Accessing web APIs from WASM is an FFI scenario, no matter how you look at it.

link
lenkite 323 days ago
Actually DOM implementations are all in C++ and DOM interfaces are described in WebIDL. So direct DOM access from WASM is indeed possible if browser vendors chose to open the same. Access via a JS shim is just utterly destroying performance - orders of magnitude worse than mere FFI - and all the trolling attempts are the one pretending otherwise.
link
dfabulich 323 days ago
Browser vendors can't simply "choose" to open direct DOM access to WASM.

When defining standardized DOM APIs in WebIDL, WebIDL assumes that you can use JavaScript strings, JavaScript objects + properties, JavaScript Exceptions, JavaScript Promises, JavaScript garbage collection, and on and on and on. Almost all of the specification of WebIDL itself is about the dozens of types that it assumes the platform already provides. https://webidl.spec.whatwg.org/

WebAssembly doesn’t have any of those things. As a low-level VM, it supports only modules, functions, bytes, numbers (32-bit and 64-bit integers and floats), arrays (called “tables”), and opaque pointers (“reference types”).

No one has ever standardized a DOM API for low-level languages. You’d presumably need to start by defining a new low-level WebIDL design language just to define a low-level DOM API.

Defining WebIDL itself has taken decades.

Today, the browser vendors aren’t convinced that a new low-level DOM API is worth their time. It’s better to make existing JS web apps faster than it is to begin a multi-year (multi-decade?) project to make a new thing possible that could be better in the long run.

link
jauntywundrkind 317 days ago
There is a JS strings spec for wasm underway. https://github.com/WebAssembly/js-string-builtins

This feels so much like one of those cases where perfect is the enemy of the good. Node.js spent a decade being wrapped about the axle, convinced that cjs and esm could never work together. Ignoring that it worked great in standard-things/esm. But eventually Bun came around and that somehow made the case that all the hemming & hawing was nonsense all along, that doing nothing was worse than letting Fear Uncertainty and Doubt reign.

It just seems so unlikely that much of JS really matters for webidl. WebIDL specifies mostly structures and routes. It throws some exceptions but that doesn't seem particularly incompatible with wasm. WebIDL has promises, which is already pretty well solved by https://github.com/WebAssembly/js-string-builtins (which alas only Chrome seems to be moving on). GC is also in wasm now. I just don't get the defeatism. Fear Uncertainty and Doubt can be so seductive, anti-belief can be so fierce, and it sucks when things aren't perfect or when there's warts, but the paralysis here & anti-will seems so wildly disproportionately strong.

link
lenkite 323 days ago
There is the Web Assembly Component Model. Nothing is really preventing browser vendors from exposing a WASM host interface to DOM, exposing it as a Component Model interface. This would allow DOM functions to be invoked from WASM without hand-written/generated JS glue code.

Nobody is really calling for exposing the full-suite of WebAPI's. But basic DOM access allowing manipulation of page elements would be immediately leveraged by all the WASM-UI frameworks available today. Framework authors would throw out all the generated JS glue code which adds painful overhead pronto with great joy.

link