How long until a canvas is used to render the full chrome of a web browser (e.g. including the TLS padlock), showing a fake benign URL in the (fake) address bar while having the user interact with a malicious page?
Yes, but this "emergency" UI of the OS could be improved I think. (Also that functionality could have been build easily with normal DOM and JS, cancel and override all events, etc)
Seems like you have some pretty strong ranty bias there.
AFAICT, this is a web standard and expected to get buy in from Safari and Firefox before shipping to users. For now it's an experiment you have to specifically enable with flags. No different than any other browser that runs experiments
> AFAICT, this is a web standard and expected to get buy in from Safari and Firefox before shipping to users.
If it hasn’t already got buy in then it isn’t a web standard, it’s just a Google proposal. Something isn’t automatically a web standard just because Google thinks it’s a good idea.
Here are Mozilla and WebKit positions on this:
> This proposal attempts to solve multiple problems with a single solution. We (Mozilla) recognize the motivation for solving some of the problems, but believe that this is not the right solution to each problem, or in some case a step in the wrong direction.
Philip: First, google slides is written in svg, so that won't change with this. But google docs is using canvas, so they might be a candidate.
… they might want to integrate this peicemeal, this API allows them to start to adopt the feature slowly,
--- end quote ---
This reads to me like "Google Docs decided to go with canvas sometime ago [1], found it to be too hard, so pushed Chrome to have a way to support HTML in Canvas. The rest is just post-hoc justifications"
> his is a web standard and expected to get buy in from Safari and Firefox before shipping to users.
1. It's not a standard. It's a scribble on a napkin in a working group's repo: https://github.com/WICG/html-in-canvas Created and edited by people from Google.
2. Chrome continuously ships "standards" like this that they create with no buy in and against any and all opposition.
3. Neither of your links have any relation to HTML in Canvas.
I remember this repo a few weeks ago: https://github.com/remotion-dev/html-in-canvas
I wonder if it works in more than just Chrome Canary now.
How long until a canvas is used to render the full chrome of a web browser (e.g. including the TLS padlock), showing a fake benign URL in the (fake) address bar while having the user interact with a malicious page?
That's why we have "youtube.com is now full screen" message.
Yes, but this "emergency" UI of the OS could be improved I think. (Also that functionality could have been build easily with normal DOM and JS, cancel and override all events, etc)
Title should have been “html-in-canvas demos in gif on X”
I naively thought the “demo” was a demo, not a X posting by a twit.
non-twit links from page:
https://compiz-web.vercel.app
https://arrival.space/htmlcanvas
Wes isn’t a twit!
Tried this demo in Safari: https://arrival.space/htmlcanvas
Looks very cool, and showed a pretty message indicating there's even more:
Use Chrome... idontthinkiwill.jpg and aren't we supposed to reject these technologies that allow Google to Embrace, Extend, Extinguish[1]?Kudos to the artist in spite of this unfortunately esoteric (wish it weren't) concern
[1](hope I'm wrong about it being a triple E https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... )
Seems like you have some pretty strong ranty bias there.
AFAICT, this is a web standard and expected to get buy in from Safari and Firefox before shipping to users. For now it's an experiment you have to specifically enable with flags. No different than any other browser that runs experiments
Here's one from from Apple from 2017
https://webkit.org/blog/7504/webgpu-prototype-and-demos/
Here's another from last year
https://webkit.org/blog/17118/a-step-into-the-spatial-web-th...
> AFAICT, this is a web standard and expected to get buy in from Safari and Firefox before shipping to users.
If it hasn’t already got buy in then it isn’t a web standard, it’s just a Google proposal. Something isn’t automatically a web standard just because Google thinks it’s a good idea.
Here are Mozilla and WebKit positions on this:
> This proposal attempts to solve multiple problems with a single solution. We (Mozilla) recognize the motivation for solving some of the problems, but believe that this is not the right solution to each problem, or in some case a step in the wrong direction.
— https://github.com/mozilla/standards-positions/issues/1076
— https://github.com/WebKit/standards-positions/issues/630
As far as I can see, nobody outside of Google has committed to implementing this.
From the discussion linked in the Webkit repo:
--- start quote ---
Philip: First, google slides is written in svg, so that won't change with this. But google docs is using canvas, so they might be a candidate. … they might want to integrate this peicemeal, this API allows them to start to adopt the feature slowly,
--- end quote ---
This reads to me like "Google Docs decided to go with canvas sometime ago [1], found it to be too hard, so pushed Chrome to have a way to support HTML in Canvas. The rest is just post-hoc justifications"
[1] https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
> his is a web standard and expected to get buy in from Safari and Firefox before shipping to users.
1. It's not a standard. It's a scribble on a napkin in a working group's repo: https://github.com/WICG/html-in-canvas Created and edited by people from Google.
2. Chrome continuously ships "standards" like this that they create with no buy in and against any and all opposition.
3. Neither of your links have any relation to HTML in Canvas.
HTML-in-Canvas-in-HTML. Yo dawg.
Nah, you forgot the canvas.
I heard you like html-in-canvas demos, but what about canvas-in-html-in-canvas-in-html?
You broke the internet!
Flash is back baby!
In a significantly reduced, dumbed down and non-functional way