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

The birth of Microsoft's new web rendering engine

blogs.msdn.com

Post reply on HN
Print view View original

91–100 of 247 posts

Re: The birth of Microsoft's new web rendering engine

#91

Post by frik »

ethomson wrote: post #64
kibwen wrote: post #49

> the new engine began as a fork of MSHTML.dll but has > since diverged very quickly Curiously, this means that Spartan will still be able to trace its lineage back to 1992's NCSA Mosiac (in contrast to Mozilla's Servo, which is a greenfield project). I expect that it will be fascinating to compare the two projects as each matures.

To be pedantic: even if there is code from MSHTML.dll in Spartan, there's no code from NCSA Mosaic in MSHTML.dll. Internet Explorer originally licensed Spyglass Mosaic , which licensed the name (and the code) from NCSA, but did not actually use any of the code. Though I suspect that there's not actually any Spyglass Mosaic code left in IE these days. (Edited, I said that there's no MSHTML.dll code in Spartan. That I…

Up to IE6, the about dialog mentioned Mosaic licensed code. There are UI related glitches (mouse pointer and scroll related code) in IE8 that were never fixed since Mosaic. There is still a lot of UI code and API related stuff from IE3 in IE11.

Re: The birth of Microsoft's new web rendering engine

#92

Post by exprE »

stephenr wrote: post #66
leeoniya wrote: post #7

Earlier quoted context omitted.

if you're not detecting on the client (via javascript), then you have to rely on headers. well, maybe via IE conditional comments + cookie setting on transparent pixel request

the point is you should be doing feature tests, not browser tests.

In an ideal world, perhaps. Sadly, in the real world, a browser seemingly supporting a feature doesn't mean it gets it right, and not all features can be detected by testing.

Re: The birth of Microsoft's new web rendering engine

#93

Post by amelius »

Here's an idea for an architecture that doesn't suffer from compatibility problems ever:

- Every web site refers to the bytecode for its required render engine

- This engine is loaded in an intelligent/cached way, and run in a sandboxed environment whenever the website is visited

- Since the website picks its own render engine (or provides its own), the developers of the website know for sure that it will render the website correctly

- Besides the render engine, also the scripting language could be referenced/provided in the same way.

An architecture like this could boost the proliferation of open-source render engines and in-browser languages.

Re: The birth of Microsoft's new web rendering engine

#94

Post by TazeTSchnitzel »

amelius wrote: post #93

Here's an idea for an architecture that doesn't suffer from compatibility problems ever: - Every web site refers to the bytecode for its required render engine - This engine is loaded in an intelligent/cached way, and run in a sandboxed environment whenever the website is visited - Since the website picks its own render engine (or provides its own), the developers of the website know for sure that it will render the…

so, Java, then

the problem with bytecode is you lose virtually all the benefits of the web

it's also not novel: you can do this today with JS, and your users will hate you because it can't be indexed and you can't select text

Re: The birth of Microsoft's new web rendering engine

#95

Post by amelius »

johnkchow wrote: post #74

This interoperability-focused approach brought the obvious question of adopting an existing open-source rendering engine such as WebKit. While there were some advantages, upon further investigation it was not the right path forward for two important reasons. First, the Web is built on the principle of multiple independent, yet interoperable implementations of Web standards and we felt it was important to counter move…

I just wished we could put on top of our HTML something like:

or something along those lines.

Re: The birth of Microsoft's new web rendering engine

#96

Post by Throwaway90283 »

EdSharkey wrote: post #15

YES! 1-2-3-4, I declare a browser war! Finally. This is the Microsoft I've been waiting for! No more rolling over and no defeatist talk of adopting WebKit or whatever. Microsoft is going to use its muscle and position to make a truly competitive browser. We need more competition, and we need the default browser in Windows to be just as good as Chrome and Firefox. Microsoft, I hope you pull every -ms- vendor flaggin',…

I'd like to see some competition as well, but in my perspective, they're taking the wrong approach.

This entire project seems to be about improving compatibility with older websites, by adding more algorithms and layers to the rendering process. I don't believe everyone is using Firefox and Chrome because they have better compatibility than IE.

I think they should focus on cutting the fat, and making the lightest weight, fastest and standards compliant browser possible, with some popular third-party add-ons available, such as ad block. Or, leave IE11 as the default now for compatibility, and spin off a new browser called IE Lightning.

If people start to switch over, then more sites will be developed to work in IE Lightning.

In short, create a faster browser with a smaller memory footprint and ad block, get users, watch compatibility fix itself, then make this ship as the default browser in 5 years.

Re: The birth of Microsoft's new web rendering engine

#97

Post by jonathansampson »

pdknsk wrote: post #14

It doesn't matter unless they make it open-source or at the very least cross-platform. I'm not downloading a 4GB VM from http://modern.ie to try it.

We created http://remote.modern.ie so you can stream Internet Explorer to your Mac. Even to your iOS device :)

Re: The birth of Microsoft's new web rendering engine

#98

Post by amelius »

TazeTSchnitzel wrote: post #94
amelius wrote: post #93

Here's an idea for an architecture that doesn't suffer from compatibility problems ever: - Every web site refers to the bytecode for its required render engine - This engine is loaded in an intelligent/cached way, and run in a sandboxed environment whenever the website is visited - Since the website picks its own render engine (or provides its own), the developers of the website know for sure that it will render the…

so, Java, then the problem with bytecode is you lose virtually all the benefits of the web it's also not novel: you can do this today with JS, and your users will hate you because it can't be indexed and you can't select text

This approach doesn't need to depend on Java. It would preferably use a minimal, non-garbage-collected VM, or something along the lines of NativeClient (or simply asm.js initially).

"It can't be indexed" happens to hold for a lot of websites that are basically single-page web-apps and which build their contents from within javascript. Fortunately, Google and others are using AI techniques to index pages. No need for special markup, or special structure.

Text-selection can be built into the render-engine of choice. Granted, this is not a guarantee that it will work for all websites, but even today you can turn off text-selection for a website, so you don't have that guarantee now either. Also, AI or OCR could help here. As an added benefit, it would allow one to even select text in an image.

Also note that this doesn't work so well in JS, because JS is not a multi-threaded language and it typically suffers from garbage-collection pauses. This is not good enough for UI work, unfortunately. And also not good enough as the target of compilers.

But, granted, to get this started, JS (or the asm.js subset) could be used initially (and be replaced later).

Re: The birth of Microsoft's new web rendering engine

#99

Post by munificent »

amelius wrote: post #95
johnkchow wrote: post #74

This interoperability-focused approach brought the obvious question of adopting an existing open-source rendering engine such as WebKit. While there were some advantages, upon further investigation it was not the right path forward for two important reasons. First, the Web is built on the principle of multiple independent, yet interoperable implementations of Web standards and we felt it was important to counter move…

I just wished we could put on top of our HTML something like: or something along those lines.

We just need to implement an HTML renderer (or two or three) in JS and then ship the renderer with your site.
Post reply on HN