Hacker News Reader

Comment by Toshio | Hacker News Reader

Correct me if I'm wrong. If a web developer is hell-bent on detecting ie, they could look for the presence of the activex API (like jQuery currently does in order to provide a uniform AJAX interface).

View on HN

Of course. They're not trying to make it impossible to detect IE. They're trying to make sure that all the "IE mode" quirks and workarounds out there in the wild don't get triggered on IE11 and break things.

Basically, they're moving to a standards-compliant model like WebKit or Gecko and they want to take advantage of all the standards-compliant layouts that developers are producing. But the only way to do that is to break with the past and not support all the madness inherited from legacy IE versions.

> Basically, they're moving to a standards-compliant model like WebKit or Gecko

I think that was the professed and proclaimed goal for every IE version since 8, or maybe even back at 7? I keep hearing that for years, and what this intention delivers in the end is yet more "IE modes":

n "browser modes" times 2 "document modes". Quirks mode. "Compatibility view."

So for IE 11, web developers would have two choices: test your page in a total of 10 IE mode-combinations. Or just serve "the Crawler/Geocities version of our site" to IE users no matter what version they're using.

Which is of course what MS/IE wants to avoid. But hey they could just pull an "Apple Inc." and license WebKit, or pull a "Google Inc." and make your browser auto-updating. Without prompts, progress indicators or restarts, just as invisible and efficiently as Chrome does by default. Presto, no more headaches with IE for BOTH users AND web devs. Maybe some MS egos would get a little dent, maybe some enterprise consultancy shops would have to cut down on man-days sold for IE-specific work. Ah yes. I can see why IE won't go this way any time soon---or only way after it has been finally and fully obsoleted even in the remotes of backwater net-cafes and even the slowest of Enterprise-IT depts...

Couple of corrections.

- Apple didn't license WebKit. Apple created WebKit, by forking Konqueror's engine.

- Chrome doesn't update without restarting. (Unless you mean restarting the machine, in which case, of course not! What kind of browser would require a machine reboot to... oh.)

> Apple didn't license WebKit. Apple created WebKit, by forking Konqueror's engine

Of course, you're right. I was typing this faster than I was thinking..

Anyway, MS shouldn't even think of pulling something like this, on second thought---because rather than a render-engine replacement, it would end up as yet another "mode" in IE..

> Chrome doesn't update without restarting

Of course the binary cannot replace itself while running -- ((although with each tab being its own process and their highly persistent statefulness they might consider silently "rebooting" background tabs)) -- but, well at my end / from my experience, Chrome doesn't restart itself and doesn't prompt about restarting, in most cases -- rather seems to wait until the next time it is restarted by the user. Maybe I get that wrong, but if my memory recalls this as Chrome's auto-update user-experience, that's a feat one way or the other..

Chrome will display an update arrow on the menu/address bar. If you haven't restarted in a while, it will eventually become a rather insistent red.

Wow, you mean you've had the patience and lack of ADD to wait a certain period of time without clicking the arrow? You're zen, my friend :)

Well, remember that the IE components are global system files that require at least restarting Windows Explorer and often a reboot to update and all versions of IE follows the lifecycle of the underlying version of Windows. I have proposed rapid release IE in the past but it'd have to be separate from the current IE installation.

Presto... :(

How does taking advantage of standards-compliant layouts requiring breaking the past?

I mean, if they're truly standards-compliant layouts, then they shouldn't be doing anything that requires that old stuff, and therefore they shouldn't be affected whether that stuff stays in or not. Or maybe I'm missing something.

Don't get me wrong, it sounds like it's headed in the right direction, but to me, at least, it's more about forcing crappy older sites to update their stuff than anything else.

You're missing the point. If they're truly standards-compliant and they "look like" IE6, then they'll get the IE6 layout the site author added and miss out on the new features. So IE11 will look bad and crufty no matter how good it's engine is. The point here is to make it "Look like WebKit" or "Look like Gecko", so that site designers don't try to support old IE versions.

This is explicitly about getting more sites to work /without/ forcing older sites to update their stuff. Older sites have ifIE() checks that return true and serve IE old legacy IE-specific code. IE11 is more compatible with standards-compliant code than legacy IE-specific code so forcing existing sites to serve IE the same code as FF/Chrome results in more sites working in IE.

> they're moving to a standards-compliant model like WebKit or Gecko

This will be great if they:

(a) actually achieve parity with Webkit or Gecko

(b) Don't try to maintain backward compatibility with previous authored-for-IE pages/sites

However, most of the browsers they've released since announcing their intention to move towards a standards-compliant model didn't meet those goals.

Maybe they'll get it this time. Or maybe this will be like Lucy, Charlie Brown, and the Football.

I don't see why B is important as long as A is the goal.

The point is to avoid being detected as IE by _existing_ websites, which typically do extra work to display nicely for IE, and that won't necessary anymore, hopefully.

The only correct and 100% reliable way to identify IE should a web dev need to, is to look for the 'Trident' token in the UA String.

Reply on news.ycombinator.com