That reminds me of the hilarious talk "The Birth & Death of Javascript" where everything get converted to asm.js, even operating systems.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Webkit.js
71–80 of 106 posts
Re: Webkit.js
#72I thought it was a static rendering, but then I put in a marquee tag and it moved flawlessly across the screen. Impressive. I can't say I see the practical implementations of this, but I'm sure there's some. But it's impressive nonetheless.
Rendering HTML to WebGL textures would be big, which I think this could do - though probably not as performantly as the browser could. It's currently not possible, partially due to security concerns if I remember right.
It renders to Canvas, so it should be already possible; three.js even already conveniently allows creating texture from a canvas:
var texture = new THREE.Texture(theCanvas);
texture.needsUpdate = true; //refreshes the texture from the source canvas
Re: Webkit.js
#73Earlier quoted context omitted.
That's not a solution for the general problem of getPixel + iframes though. Here, I'll give a simple example. Let's say there's a site that uses cookies to track logins. For example, hacker news. Now, hacker news does have the X-Frame-Option Deny, but let's assume it doesn't. So to figure out my hacker news username, all you have to do now is create an iframe with hacker news, and then getPixel on the area of the fra…
There's no reason you couldn't apply the exact same "same origin policy" to elements (iframes, images, etc) when rendering into a bitmap.
You could, but it would change scope a little. Right now, it's reasonable to expect that information will not be leaked to external servers, but user interactions can be faked.
On an information only webpage (no user interactions) there's no need to have the X-Frame-Options to remain secure. If there's a way to access the data in that frame suddenly, that changes the necessity of that header.
Re: Webkit.js
#74Earlier quoted context omitted.
Rendering HTML to WebGL textures would be big, which I think this could do - though probably not as performantly as the browser could. It's currently not possible, partially due to security concerns if I remember right.
Awesome idea! I've seen tricks where CSS 3D transforms were used to position the entire DOM within a scene rendered in Canvas, but that approach is extremely limited. [0] Theoretically, now you could render the DOM to a texture instead of to the screen and do some sweet deferred rending. == Edit == Looks like one of Mozilla's Distinguished Engineers blogged about the technique. [1] [2] The creator of emscripten used…
One of the drawbacks with rendering DOM content to a Canvas/WebGL texture is that interactivity is lost in the process. At the very least an intermediate layer would have to be created that pipes scene input into DOM input.
The nice part about CSS 3D transforms is that interactivity is maintained, and it's still hardware-accelerated. A fantastic example of this was made by the creator of Three.js over a year ago:
http://mrdoob.com/lab/javascript/threejs/css3d/
As you said above, there are severe drawbacks with that approach. It is very limited in terms of what's possible compared to a traditional 3D scene. Moreover, since CSS 3D transforms are essentially DOM content rendered to a texture, rasterization occurs, and as such there isn't clean scaling, even with SVG content.
Re: Webkit.js
#75Pretty cool. There's been a push to make HTML run everywhere, but this proves you can make X run on HTML. Maybe someday we'll code apps in Objective-C/Java that run in the browser, all inside a canvas.
We're closer than you think! https://developer.gnome.org/gtk3/stable/gtk-broadway.html http://www.youtube.com/watch?v=fr8eo4RlPw4
And also emscripten-qt:
http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...
Re: Webkit.js
#76Earlier quoted context omitted.
What exactly are iOS users missing in Safari, in your opinion, that they would get from Firefox? I can see that Chrome has some cool sync features if you're into that sort of thing. But it still uses WebKit. And from what I've observed, people seem happy with the "Chrome" app in the app store, even though it uses a handicapped renderer. (Although in iOS 8, it won't be handicapped anymore, and will be as powerful as n…
Most iOS devs aren't clamoring for alternative browser engine implementations because they're happy with the objective C runtime. Web developers shouldn't be happy with only having one browser implementation available because there's no competition on iOS. Safari on iOS can lag in features and not care because there is no competition on iOS. Chrome on iOS offers nothing in the way of additional html5 APIs and is just…
> Chrome on iOS offers nothing in the way of additional html5 APIs and is just a new UI on the same old Webkit (to my knowledge).
No, they forked Webkit due to all the browser related #ifdef's they had scattered across the source code. They were diverging to much and damaging the quality of the code.
https://en.wikipedia.org/wiki/Blink_%28layout_engine%29
Edit: They're still pretty similar, though.
Re: Webkit.js
#77Earlier quoted context omitted.
Most iOS devs aren't clamoring for alternative browser engine implementations because they're happy with the objective C runtime. Web developers shouldn't be happy with only having one browser implementation available because there's no competition on iOS. Safari on iOS can lag in features and not care because there is no competition on iOS. Chrome on iOS offers nothing in the way of additional html5 APIs and is just…
> Chrome on iOS offers nothing in the way of additional html5 APIs and is just a new UI on the same old Webkit (to my knowledge). No, they forked Webkit due to all the browser related #ifdef's they had scattered across the source code. They were diverging to much and damaging the quality of the code. https://en.wikipedia.org/wiki/Blink_%28layout_engine%29 Edit: They're still pretty similar, though.
Chrome on iOS doesn't use Blink because Apple doesn't allow it.
Re: Webkit.js
#78FirefoxOS will host Safari / Chrome apps, before iOS will allow a Firefox. Open FTW.
What exactly are iOS users missing in Safari, in your opinion, that they would get from Firefox? I can see that Chrome has some cool sync features if you're into that sort of thing. But it still uses WebKit. And from what I've observed, people seem happy with the "Chrome" app in the app store, even though it uses a handicapped renderer. (Although in iOS 8, it won't be handicapped anymore, and will be as powerful as n…
Safari in iOS is missing many newer APIs. For example WebRTC is not in Safari but it is in Chrome/Firefox. No idea if it's been added to iOS8. Even WebGL in iOS8 is currently hobbled.
http://codeflow.org/entries/2014/jun/08/some-issues-with-app...
Also it's not a matter of "clamoring". People have no idea what they're missing. Do you think anyone would have been clamoring for Firefox on Windows in the 90s for they had never seen it and were limited to IE?
Maybe I'm showing my bias here but remember the browsers before Chrome and V8 came on the scene and heated up the competition? Well there's no competition on iOS because you can't write your own browser. Heck, I'd certainly like to see ASM.JS on iOS as one example.
Re: Webkit.js
#79I've been watching this project hoping that eventually PDFs could be rendered on the client.
Re: Webkit.js
#80I've been watching this project hoping that eventually PDFs could be rendered on the client.
You can do that today already using toDataURL() https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE... to convert canvas to image and then use jsPdf http://parall.ax/products/jspdf to convert that image to pdf