Many of the upcoming generation of browsers (FF 3.1, IE8) are going to support cross-domain XMLHttpRequests in one fashion or other (with security concerns, as long as the server opts in, etc).
Is the same bit of functionality going to be in WebKit?
FF: https://developer.mozilla.org/en/Cross-Site_XMLHttpRequest
IE: http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx
Basic support for this was added to WebKit in May (see this patch). There are have been a number of other patches since then cleaning it up and refactoring bits of WebKit to deal with the changes entailed as well as tracking changes to the spec. Since the spec had changes recently (and webkit was updated with them 3 days ago) I think it is safe to assume no currently shipping browsers support it, but that most of them will in the future, and the current WebKit nightlies are tracking the standard fairly closely.
I think this is really up to the standard (http://www.w3.org/TR/XMLHttpRequest/) rather than the browsers framework, or javascript engine.
In fact I fully disagree with Microsofts decision to implement their own stuff that has nothing to do with the W3C standard. The web is a mess today mostly because of Microsofts ugly implementation of things.
As per WebKit, they seem to be pretty up-to-date with W3C.
Here's also a good article about this: http://ajaxian.com/archives/the-fight-for-cross-domain-xmlhttprequest
If you're looking for other ways to communicate cross-domain using ajax style (without using the XMLHttpRequest object), you should check out JSONP, it is currently fully supported on all browsers.
Related
I read this article https://wiki.mozilla.org/NPAPI:HttpOnlyCookies , since the article is almost two years old, has it been implemented in NPAPI or Firebreath
It's not listed as an accepted proposal on the main NPAPI page, so it's never become part of NPAPI. That's why it's not in the NPAPI headers. Given that, it's unlikely any browser implements it. Chromium certainly hasn't, and mxr doesn't show any indication of NPNURLVHttpOnlyCookie in Gecko either. (Not surprising, since both Chromium and Mozilla contributors argued against it on the NPAPI list when it was proposed.)
The age of the proposal is irrelevant given that it was not accepted.
Support is not available in FireBreath, though it could probably be added if you wanted. I think support has been added to Firefox's NPAPI, don't know about Chrome. You'd have to try it.
So I'm researching new frameworks and am really impressed with what I've read about Dart. Of course, I have to support at least IE8, and Dart doesn't seem to provide that. I was wondering why exactly that is. Is it just because it compiles to ES5? Would some simple polyfills fix that?
(Thank's for checking out Dart, we're glad you like what you see!)
Dart is from the future, today. Look at any trends, and one thing is clear: mobile, mobile, mobile. Oh, and also modern browsers that auto-update.
Spending any time working on legacy browsers, with their outdated JavaScript engines and feeble support for HTML5 (if any), means we're not spending time working on a comprehensive platform for developers to build apps that wow users. We believe that user expectations are high, and the only way to meet and exceed them is to build a platform that runs on modern JavaScript engines and can exploit the wide array of HTML5 features. You just can't build a fantastic experience that shows off the power of the modern web and support legacy browsers.
For a quick fix, encourage your users who are stuck on legacy browsers to install Chrome Frame. Or, better yet, encourage them to upgrade their browsers.
As to what prevents Dart from being used in legacy browsers:
Lack of testing. Our buildbots don't test against legacy browsers.
Lack of ES5 JavaScript engines.
Manpower. Our resources are better used building for modern web browsers.
I'm not sure if we explored if an ES5 shim would work. We'd love to hear from the community if they get this to work, though.
The question's pretty straightforward and the old topic is here. I'm hoping to get up-to-date answers since IE9's gonna be released this March 14, 2011.
In addition, I would also like to ask when will Firefox and Opera be supporting WebSockets?
I've been following both the development of IE9 and I also participate in the HyBi WG (WebSockets protocol). Microsoft has been keeping the demo implementation of WebSockets up to date with the latest revisions of the protocol, however, I suspect that the initial release of IE9 will not have built-in WebSockets support. It will probably not be until IE10 unless they start to see it as a big competitive disadvantage in which case we will likely see it added in a IE9 update before IE10.
Firefox will likely support WebSockets in an update to FF4 or with FF5 (but the plan is that 5 will come out this year). Also, you can turn on the current implementation in FF4 using a about:config option.
I have no idea about Opera. They are interesting in the protocol but they've been pretty silent on the HyBi list.
Also, if you need WebSockets right now you can always use the Flash shim/fallback web-socket-js.
Update:
I forgot, Opera 11.00 does have WebSockets support built-in but disabled. Go to opera:config and search for WebSocket.
So in summary, just about every modern browser has WebSockets support in some way either built-in and enabled (Chrome, Safari, iOS), built-in but disabled (FF4 and Opera), as a downloadable add-on (IE9), or using the web-socket-js Flash emulator (everything except iOS).
Nope, The RTW version of IE9 does NOT support a websocket type... :(
UPDATE: The IE team is developing websockets for their browser, but it's not included in the initial release because the standard is in a fluid state. Although the implementation is stable, the standard isn't. If you want to test it out in IE9, you can by downloading it here:
http://html5labs.interoperabilitybridges.com/
You can hear more about it by listening to this DotNetRocks podcast:
http://www.dotnetrocks.com/default.aspx?showNum=648
Best regards.
IE9 does support WebSockets but not as a "built-in" functionality. You have to download it as a plugin from http://html5labs.interoperabilitybridges.com
The reason given by microsoft for not including in default setup is - the standard is unstable and keeps changing and in default setup only stable HTML5 standards shall be included.
So in a way IE10 as of now will also not include.
The HTML5Labs site will provide "experimental" support to unstable standards.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
Will IE9 support WebGL and/or WebSockets?
Most answers to the question "When will browser X support HTML5 feature Y?" are answered by When Can I Use. In addition to list past, current and future support each item also generally has links to relevant news.
WebSockets
WebGL
Update:
Microsoft has been actively participating in the IETF HyBi working group (WebSockets protocol) and also participating in W3C work on the WebSockets API. The IE 10 preview release has WebSocket support built-in so it looks very likely that we will soon see a official release version of IE with WebSockets.
WebGL in IE still looks pretty uncertain. Microsoft claims fundamental security issues with the design of WebGL, but I suspect it has more to do with the fact that Microsoft has a vested interest in promoting their own DirectX framework rather than OpenGL (which is what WebGL is based on).
As of a few months ago, the IE9 team hadn't made a decision about supporting WebSockets, and they didn't seem to see the point to WebGL.
WebGL seems not to be include in IE's strategy because of DirectX.
Anyway google already worked on that with the ANGLE project.
http://code.google.com/p/angleproject/
The IE team added a WebSocket implementation at HTML5 Labs which is their testing ground for new implementations. Chances are high that WebSockets will make it in IE9
You can look at the current release notes for the platform demo - there is no mention of either WebSockets or WebGL.
There are many discussions of the security issues of WebGL. I first heard of it on one of Steve Gibson's podcasts. Since it gives much lower level access to both the operating system and the hardware any flaw can be exploited much more severely. A quick Google search found this article with descriptions and video of some of the flaws: http://www.contextis.com/research/blog/webgl2/
Microsoft seems quite reluctant to implement WebGL in IE, since OpenGL is a competitor to DirectX. So I think it's unlikely we'll see WebGL in IE in the near future.
I’ve started an Open Source project called JebGL that can serve as a fallback for IE users. It’s a Java applet that when finished will serve as a plugin replacement for a WebGL canvas. It’s still in the early stages of development, but you can check out the demos at http://jebgl.googlecode.com
Right now, the Microsoft IE team is struggling to get HTML 5 and SVG (2D graphics) into Internet Explorer 9. Other web browser makers have been shipping with those standards built in for years.
Apple Safari, Google Chrome, and Mozilla Firefox all run fine on Windows. Takes one mouse click to launch a different browser. Takes a year or two to see what Microsoft might do.
IE progress has consistently been glacially slow this whole decade.
No, IE does not have WebGL support now and betas from other browser makers already run it. IE9 will not catch up with contemporary web standards like WebGL, just ones that have been out for several years or more.
IE9 is not a cross platform web browser either. It will only run on certain specific versions of Microsoft Windows. Just run one of the standard web browsers and you can see what WebGL can do. Their current betas are running some impressive WebGL demos now.
As a fallback until Microsoft adds WebGL support, the Google Chrome Frame beta currently supports WebGL.
RE: WebSockets: No. The target was websocket support in IE10. Tests show that it only has partial support.
I want to develop Safari plugin using xCode, What API should I use? Someone can give me some documents or sample codes ,Thanks very much!
The answer is rather complicated i'm afraid.
Unfortunately, Safari the web browser does not have a plugin API. That means you technically cannot extend Safari's user interface or features using plugins.
However, WebKit the web rendering engine (which powers Safari and many other browsers/apps) does have a plugin API (actually it has 2) which allows you to create plugins for rendering web content inside webkit webviews.
You can find documentation on developing WebKit plugins in Apple's docs here. (PDF Link!)
Also note: Safari's lack of a true plugin API has not stopped lots of developers from developing various pieces of software which they call "Safari plugins" even tho they are technically not Safari plugins. They are usually something called an "Input Manager" which are widely viewed as rather questionable pieces of software. Input Managers always seem to be on the cusp of becoming unsupported or broken by Apple. It's not really clear whether Input Managers are kosher with Apple or not.
Then again, several "Safari plugin" Input Managers are quite popular, so....
Input Managers are a whole other topic. I'm sure if you google it you can find a lot of information on them. However, personally I would advise against developing an Input Manager due to their questionable status in the Mac software world and their constant danger of becoming unsupported or badly broken.
Update: A few years after I originally answered this question, Apple did provide a sort of plug-in API for the Safari browser itself. However, they are called "Extensions", not plug-ins.
See the Apple Safari Extension Programming Guide for details.
Check out Rentzsch's ClickToFlash, it's a plug-in that is fairly well documented, along with neat source code.