HTML5, Site-Ready and Experimental
As the technologies around HTML5 continue to develop, people need a better way to distinguish the more experimental parts of HTML5 from the parts ready for use in mainstream sites. The recent browser technology kerfuffle around WebSockets offers a clear example of the problem that developers and consumers will face again and again over support for emerging standards.
With many HTML5 technologies still under active development, our approach is to give developers better choices and avoid false dichotomies around standards support. The IE9 browser has site-ready HTML5 support that developers and consumers can depend on. We will also offer developers “HTML5 Labs” for more experimental technologies still under development. By clearly separating prototype implementations from mainstream browser product ones, we can avoid many negative consequences.
In the IE9 product, we’re delivering on the key parts of HTML5 that are site-ready. IE9 offers support for real-world web patterns that developers are using today as well as the HTML5 patterns we expect to become more mainstream. IE9 does this because we want to improve interoperability on the web by providing developers a consistent programming model through the same mark-up. The goal is supporting great new capabilities, ideally in a way that interoperates or will interoperate soon across browsers.
We will also offer prototype implementations for the more experimental or unfinished parts of HTML5 that some developers may want to try, but consumers can’t depend on yet. We will be explicit about the implementations that are more prototype than product. These prototypes are how we balance providing a product for millions of consumers while actively engaging in speculative technology discussions with developers and enthusiasts and avoid confusing either group. You can read more about that here.
In this post, we look at the pattern of putting unfinished technology into a product, the negative consequences of doing that, and our alternative approach for other HTML5 technologies that are still under construction today.
The WebSockets
First, WebSockets are a good idea.
They are both a technology and a set of standards that are under construction. They’re often included as part of the HTML5 discussion. With WebSockets, browsers and sites can do some neat things that are otherwise very hard, very slow, or not possible. You can see videos of some scenarios enabled at https://www.websockets.org/ – a site not actually related to any of the organizations working on the standard, but from a company that has some product offerings in the space.
Implementing a technology while the blueprints that describe it are still changing significantly causes many problems. In this section, we’ll use the experience of WebSockets to illustrate common challenges of under construction technologies. Below, through the transparency of Mozilla’s process, you can read for yourself how several different problems played out.
This is a view into the difficult discussions and decisions around a technology under construction: guarantees that websites will break multiple times between today and when the technology is finished, the security risks to people using the technology, and the challenge of listening to a lot of contradictory feedback.
Let’s look at bug number 602028 in Bugzilla, Mozilla’s issue tracking system. For people less interested in these details, this is a good place to skip ahead to the next section.
This bug was first reported 5 October 2010. The bug suggests initially that “while the final WebSockets protocol is sorted out,” Firefox should do “prefixing.” One of the first comments in the bug immediately stakes a position (of disagreement), and calls out the compatibility issue that developers will face writing sites that work across browsers with this technology under construction:
We most certainly should not… Prefixing in Gecko doesn't gain anybody anything… It only hurts us, because "Firefox doesn't implement HTML5". Comment 2
A subsequent comment cites the same facts – volatility and compatibility issues – as an argument in the other direction.
The reason that we want to prefix it is because we know, 100%, that it's going to change. We also know that other browsers will update it as well. We don't want it confused with… anything other than experimental and the best way to do that is prefix it as such.
The new version will not be compatible with existing implementations. Comment 7
Other comments go on to cite precedents for either course of action (here, and here), adding “WebSockets won't exit demoware status for a few years.” That’s a powerful comment about the pace of technology adoption. Cynically, the discussion goes on that “the who's-in-the-lead perception may trump all other considerations… We [Mozilla] are… constantly eating WebKit's dust. I would lay a bet we'll do it again here.”
A key point in the discussion is that developers “can be expected to expect their server's [sic] will break as new versions of WebSockets are implemented in browsers.” A Google employee working on WebSockets goes on to add “the best strategy is to just keep breaking people.” A Mozilla person responds with his concern that this
assum[es] that the developers will have the perfect knowledge of everything that's happening on the web, what the status is of various standards are and if things are going to change. Given my personal experience that's a dangerous assumption. Comment 27
That’s when someone brings up the security issue, and another person makes the observation that it might not be worth “being able to check-off another ‘HTML 5 support’ box on the marketing slides.” Someone goes on to say what the standard should do and that they should follow it, to which someone else responds:
That would be great. Except that there is no standard yet, just a series of working drafts, with incompatible handshakes, and no plan… that doesn't simply cause servers using older handshakes to barf on newer ones. Comment 73
The Negative Consequences
First, work on WebSockets continues today and Microsoft is part of that discussion. No one should interpret this recent news as the end of WebSockets.
One tech publication wrote that “the Web Sockets history illustrates some pitfalls of the style and pace of Web standards development,” and that “including support for a specification [that] wasn't done” is just the latest wrinkle. The article’s headline describes “the risk of unfinished standards,” while another article describes “emerging Web standards like WebGL and WebSockets,” and a comment from a Mozilla leader here refers to “speculative features.”
WebSockets is just one of many, many unfinished, emerging, and speculative features. Rushing ahead with implementation while the blueprints are changing a lot creates dissatisfaction. This (warning: potentially NSFW) video dramatizes that developer dissatisfaction. That dissatisfaction is the result of supporting unfinished, emerging, and speculative features in the mainline product.
The question is how to balance the implementation of these under construction technologies (in order to resolve under construction issues) with the needs of developers (who don’t like re-writing their code over and over to get new capabilities) and the needs of consumers (who expect sites and browsers to just work). Today, iPhone and iPad 4.2 support WebSockets. Firefox and Opera have recently disabled their implementations because of (among other things) the security and compatibility concerns.
An Alternative Approach, because WebSockets are Not Alone
One alternative approach to these experimental features is being much more explicit about implementations that are more prototype than product. This is the approach Microsoft is taking. You can read more about it here. Through these prototypes we balance the objective of providing a product for millions of consumers and engaging in early speculative discussions with developers and enthusiasts, without confusing either group.
There are many other technologies under development today that are still under construction. Because they are not site-ready today and will not be ready, relevant, and real-world before we release the IE9 product, these emerging standards are susceptible to the same problems and negative consequences that WebSockets has faced. Some technologies are in transition and being reconciled with others (or potentially abandoned in favor of others). SMIL animations and SVG fonts, though they are used in the Acid 3 test, are on the way out in favor of CSS animations and WOFF. The Web SQL specification, for example, was formally taken off the Recommendation track at the most recent TPAC with the emergence of IndexedDB as a better path. IndexedDB is itself an emerging and unfinished standard, along with WebSockets, the File API and WebGL (as the Ars Technica article above points out).
Site-ready also looks at the larger context of developer needs today and tomorrow and the viable alternatives as well as the state of the standards process. For example, CSS3 is an enormous set of technologies. IE9 already implements many CSS3 modules that are site-ready. Several other CSS modules (like CSS3 Gradients) are still emerging and unfinished. Other modules have perfectly fine interoperable alternatives, like using script in place of CSS3 Transitions and CSS3 Animations. For other technologies, like web workers, other considerations apply as well. Web workers introduce complex multi-threaded programming concepts to JavaScript, and require extensive prototyping (just like WebSockets) to fully explore the impact on developers and the broader web programming model.
There are many technologies that can easily play out the way WebSockets have. Developers and consumers are better off if these technologies are brought forward as explicit prototypes rather than in the product that so many people depend on. WebSockets and the IndexedDB web storage are the first prototypes in the new program. Some experimental CSS3 modules are potential candidates for prototypes, along with other technologies (e.g. the File API). This is a process we’re excited to work through with the community.
Looking Ahead
In developing IE9, we considered how different specifications are still evolving at different rates. IE9 supports technologies that, while not always finished, are developed enough to avoid the problems that WebSockets illustrate today.
In the IE9 product, developers can expect site-ready HTML5 so they can take advantage of the best of HTML5 that is ready and can still experiment with emerging HTML5 with HTML5 Labs. By keeping these separate, developers get what they need without the negative consequences of co-mingling very different things in the same browser.
IE9 offers support for the most relevant, real-world web patterns that developers are using today as well as the HTML5 patterns we expect to become more mainstream. By relevant and real-world, we mean the technologies with the broadest impact for browser users (e.g. CSS ahead of MathML). By support, we mean providing developers a consistent programming model that enables the same mark-up. The goal is supporting great new capabilities, ideally in a way that interoperates or will interoperate soon across browsers.
This approach (along with its supporting points, like test suites and “same markup” as a goal) has garnered strong support from developers. It’s also resulted in some surprising headlines over the last year, like “Only Microsoft gets web standards” according to “Mozilla man [who] blasts Apple and Google for HTML5 abuse,” from The Register.
In this context of unfinished technology, measuring how much HTML5 different browsers support through “benchmarks” does not make much sense. In particular, many of these tests (like Acid 3) include different partial collections of unfinished standards, while they exclude deep or broad assessments of the quality of the implementations. The key questions for tests are how appropriate is their scope, how accurate and rigorous are the individual tests, and how comprehensive is their coverage. The standards bodies involved in the process of developing the standards (like W3C and Ecma) are a great forum for the development of trustworthy, high-quality tests.
Professional website developers are busy. They write a code for a living and genuinely don’t have the spare time to wade through comments on all these under construction specifications and keep track of every build of every browser. With this approach, we make it easier to take advantage of the capabilities that are stable and ready for prime time. We remove much of the guess work for developers of working with a moving target. The result is more time for site developers to innovate and create better web experiences.
Back in March when we released the first platform preview of IE9, we were clear that we love HTML5 so much we want it to actually work. One aspect of that involves using the whole PC to run HTML with the best performance. Another aspect is working with community and standards bodies on test suites. Making sure that developers avoid the frustration of wasted time re-writing sites over and over as technologies change – and that consumers avoid frustration of sites that break easily – is just as important.
Thanks,
Dean Hachamovitch
Comments
Anonymous
December 20, 2010
someone please when will IE9 RC be released on this microsoft IE9 website ? because my IE9 BETA1 does not work well and sometimes it hangs on some website. so when can i download IE9 RC please anyone ?Anonymous
December 20, 2010
someone please when will IE9 RC be released on this microsoft IE9 website ? because my IE9 BETA1 does not work well and sometimes it hangs on some website. so when can i download IE9 RC please anyone ?Anonymous
December 20, 2010
I will try these experiments. This is good. What's is next on the roadmap for lab.Anonymous
December 20, 2010
Thanks for the write up. Can we get geo location support please? All the other browsers will have it.Anonymous
December 20, 2010
Thank you guys for starting to address these concerns. Q: will it be possible to download a sort of "preview" build that implements the full set of prototypes after IE 9 ships, in much the way that you have done preview build for IE 9?Anonymous
December 20, 2010
"Other modules have perfectly fine interoperable alternatives, like using script in place of CSS3 Transitions and CSS3 Animations." Like all the perfectly fine work around that get done for specifically for IE, as it looks like IE9 will be the only browser without them.Anonymous
December 20, 2010
Please, give us some information about Geolocation. This uncertain silence is worse than if you'd just said "no".Anonymous
December 21, 2010
I think many people (JM...) just didn't understand the Microsoft strategy. You'll not see Geolocation, Transitions, FlexBoxes and WebWorkers in IE9 because the next version of IE9 will be the release candidate. Microsoft will not introduce a new, potentially buggy, feature in a non-beta builds (or at least not something as big as those complex features), because nobody will be able to test it in time for RTM and we'll find a lot of bugs after IE9 come out, which is not what the IE Team want. IE10, on the contrary, will be another story, which will probably benefits from those new features like IndexedDB and WebWorkers. Chrome is a perpetual beta version. My website works very well in Chrome some day, it has rendering issues three days later. Then everything is fine a week after that. It's simply not serious. IE is intended for enterprises. When something is added, it should work. Microsoft did the mistake of adding bad stuff to IE (in v5/6) to rivalize NetScape and they've paid the consequences. Now, they just don't want that situation anymore, which is good for us, developers.Anonymous
December 21, 2010
@FremyCompany: I don't think that's the point as far as geolocation is concerned, as it's already been implemented for WP7, and I doubt it'd be costly to port it over. It's just that it's not a feature that is seen as important for non-mobile machines.Anonymous
December 21, 2010
I agree with you, FremyCompany.Anonymous
December 21, 2010
As web developers this shouldn't be any problem. We will continue to detect features and degrade for slower moving browsers. Users will continue to transition to browsers that deliver a better experience.Anonymous
December 21, 2010
@FremyCompany - I understand why Microsoft doesn't implement new features as quickly as others, but it would be at least fair if Microsoft'd inform us about upcoming development of IE.Anonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
WOW! Microsoft is treading lightly with standards! New Microsoft indeed, well done! WebGL fast please, even in labs.Anonymous
December 21, 2010
@Stefan Did you miss the whole discussion in the article about vendor prefixes? It's basically like painting a huge sign in the browser for hackers. Look over here, this is where the unstable and potentially exploitable stuff is. Not to mention developers use it anyway and then it has to be maintaned in the browser indefinitely. If the prototype code ships out-of-band, then there's no confusion.Anonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
Since these standards are evolving rapidly, there are sure to be parts that finally get nailed down between IE releases (which seem to occur every 2-3 years). Will Microsoft add these in, either in a patch or a minor point upgrade? Chrome may not be "serious" with all the releases they do, but Firefox is, and their minor point release cycle is a fair bit tighter (every year or so). I'd rather not wait 3-4 years from now before we see Web Sockets in IE, especially if the standard is nailed down a year from now.Anonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
I wonder what is IE team's stance on the new input elements (e-mail, date, etc.). Are they good enough to be supported? I see them as the best part of HTML5 because they save a lot of work and fail gracefully (become textboxes) in older browsers.Anonymous
December 21, 2010
» By relevant and real-world, we mean the technologies with the broadest impact for browser users (e.g. CSS ahead of MathML). « Yeah, all those eggheads will all their complicated formula stuff are the minority, the masses just want dancing kitties. That's why Canvas/SVG got implemented and HTML5 forms not…Anonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
I think IE9 is ready for the traditional Html Websites, but I am a web developer, and there is nothing traditional in Web Applications, I used WPF (biiiiiig mistake) in a project, and I wished they did like Google Chrome (update it and improved its performance every 6 weeks), but this never happened and we still struggle with its performance. Updating a browser every 6 weeks is hard, making it faster and adding more features is not easy, but Google is doing it anyway, and they make it look soooooooo simple. Looking at natural selection, the future is for the faster, the smarter, the better, … :-)Anonymous
December 21, 2010
One more thing, I am still not sure how will Microsoft compete with Google Chrome, IE 9 will be released, Google Chrome has much more API, much faster (with very few exceptions), and will surpass IE9 in few weeks after its release. On the other side, Microsoft will go in hibernation, as we are used too with every other Microsoft product, and then?Anonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
What Google does is not really preferable over what Microsoft does. They update the browser frame (at least I think they do...) and the V8 script engine every six weeks. They don't update one bit of WebKit though, which is the most buggy and incorrect collection of as many features as possible one engine can be. If Google would at least put some engineers on CSS and script compatibility, WebKit could really be a great engine. MS on the other hand is too conservative. The long release cycle may have made sense when serious work was necessary (i.e. CSS 2.1 compliance, maybe even SVG), but a modern browser should be updated at least once a year. The further downside is, that even thoug it currently takes about 2 years for a new version of IE to be released, Microsoft is not working out the details. I can completely udnerstand that one would want to be conservative about implementing new features. But I can not understand, that minor and middle sized issues are not fixed even if they're an apparent spec violation (or an apparent bug that makes just no sense). So unfortunately, at the moment, MS clombines the disadvantages of both methods...Anonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
@Stilgar I believed Microsoft for more than 15 years, but the last 5 years where when the company went down on every direction, I know that users don’t care about API, but I do. In order to run applications written by us, you must have Google Chrome, simple, the same as you need Java to run Java or .NET to run .NET. Google is saying that the browser will become faster and better once every 6 weeks, I don’t care if they get it faster even by .0001%, at least there is someone who is doing everything they can to make developer life better. Search the internet for the negative reaction about VS.NET 2010 service pack 1, and how slow WPF is; so much advertisement when Microsoft released it 4 or 5 years ago, 3d accelerated, good graphics engine, and it turned to be the slowest technology of all time. Yes, I use Google, they did not mislead me with false advertisement yet.Anonymous
December 21, 2010
I don't know. Our project breaks with every Chrome release. It breaks with every IE release too but at least it is not every six weeks. BTW I am pretty happy with VS 2010 but I use it to develop web apps so I do not know about WPF pains.Anonymous
December 21, 2010
So, folks, basically Microsoft is saying this: because some lazy web developers don't want to upgrade their webapps when any API changes, they (Microsoft) will not support any of these innovative web technologies. I applaud Microsoft for focusing on improving the lives of all lazy web developers! Wait, but, hum, I'm not lazy. Ok, I guess my webapp wil support ONLY modern browsers: Google Chrome, Safari & Firefox.Anonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
Please get it settled once and for all. When is a detailed specification of the product version of IE9 open to the public? First of all, please clarify the one that it is possible to use it and the one that it is not possible to use it. I want you to offer the list of the tab of HTML to be able to guarantee operation with IE9 and the list of the attribute that can be used in those tabs. Maybe, I think that it becomes the subset of the draft of HTML5.Anonymous
December 21, 2010
MS needs more public Betas of IE9... If not, we will see another version that could have been better going gold...Anonymous
December 21, 2010
If you add just one html5 form feature in IE9, make it the placeholder text. Should be extremely easy to add and it replaced the current need for javascript to do such a simple task. But anyway, I do like how IE9 is handling standards for the most part. Obviously I would like html5 form stuff, but just adding things that really work will keep things simpler in the future. Also, I hope this post will get all the people begging for websockets to be quiet for a while =pAnonymous
December 21, 2010
@Luis so your definition of "lazy" is developers who have actual work to do instead of update their working code every six weeks. Let alone that small companies may not have the budget to pay for constant upgrades to their web apps.Anonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
What's clearly appearing when reading the comments is that the current release cycle of IE (two years or more) is not suitable to web anymore at this time. The IE Team will need to provide more updates in the future (one every 8/10 months seems reasonable). A good solution would be to have a "pre-IE10" engine included in IE9.1 that would evolve with time, while the IE9 engine would stay the same. The pre-IE10 engine would only be triggered by pages having X-UA-Compatible: IE=edge (by default) or IE>9. Other pages could still use the RTM 9.0 shipping IE engine by specifying IE=9. While I know it will not exists in IE9, this kind of feature is nice to have for IE9.* / IE10, because enterprises can release for IE9 and be sure the new updates won't break their internal website, but real websites can take advantage of more regular updates.Anonymous
December 21, 2010
I think what this shows, and is echoed perhaps unintenionally by many of the commentors, is that Microsoft has far more experience in developing a solid, stable and long term platform for developers than anyone else on the planet. They've clearly learnt the mistakes of rushing implementations through, of trying for short term gain rather than long term benefit and are clearly bringing that experience to HTML5 at long last. I do hope, however, that we will see many of these more experimental, in development features in something like the platform previews, it'd be a great way to help iron out many of the issues with emerging technologies.Anonymous
December 21, 2010
Wow, a WebGL shout out! It's like you guys aren't ignoring it. ;) WebGL is gonna hit 1.0 really soon IE9 guys, will it make it into IE9? Sure hope so.Anonymous
December 21, 2010
@GT "In order to run applications written by us, you must have Google Chrome, simple, the same as you need Java to run Java or .NET to run .NET." This is called vendor lock-in. You are just replacing "MS-standards" like VML or something with "Google-standards", which is what WebGL, WebSockets and WebWorkers basically are. But hey, Chrome IS HTML5, isn't it? Maybe, but to me definitely not as long as Google won't fix WebKits percentage-bugs. I think, people just begin to understand the more complex & clean approach MS is taking on W3C-standards. Writing a comprehensive test-suite is far more work than it sounds, but without it, the underlying standard is pretty much unenforcable. It is far more work than tweeking a bit of performance every six weeks or introducing "standards", which are mainly a Google-brainchild itself. As christmas eve is nearing, I have wishes: First, CSS3- or HTML5-features should get to Candidate Recommendation as quick as possible, but as clean and verified as necessary. I hope, MS and Google will be drivers to get things done in 2011. The process must be streamlined. Plus there should be a timelimit: if a working draft remains in this state longer than two years, than it should be dropped altogether. The second thing I wish is, that every technology should be checked not only against it's technological dimension, but also it's application. GeoLocation f.e. is a thing I look at very critically. How easy will it be for Facebook to track down users, if any browser has a comprehensive GL-API? Third, there is the broader thing of companies inroducing standards at the location most convenient to them, not at the most logical location. Why is WebSockets an HTML-feature? It's HTTP. WebWorkers is basically a JavaScript-feature, but it is in the HTML-standard. And last, MS should simply keep those Previews alive, even after IE9 has shipped. If a HTML5- or CSS3-feature gets fixed, it can be introduced in the Previews. And I really see no reason why ADDITIONAL capabilities cannot be introduced by Windows Update. I know, MS is reluctant of adding features outside the release cycles for communication purposes (read: PR). But here is no problem, since the audience are web developers fit for keeping themselves up-to-date. If you don't, it will basically defeat the purpose of PR. Oops, forgot something: CSS3 border-image in IE9, please grinAnonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
@FremyCompany But web developers aren't the only people who matter. Whilst they might want everyone to get a new browser every six months, that's just not practical in reality and longer, more considered release cycles are vastly preferable. The 18-month to 2 year cycle is probably the best compromise between the needs of everyone.Anonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
Thanks for this approach. There's already enough new stuff lying ahead. We don't need another "incompatibilty war" like we had with IE5/6.Anonymous
December 21, 2010
@Stilgar "I don't know. Our project breaks with every Chrome release. It breaks with every IE release too but at least it is not every six weeks. BTW I am pretty happy with VS 2010 but I use it to develop web apps so I do not know about WPF pains." I am not sure what your using that it breaks every release, care to elaborate? We have been advising our users to use Google Chrome and or Safari / FireFox, as a last resort we also support IE8 (IE6 and IE7 are blocked). Our web applications are fully Javascript driven and we haven't seen a single problem occurring due to a browser update with our application based on when we started recommending Chrome (back then it was version 4) to Chrome 8 and Chrome 10 (dev channels). I am not saying Chrome is perfect (there are still some anoying bugs), but atleast it gives our users a really good / fast experience working with our web applications, and therefore we love it :-).Anonymous
December 21, 2010
@Luis As your webapps will only support a few browsers likely somenone will built an apps that does the same and works for every browser and leave your pityfull efforts in the dust and quickly forgotten.Anonymous
December 21, 2010
@Andrex WebGL will likely never make IE as it is not a W3C webstandard but some private standaard created by competitors to promote OpenGL. When W3C publishes a new 3D canvas or 3D SVG standaard Microsoft will support that in IEAnonymous
December 21, 2010
I am not sure because I am not the one fixing it but I often notice functionality that either breaks or misbehaves due to new versions of Chrome. Stuff breaks in both third party libs and in our own js code. In FremyCompany's comment in the beginning of the thread it seems like he has the same problem.Anonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
I hate to repeat this here but once a post on the IE blog is not the latest post it gets ignored. Can someone from Microsoft please make a statement about shutting down the IE6/IE7/IE8/IE9 images at http://www.spoon.net/ ====================================================================================================== This was THE most useful resource for testing multiple versions of IE and the shutdown really ticked developers off! As a long time web developer of Enterprise Web Applications I've tried all the options out there to try and simplify testing IE and the lack of realistic options is a royal PITA. 1.) Multiple IEs - IE8 breaks the functionality of IE6's textboxes - thus its a NO-GO 2.) IETester - works great until you need to test popup interaction and then it fails - thus a NO-GO 3.) Virtual PC with timebombed images of IE6, IE7, IE8 - works ok, but the 12Gigs of HD space needed is frustrating when each full image of Windows dies 4 times a year, running a full Windows image is slow and you have to beg for updates because the releases are not co-ordinated and announced well at all - thus its a NO-GO 4.) IE Super Preview - Last I checked this did not allow full testing of IE user interaction, JavaScript DOM changes, popups etc. - thus its a NO-GO 5.) Multiple PC's to run multiple versions of windows and IE. With all the hardware, software, and physical space needed - its a NO-GO 6.) Spoon.net IEs - They work, they work just like local native apps once running, and there's no hacking of my real local IE install. - the ONLY problem with these IE's is that Microsoft shut them down Please understand that we (developers) just want something that works. Testing in multiple versions of IE is a pain to begin with and with IE9 on the horizon it is only getting worse. I'm not sure where the issue stands with Spoon, but I would really like a solution worked out fast. SteveAnonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
hAl: > As your webapps will only support a few browsers [...] Does Google Chrome Frame ring any bells? :)Anonymous
December 21, 2010
@Steve Did you try make a request for this using Microsoft Connect? @Stilgar Then you probably use features that still don't have a stable specification, which is always a risk to use, but for me as a developer I'd rather take that risk on features that just enhance things and are not critical in the application :-).Anonymous
December 21, 2010
Wow ... this seems to miss the point. IE, FireFox, Opera, Chrome and Safri should support the same stuff. Standards are a feature list with guidelines. If the Standard changes .... version the feature. Remember MS XML 1, 2, 3, 4, 5, etc. We are not talking about issues for users, we are talking about developers. We get versions and changes. Do it now, if it changes, add a new version number. Really ..... where are the smart people a MS.Anonymous
December 21, 2010
So Today's Microsoft "cop-out " phrase is "site-ready". Any technology/spec that MSFT doesn't want to implement or is behind on implementing is therefore now not "site-ready". What is really sad is that in order for many of these specs to see the "recommendation" status, there must be actual reference implementations by 2 or more of the "big" browsers.. and often IE is the browser "Holding back the Web" [TM] Since you've highlighted the features that likely won't see action in the IE9 RTM, lets at least discuss the items that are: "site-ready" that are just waiting for IE to finally catch up on. 1.) Geolocation - Seriously!... this isn't a hard API to implement and yet provides major possibilities to developers that they currently have access to on EVERY OTHER BROWSER! best of all, 100% of this does not affect DOM rendering etc. so it can be updated/improved on-the-fly at any time, in any release/patch - therefore there is absolutely no reason why IE9 should not support this 2.) innerHTML - Developers have complained about this for years and Microsoft developers themselves have indicated that the existing poor support was due to a buggy implementation. Its been over a DECADE since MSFT released this buggy implementation - where's the fix?! - Since innerHTML is now part of the HTML5 specification - IE9 must support it completely and properly if MSFT expects developers to continue supporting IE, and especially if MSFT has any intentions of claiming that "IE9 is HTML5 ready" - because currently that statement is a load of bunk! 3.) localStorage - I know this supposedly worked in IE8 - but even in IE9 (latest preview) I still find that my tests indicate I can't develop in IE because it refuses to understand/use my local drive/localhost/127.0.0.1/192.168.x.x - if there is a special setting we need to set to make this work - please advise 4.) video/audio - Developers need a common, free AND open format to deliver content. IE9 NEEDS to support WebM AND OGG for video, and MP3, OGG for audio. Please stop hiding behind DRM shackles etc. and just release a browser that works!!! If HTML5 audio/video is unable to gain traction in the market it will be 100% based on IE9 not supporting the correct formats. On a side note someone above mentioned that WP7 (Windows Phone 7) actually does support Geolocation in IE (whatever version that is) - if this is the case - it looks like the technology is already there, hurry up and port it! If however this statement is false and WP7 does not support Geolocation - what on earth was MSFT thinking releasing a mobile smart phone with a browser that doesn't support Geolocation?!?!?! it would have made much more sense to release it with a WebKit based browser. Can you (Microsoft) please clarify the state/release of Geolocation on the Windows Phone 7 and IE9 RTM. thx RalphAnonymous
December 21, 2010
@ Ralph I am sure you have sources inside Microsoft, that have told you exclusively about technology that Microsoft "...doesn't want to implement or is behind on implementing is therefore now not "site-ready"...." That is amusing! (I am polite in this one, other descriptions also come in mind) Try html5labs.interoperabilitybridges.com and see the technology, strangely by Microsoft, that you accuse. HarryAnonymous
December 21, 2010
@Ralph, I'm pretty sure the same team who work on the WP7 IE don't work on the 'Desktop' IE, so I don't think you'll get an answer to your question here.Anonymous
December 22, 2010
I think we are forgetting a major difference between Google and Microsoft, Google is creating a full application environment inside Google Chrome, Microsoft is just writing a new release of a web browser and it has independent application environments one of them is .NET. I am pro innovation and against standards, and I was with Internet Explorer all the way until Chrome, after all, we all know that the most popular browser is the one who will define the standards. The Chrome application environment evolves every 6 weeks, and now getting way faster than .NET or Java or any other browser technology including Silverlight, V8 interaction with the UI is now hundreds of times faster than C# and Java with very large forms. Put a large amount of HTML in a page, interact with it using JavaScript, and try the same with Silverlight or WPF, or any other UI technology, none of them can match Chrome (with a few 3d exceptions in IE9), and Chrome dev is catching up with that pretty quick. Microsoft will release IE in a few weeks or months maybe as they do with other software, but Chrome will continue evolving their browser/ app environment and make it better, faster, and more features every 6 weeks, I don’t know how can anyone compete with that.Anonymous
December 22, 2010
The comment has been removedAnonymous
December 22, 2010
The comment has been removedAnonymous
December 22, 2010
Why dont you develop that site with HTML5?Anonymous
December 22, 2010
The comment has been removedAnonymous
December 22, 2010
The comment has been removedAnonymous
December 22, 2010
The comment has been removedAnonymous
December 22, 2010
The web is evolving at a rapid pace. By using, testing, reporting bugs and pushing half baked API's to their limit we will help moving the web experience forward for the rest. I'd hate to think what would happen to our industry if we kept waiting for IE to implement a feature before using it. If IE9/10 doesn't support File API, the IE users will have to use old file browse dialogs, while the rest of the users will get desktop drag and drop uploading with pre-upload thumbnails and progress events for a way better experience. If IE9/10 doesn't support CSS-gradients we will serve an image to IE instead, which will take an extra HTTP-request (if we're not using CSS data-URI's or MHTML, which will add to the size of the IE-specific CSS or using -ms-filter: "progid:DXImageTransform.Microsoft.gradient() if we don't need opacity) making the IE experience slower. If IE9/10 doesn't support the Geolocation API we'll use the less exact IP-detection or just let the IE-user select where he/she is, making the experience more cumbersome in IE. I could go on and on, but the point I'm trying to make is that in the end, the users who want a better, faster and more beautiful experience will switch from IE to Firefox, Chrome, Safari or perhaps Opera. Some won't. They can keep on using the service at a more basic level. Merry xmas!Anonymous
December 22, 2010
@GT - I agree that Chrome is a better browser at the moment, but I don't see that as a justification for much else....not just yet, at least. Microsoft is really doing a poor job at bringing IE8 up to speed (see for yourself by running this HTML5 test site on IE8 then on Chrome: http://bit.ly/g8DaIe) ...maybe they should have a Silverlight based browser so it's easier to roll out updates lol @Banned in Boston - IMHO, I would suggest taking the wait and see approach on moving to Flex. Remember those talks between Microsoft and Adobe a few weeks back...well that went silent, but new computer models seem to be doing some talking - check out the included software on this new computer (namely: Microsoft® Silverlight Acrobat® Reader) - http://bit.ly/evbQ9k Also some interesting news related to tablets and a rumored Windows 7 OS aimed at tablets and expected to show up at CES which is right around the corner: (Tablets) http://bit.ly/dQkMXc (Windows 7 OS) bit.ly/gQAN2R Cool thing about bit.ly besides the analytics, you can add .qrcode to any of the extensions: http://bit.ly/gQAN2R.qrcode --> Microsoft's going to have to come up with an answer to thatAnonymous
December 22, 2010
The comment has been removedAnonymous
December 22, 2010
@Jordan | a Silverlight browser? To see how poorly a technology is implemented, push it to its maximum, put 5,000 text boxes in a scroll in a stack panel in Silverlight and try to run the application, then repeat the test with HTML5 in Google Chrome and look at the results. Once you see the difference, and it is huge, then you will realize how poorly that technology is implemented.Anonymous
December 23, 2010
@hAl "WebGL will likely never make IE as it is not a W3C webstandard but some private standaard created by competitors to promote OpenGL. When W3C publishes a new 3D canvas or 3D SVG standaard Microsoft will support that in IE" WebGL is as much as standard as anything the W3C creates, both are made up of primarily the same companies including Mozilla, Google, Apple, and Opera. Only one lacking is, of course, Microsoft, because supporting standards is great when it's convenient for you, but when they compete directly with one of your technology it's a no-no. And in all actuality there's no reason WebGL in IE9 can't be hooked up to D3D, it's what Firefox is doing by using ANGLE.Anonymous
December 24, 2010
will IE9's implementations of various DOM methods be fixed to follow the standard specifications? There are many methods that were implemented wrong in IE5.x/IE6 that have still not been fixed. Since IE9 will be the first decent release of IE in terms of being a browser that actually meets some specs and has half-decent performance it would be a tragic, epic failure if IE was still to not have fixed some of the most basic JS methods. nick the greekAnonymous
December 24, 2010
@Andrex >> WebGL was not made by the W3C. Period. The fact Mozilla, Google and others implemented it does not mean it is a standard.Anonymous
December 24, 2010
will IE9's implementations of various DOM methods be fixed to follow the standard specifications? There are many methods that were implemented wrong in IE5.x/IE6 that have still not been fixed. Since IE9 will be the first decent release of IE in terms of being a browser that actually meets some specs and has half-decent performance it would be a tragic, epic failure if IE was still to not have fixed some of the most basic JS methods. www.torrenzz.ruAnonymous
December 30, 2010
Microsoft still not get it...