Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Webkit.js

trevorlinton.github.io

Post reply on HN
Print view View original

81–90 of 106 posts

Re: Webkit.js

#81

Post by bastawhiz »

dag11 wrote: post #7

I 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.

At some point, it won't matter whether your browser supports a particular feature of the web. Any site could just embed a copy of WebKit for browsers that are too old (i.e.: when the latest version of Firefox is a few dozen versions behind) and render the page using the latest rendering engine.

Re: Webkit.js

#82

Post by benjaminjackman »

rl3 wrote: post #74
ndesaulniers wrote: post #11

Earlier quoted context omitted.

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: htt…

Here is another really good one: http://mrdoob.github.io/three.js/examples/css3d_periodictabl...

Re: Webkit.js

#83

Post by mantraxC »

I remember when for some reason people started writing SVG and HTML engines for Flash. Because, I don't know. They wanted to put a browser in your browser, so you can browse while you browse.

The engines worked, but where are they now? Nowhere. Just like Flash.

No matter how much effort you put into something, no matter how functional it is, now matter how much geek cred you'll get for it, if it doesn't have some sensible use, at least superficially, it'll linger and die. Wasted effort.

Just because you can do something...

Re: Webkit.js

#84

Post by brianchu »

rl3 wrote: post #74
ndesaulniers wrote: post #11

Earlier quoted context omitted.

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: htt…

This is http://famo.us 's approach. A JS framework built on the idea of positioning everything only using CSS 3D transforms.

Re: Webkit.js

#85

Post by notastartup »

ndesaulniers wrote: post #42
notastartup wrote: post #38

this is pretty cool but network requests and javascript support would make it even more crazier. I viewed the html source for this page and pasted it. I was quite impressed. It looks like this is supposed to be a browser engine written in Javascript? So essentially we would have a sandbox browser within a browser? That would be awesome.

> javascript support would make it even more crazier There's interesting research being done in the area of meta-circular interpreters. There's techniques for speeding them up; they're not as slow as I'd expect. For example, one interpreter can do type analysis and rewrite chunks of code.

another interesting question would be will webkit.js support single origin policy? basically, what if you could use webkit.js like an iframe but with the ability to execute javascript and manipulate that window.

Re: Webkit.js

#86

Post by tlrobinson »

euank wrote: post #73
tlrobinson wrote: post #67

Earlier quoted context omitted.

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.

I'm not sure what X-Frame-Options has to do with it. I'm suggesting either not allowing rendering of bitmaps containing different origin iframes/images, or blanking out those elements in the rendering. Canvas does exactly that by not allowing different origin images to be drawn into a canvas element.

Re: Webkit.js

#87

Post by wycats »

pornel wrote: post #65
atonse wrote: post #59

Earlier quoted context omitted.

I agree on principle. Many of us still have emotional baggage from the days of 95% IE market share, where the web really, REALLY sucked. But nowadays, I see it as, multiple companies have a vested financial interest (including MS with their new leadership) to ensure that browsers are very powerful. Even Apple, with iOS 8 has enabled 3rd party devs to have a full speed browser now with a JIT'd JS engine. They are simp…

> There's nobody out there saying "I won't use iOS because it only has Safari." FWIW, I said it and did it. I didn't like Safari, and I couldn't change the default browser to anything better. Even worse, most 3rd party apps used their own utter-crap in-app browsers instead. So I switched to Android where I have freedom to set my preferred default browser, and 3rd party apps actually respect that. I do agree with the…

> FWIW, I said it and did it.

Same.

Re: Webkit.js

#88

Post by jgraham »

comex wrote: post #62
euank wrote: post #55

Earlier 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…

Any reason you couldn't just outright black out any pixels covered by different-origin iframes?

Even some same-origin things, for example input type=file, which can reveal paths on the local filesystem, would have to be blanked out.

Re: Webkit.js

#89

Post by chuable »

emilsedgh wrote: post #61
grimtrigger wrote: post #58

Pretty 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.

That would be a sad day. Layers upon layers of complexity, abstraction, technologies, etc. Please make it easier. More simple.

Our entire modern day computing experience is built upon 'Layers upon layers of complexity, abstraction, technologies, etc.';Simple and easy doesn't necessarily mean less.

Re: Webkit.js

#90

Post by anon1385 »

ndesaulniers wrote: post #52
anon1385 wrote: post #49

Earlier quoted context omitted.

Having to convince users to install your fork of the OS really isn't the same thing as being able to run a different native browser alongside their existing software. If the only way to use a browser other than Internet Explorer had been to switch OS then Firefox could never have been created in the first place.

How is that any different than with native code? You can't just rip out your OS' implementation of libc and have all of your programs use another (not all implementations of libc are ABI compatible). You can't boot your computer into two operating systems at once (or can you?). This whole post is analogous to running Windows in a VM on Linux.

>How is that any different than with native code?

On an open platform I have a choice of web browsers. On a Javascript sandbox based browser-OS I don't have any choice.

>You can't just rip out your OS' implementation of libc and have all of your programs use another (not all implementations of libc are ABI compatible).

I'm not talking about using a different browser engine to run local apps. Obviously there are going to be platform specific APIs that mean things won't be compatible (unless of course Google and Mozilla agree on a set of APIs and don't implement any vendor specific ones at all, but that is highly unlikely since it would mean killing backwards compatibility with current ChromeOS and FirefoxOS apps).

I'm talking about being able to use a different browser stack to browse the web. FirefoxOS makes it impossible to do (with any kind of respectable performance) but it's trivial on a native open platform.

>You can't boot your computer into two operating systems at once (or can you?). This whole post is analogous to running Windows in a VM on Linux.

This is just a silly semantic argument. You are defining the web browser stack as part of the OS just to avoid the awkward reality which is that you have totally locked out all other browsers from your platform. It doesn't make sense to run two kernels (unless you are doing things with a VM) because the role of the kernel is to talk to the hardware. That isn't the role of the browser stack, so there is no reason at all to only allow a single browser stack to run at a time. It's quite possible to run several, which is of course trivially demonstrable on an open platform like GNU/Linux or Windows. If you really want to make analogies, it is more like running a second windowing system. Some OSs like linux make it possible to swap your window manager, others like OS X don't. But the most important thing is that on either you can always just run native software full screen and draw whatever windows you want with no performance penalty (which in this analogy is akin to being able to just browse websites using a third party browser stack, but not being able to run the local apps using it).

Post reply on HN