The HTML-in-Canvas API origin trial
30 points - yesterday at 7:54 PM
SourceWouldn't it make more logical sense to add canvas to html elements? I.e. checkbox.getContext("2d").fillRect(...)
Not if you need your html to adapt to the shape of a 3d object drawn in the canvas.
What you described is the CSS painting api (part of CSS Houdini)
I guess there are uses for that, but as a web game developer, that wouldn’t really help me. The killer feature is input and text rendering.
I would use it to render HTML elements such as inputs or a website in videos. Even though HTML is powerful the control over every pixel is important for high quality videos.
Back in the WebVR days the sentiment was we can never do this because security.
In my experience with standards bodies/Chrome, anything outside of the owning company's product goals is "no, because security", and then then they flip-flop on that when the browser feature becomes a dependency for something an internal team is working on (which happened many times with WebVR, now WebXR).
So I'm curious what is Google working on that has this as a dependency, now that they've 180'd on it?
"Security" is usually not a binary, but how much money you are willing to spend to figure out a way to do it securely. It shouldn't be surprising that chrome spends more resources on things that have a business case than things that do not.
thomasikzelf
today at 7:01 AM
This had to do with leaking privacy sensitive information such as visited links by reading back pixels from a rendered <a>. They fixed this with a concept they call "read-back-allowed rendering"
chews
yesterday at 9:42 PM
Yo dog, we put a DOM in your Canvas in your DOM.
Of course, the natural question is "Can you put a Canvas in the DOM in the Canvas in the DOM?"
Here's hoping for it being DOM-in-Canvas all they way down.