I would like to know from the IE team if there's a specific plan to fix the browser update issue, that is the fact that IE is by far the slower browser when it comes to user upgrades. It's exciting to see features in IE1x+, but we all know that those will be a tiny fraction of users for a long time.
I think that gaining consensus in developers' mindset goes through forcing updates like Chrome and Firefox do; don't care if it's monthly, quarterly or yearly, but users shouldn't even realize that an update was pushed to their machine. This model has shown that it works for browsers, and not only that, it has also proven to be the best model. Is there any actual actionable plan on this?
Adding new features in IE15 is fine and good, but won't buy a dime in developer consensus, when we still waste time supporting 5-years-old IE browsers at any given time.
Your info is out of date, as they have already fixed the browser update issue. Modern IE will automatically upgrade when new versions are released - you can see this by looking at the adoption rates for IE9 -> 10 -> 11.
However, there are still a lot of users on IE8 and below, which did not have auto updating. As people gradually migrate away from these legacy versions and get onto the evergreen track, then the situation should improve until IE's overall upgrade rates match those of Firefox and Chrome.
I don't see how this is fixed. According to StatCounter, IE shares are: IE8 6.7%, IE9 3.8%, IE10 4.0%, IE11 9.0%. IE10 is supposed to have an "install new versions automatically" option and yet still has close to half the share of IE11, and IE8+IE9 share is still greater than IE11 share.
I thought the "install new versions automatically" checkbox simply meant that new Internet Explorer updates were installed along with automatic Windows updates, where before they were optional.
If so, aside from enterprise, there's (sadly)a significant fraction of home users that turn off automatic Windows updates because they regard them as a hassle.
I'd argue that IE is primarily used in corporate settings, when silently upgrading software is a big no-no. Everything has to be tested by the IT/IS department and rolled out in a controlled fashion.
Last time I managed to find a study showing daily browser market share, I noticed that the drop for old IE versions during the weekend was significant but below 50%. So over half of those users are not corporate users.
I don't like citing numbers without a source, but I couldn't find one in 5 minutes Googling. If somebody has a link that shows fairly recent daily IE usage share, we can double check my recall.
I would also like to add that one technical solution for the "IE in enterprise" problem would be allowing parallel IE version installations. IE already allows to go into old version emulation mode, but it's not 100% faithful (I don't know the details).
If it was 100% faithful, sysadmin could simply update IE to the latest version for normal browsing (or even let it auto-update, since I'm sure no sysadmin believe that he/she can QA IE better than MS for general Internet usage), and forcing compatibility (through GPO) for Intranet sites that are broken in newer version.
But since it's not 100% faithful, the technical solution would be allowing to install an auto-updating IE in parallel to IE8, and then configure a policy to automatically switch to IE8 for Intranet sites (Chrome Enterprise does a similar thing; you can configure a GPO so that the user is automatically brought to IE when he/she browses to specific websites, e.g.: Intranet).
>I'd argue that IE is primarily used in corporate settings
I wouldnt make that distinction. While its probably true that some corporate users are still stuck on XP. Most non techy people I know (which is almost everyone) just buy a new laptop open it up and start using IE. They will probably never upgrade unless the computer tells them or does it automatically.
I would have agreed up to the past September, when Mavericks was released for free. Some big leaps in IE updates are tied to Windows upgrades, which are not free for users.
This has a direct reflect on Safari adoption. NetMarketShare gives these numbers for OSX adoption (which is the same of Safari version adoption):
10.9: 3.75%
10.6: 1.29%
10.8: 1.18%
10.7: 1.05%
So roughly half of OSX users are already using the last Safari version (which was released only 7 months ago), which is absolutely different from the situation you have with IE version adoption.
What would be the situation of IE version adoption, were Win7 a free upgrade for all WinXP/Vista users? I think we can agree that free operating system upgrade does have a measurable impact.
Nonetheless, I agree with the general point that Safari now sits in the middle between IE and Firefox/Chrome, and that's why I have not mentioned it in my original post.
I agree this is a pain, and IMO a bad mistake by Microsoft.
However, Windows XP was released in 2001, replaced (Vista) in 2007, reached end of mainstream support in 2009, and users have been warned it's going away for many, many years.
OSX Mountain Lion was released in 2012, replaced just a few months ago -- but now doesn't seem to be that much better off in terms of receiving updates to its bundled browser than Windows XP is.
Fair point. Microsoft has always been a lot better than Apple at protecting backwards compatibility. It's just a shame that they decided to use IE as a lever to push people toward newer Windows versions rather than doing what's best for the Web platform.
I wonder if a re-branding is in order. I suspect I'm not the only one who feels an inner discomfort with IE. I even associate the logo and name with thoughts like "outdated," "broken," "difficult," and "cumbersome."
I realize they've come a long way, but it's tough to shake off 10+ years of negative experiences and associations.
None of the things listed as "not currently planned" are big surprises, though seeing WebRTC there is very disappointing. I've never seen "Object RTC" before, is it a competing effort, or a restandardization effort?
Object RTC is developed by a community group at the W3C. It includes people from Google, Microsoft and a number of telecom companies, amongst others http://www.w3.org/community/ortc/
Microsoft had a competing proposal to WebRTC called CU-RTC-Web which, as far as I understand it, proposed to get rid of the Session Description Protocol (which is text-based and thus difficult to parse/edit) and provide lower-level APIs instead (details here: http://www.tokbox.com/blog/what-the-cu-rtc-web-vs-webrtc-deb...).
I've just started reading up on ObjectRTC but I believe it plans to offer an API to replace SDP too and Microsoft has moved to it since it's similar to their CU-RTC-Web proposal. All in all, it looks like this will delay the adoption of WebRTC everywhere but will be for the best in terms of API and developer experience in the end.
Those two things are... orthogonal? WebRTC is a transport for media and data streams, which looks somewhat like SCTP-over-DTLS-over-UDP. getUserMedia is a way to get a stream which can then be sent over a transport.
Not quite - getUserMedia is one part of WebRTC. If you use the 'full' WebRTC (i.e. RTCPeerConnection), you're tied into a certain architecture, which isn't generally useful if you already have a server architecture. getUserMedia is more useful in general for developing web conferencing solutions IMO.
I think a lot of browser developers (Safari/IE) are baulking at implementing google's WebRTC. I would hope they would at least offer getUserMedia even if they don't implement the full WebRTC.
If you've looked into WebRTC you'll see it is horrendously over-engineered. I was hoping to grab the AEC code, but gave up on that idea after looking into it in more detail.
I don't see over-engineering in WebRTC; I see the same assisted-peer-to-peer routing required to support the major use-cases of traditional SIP:
1. When people are within the same firewall, they want to be able to communicate directly without routing anything but connection set-up through any servers; and
2. when people are members of the same corporation or mobile ISP, but are behind different firewalls, they want to be able to communicate by routing through the corporation/ISP's shared pool of TURN servers, instead of your service's hosted TURN servers.
Did you actually get into the internals of WebRTC on your project? That is when you notice the overengineering.
In our product, our customers generally want the session recorded, which doesn't seem possible with WebRTC. Also we need to provide group video, which peer-to-peer isn't very useful for (in terms of efficiency).
That's not to say that WebRTC isn't useful in other use-cases (such as your product). However getUserMedia is more generic because it can be used in web conferencing products like ours. That is why I say that if browser developers don't want to implement the full WebRTC, they should at least implement getUserMedia.
Ah, now I see what you mean. I agree--getUserMedia is useful on its own, with or without WebRTC.
Personally, I do hope they implement the full stack, though, because WebRTC--or ObjectRTC--is useful on its own, too (this is why I was saying they were orthogonal.) WebRTC using pure Data Channels is wonderful for enabling things like BitTorrent-like data sharing and realtime LAN gaming, whether or not there's any videoconferencing going on.
I think the proposed changes are akin to the WebSQL early on, vs. IndexedDB stuff we wound up with. I think it just comes down to people looking at WebRTC and its' short comings as well as the earlier MS/IE proposals, and coming up with something that's probably better moving forward. It sucks in terms of actually getting next gen apps out... I want my Skype killer!
Note that this site lists WebGL as "IE11+". That's false. IE11 has a flavor of webgl that's experimental (prefixed or not) that's reported as version WebGL 0.92 (this is basically an invalid specification conformant string, it's either 1.0 or something not done).
Huge gaps and bugs remain in Microsofts WebGL implementation which make it nearly impossible to use except for specific select usecases that Microsoft optimized for.
It took google and mozilla about 4 years to get a good WebGL implementation (and they're still not done). It'll take Microsoft years to come to bring their implementation on par with the rest of the WebGL world.
We shipped an update to the IE11 WebGL implementation to developers today as part of Windows 8.1 Update. We will roll this out to all IE11 users through Windows Update starting next week. There will be further updates to our WebGL implementation in the summer.
If there are specific use cases that you're interested in support for, please let us know what they are so that we can prioritise the order of our implementation.
Another measure that's also very useful is to run the webgl performance regression test suite every day to see if performance got worse or better with the changes.
Unfortunately there isn't a comprehensive GLSL syntax test suite, but GLSL has been much of a sore point in IE where some syntax that's valid GLSL would work except in IE (such as uniforms separated by a comma).
I've submitted some tickets to IE (and added more conformance tests to cover them) for some of the gaps (gl.SAMPLES, gl.STENCIL_BITS, gl.SUBPIXEL_BITS).
A thing that's also a sore point is IEs lack of support for very common extensions such as OES_texture_float_linear, WEBGL_compressed_texture_s3tc, WEBGL_depth_texture, OES_standard_derivatives, OES_vertex_array_object, ANGLE_instanced_arrays, OES_element_index_uint, WEBGL_lose_context. You can get an overview of the state of support on http://webglstats.com/
A note on floating point texture extensions. If you implement one extension (for instance OES_texture_float) you should really implement the companion extensions as well for texture_float_linear and color_buffer_float. Only the triplet of extensions provides comprehensive overview of support.
I think the demos above are fairly good usecases for gaps that you might have, because they exercise a lot of functionality, they're not bound to some specific framework (like three.js) but they are WebGL conformant.
Thanks for such a fast reply! :) I'm quite happy with Microsoft's recent push towards openness.
One additional suggestion: Perhaps you could also include a rationale on why a specific feature is not planned to be implemented: e.g. WebRTC. (Though I can anticipate this might not be feasible to do for strategic / management reasons.)
Thanks for the link. I always found it hard to know what is happening in new versions of chrome and which feature became available when. This is exactly what I needed - Thanks!
Also found chrome dashboard easier to use than IE dashboard but that's understandable as this is new effort.
And, if anyone from IE team is here, how about some consistency with developer tools with other browsers as well. The web developer UI in IE 11 is so different that I struggle to found simple things - maybe I am not good in recognizing new icons :)
I'm bewildered by the many "under consideration" entries. When all the other major players support something, and you want to be taken seriously, why aren't you throwing more engineers at the problem?
If feature status were a Facebook relationship status, many might say "it's complicated." ;-) Most of the time, it's not actually a question of engineering resources. Stay tuned as we update more and more stuff to "In Development".
I'm curious--does this imply internal-politics problems (e.g. getting other departments to expose, and possibly backport, APIs that Chakra needs to consume to do the features), or just weird engineering challenges specific to the Chakra codebase?
I could see some conflicts of interest issues too. (e.g. implementing WebRTC could be against their interests - since Microsoft owns Skype, they might not want to lower the barrier of entry to a competitor.)
In the past when they've spoken about why they delayed implementation it was often due to security issues (e.g. Webgl) or due to the standards proposal not being mature enough and them being worried that supporting it would lock in a bad version of the spec because people would build code on top.
And here are some that they ship[1] that according to that page aren't in other browsers (or are listed as in development for one or more other browsers)
1. CSS Device Adaptation (@viewport)
2. CSS Scrolling Snap Points
3. Exclusions
4. Encrypted Media Extensions (only they and Chrome ship it)
5. Grid
6. IME API
7. Regions
8. Screen Orientation API
9. Streams API
10. Web Crypto API
[1] These are listed with a status of "Prefixed" on modern.ie/status.
Anyway, I think most of those aren't part of the w3c standards (yet). But I think it's good to see them publicly state their roadmap.
It's a good point. It makes it embarrassingly (for Microsoft) clear who the leaders are when it comes to browsers.
That said, despite Google's leadership in this area, Chrome's support of "new browser features" is often sloppy. They ship some features in quite broken states, and don't get around to fixing them until a lot later. The Chromium issue tracker has over 56,000 open issues. Google are going for quantity over quality when it comes to new features.
They are considering if they can skip some features just to retain some lock in, or competition is already too strong for them to do it. That's "under consideration". "Not considered" means they decided that competition is too weak yet and they can just skip that in order not to increase interoperability (for example WebRTC). Implemented features means they think competition has won and they have no choice but to go along even if they didn't want before (for example WebGL).
Can somebody on the IE team comment on when specific SVG features will be added? I am interested in using a <use> tag with a xlink:href to an element in a different SVG file. This is part of the SVG spec and works in the latest versions of Chrome and FireFox, but does not work in IE 11. Any plans to fix this?
This is somewhat misleading WRT to Flexbox. IE10 "supports" the abandoned syntax, which is incompatible with the new proposal. It would be very useful if this was explicitly mentioned in cases where the API for these things is in flux.
I still don't understand why IE still mark Content Security Policy (CSP) under consideration given all other major browsers (Firefox, Chrome, Safari and Opera) have at least some version of CSP implemented.
I am actually very surprised they don't yet have HSTS implemented. IE is so much behind these security standard IMO. I don't know why they would push Web Crypto into 11+ when they don't even have CSP or HSTS implemented yet.
Given the standard, they should have HSTS, then CSP, then Web Crypto and then subresource integrity (which will probably take another year or two to stabilize a final draft for v1).
If they do add that, they should specify VP8 and/or VP9 and/or Vorbis and/or Opus rather than just WebM.
The Opus audio codec, which was co-developed by Microsoft subsidiary Skype, would be useful both for WebRTC, and the alternative Microsoft favours, ObjectRTC.
VP8 and Opus both get mentioned in passing in the ObjectRTC spec that I found, but I don't know if they have the same status as in WebRTC (mandatory for Opus, optional for VP8)
Has the Irish domain registry lifted its rules on .ie domains? It used to be that you only register them for Irish businesses, even getting yourname.ie was not straight forward. It's a little disturbing to see this domain.
This is great. I realize that there are probably political hurdles to doing so, but it would be awesome if these linked to MDN in addition to MSDN / W3C / WebPlatform.
Yep, and we're already chatting with the Chrome team on how browsers can collaborate on this type of data. We encourage people to use our data too. It's openly licensed.
But Object RTC is under consideration. I believe (but don't quote me) that most of the efforts at the W3C are focused on this over WebRTC. Also, you'll notice that the IE team is taking a slightly more conservative approach to the new features. Since many features are still in draft mode and can significantly change, they're implementing features as they mature.
MS tried to sabotage mandating free codecs for standard real time communications, but W3C managed to put Opus in WebRTC. Not sure what's going on in parallel efforts in this regard but it's a pretty important issue and MS is on the wrong side in this one.
They are comparing IE to other real modern browsers - it's rather surprising to see. Like saying "The competitors are far ahead, here what they already do and we don't and out of that what we plan to do next and what not.".
There are only 13 features listed there not currently supported in IE and supported by Chrome, Safari, and Firefox. Of those, 4 are currently in development.
I think that gaining consensus in developers' mindset goes through forcing updates like Chrome and Firefox do; don't care if it's monthly, quarterly or yearly, but users shouldn't even realize that an update was pushed to their machine. This model has shown that it works for browsers, and not only that, it has also proven to be the best model. Is there any actual actionable plan on this?
Adding new features in IE15 is fine and good, but won't buy a dime in developer consensus, when we still waste time supporting 5-years-old IE browsers at any given time.