IE7 To Support XMLHTTP Requests
Ruliz Galaxor writes "IEBlog posts that Internet Explorer 7 will support a native XMLHTTPRequest object as many other browsers currently do. This will mean no more ActiveX MSXML objects to implement AJAX functionality. It looks like Microsoft is seriously trying to make the lives of us web developers easier. Of course you'll still need to use the Microsoft.XMLHTTP ActiveX object if you want to support IE6 and older."
It's OK, we understand ...
"Of course you'll still need to use the Microsoft.XMLHTTP ActiveX object if you want to support IE6 and older."
Which means that browser type checking will need to remain pretty much for the forseable future. Inclusion of XMLHTTPRequest now is nice, but in practical terms its perfectly meaningless.
StrategyTalk.com, PC Game Forums
Begun the browser war has (again).
It looks like Microsoft is seriously trying to make the lives of us web developers easier.
MS deserves credit for this sensible implementation of XMLHTTPRequest, and indeed for innovating XMLHTTPRequest in the first place.
Now if MS is "seriously trying to make the lives of us web developers easier" [when] will they implement the rest of the core W3C web standards?
FF, Opera and Safari and their respective communities are already well advanced with implementations of SVG, DOM, CSS, PNG, JPEG2000 and XForms. These standards are bread and butter for "seriously trying to make the lives of us web developers easier".
When will MS join the inevitable?
Can someone tell me if this means that I no longer have to take my business elsewhere when I encounter a "Sorry, this site only loads in Windows?"
I dig that stuff that requires the DRM WMP still may not let me in, but what about other things?
Can I hope that Safari and friends will no longer be a second class citizen on Exchange WebMail, for example?
--
$tar -xvf
I think it's great what the IE developers are doing. There are, of course, a few features I'd love to see integrated into the latest version, but I'm extremely happy with what they're doing otherwise.
When the IE blog began I was angered that they didn't seem to be worried about the numerous CSS flaws, among other bugs. They seemed like they were just trying to beef up security. As time marched on, though, the developers seemed to be taking notice to what most of the replies were about. The IE developers listened and really went the extra mile where the concerns of web developers everywhere are concerned.
While there are a few things I'd love to see (like the ability to properly deliver XHTML), I'm happy (for now) with the changes they're implementing. It sounds like they're really committed to helping web developers from having to design their website three or more times before they get a version that's decent looking in all browsers.
Let's give the guys some credit where credit is due... who knows, maybe the rest of Micro$oft will take the hint.
... embrace and extend.
It's good that MS is supporting web standards, but I doubt the reason is to play nice and make the lives of web developers easier. IMHO, MS realized that they have lost a lot of ground, credibility and following in the browser market. Any new "innovations" coming from MS will NOT be adopted very easily these days unless Firefox, Safari and Opera endorse it. So, before it can repeat what it did to Netscape, MS needs to re-capture its lost browser market share. The easiest way to do that is to come up with a really great browser that supports all the current web technologies, and that is easier to code for than other browsers. Classic 'embrace'. Once it has done that, and it has all the time and money in the world for it to do that, only then can it can start phase 2, the 'extend' phase where it renders all other browsers obsolete.
The only way to combat MS on this front is to keep innovating, staying a step in front of it. Netscape made the mistake of not updating their browser soon enough, and they paid dearly. I hope Opera, Firefox and Safari have learned that lesson.
> XMLHTTPRequest is too important for MS not to try and control it. I wouldn't rule out a good ol' "embrace and extend" move.
What the hell are you talking about ? Microsoft invented the damn thing. Embrace and extend my ass...
FireFox doesn't even fully support CSS2. (http://www.w3.org/TR/REC-CSS2/text.html#text-shad ow-props) When will FireFox join the inevitable?
3
https://bugzilla.mozilla.org/show_bug.cgi?id=1071
Note this bug was opened in 1999. Judging from the target milestone (mozilla1.9) and the FireFox roadmap, we will have full CSS2 support in FireFox 3.0 by 2007. Wow, eight years...
What IE really needs right now, if it wants to be taken seriously as a platform for AJAX web applications, is proper DOM/CSS support. The following would be a good start (my current peeve list with IE6):
I've posted this on ieblog before. I sincerely hope that somehow someone on the IE team sees one my numerous implementations of the above list of rants and implements solutions for them. It'll make the professional lives of many AJAX developers quite a bit more pleasant.
Firstly, this is not news. This was posted on the IEBlog way back in September.
Secondly, this is one hell of a misleading headline. Internet Explorer has supported this interface since Internet Explorer 5.0, released in the year 2000. All that's different in Internet Explorer 7 is that it's implemented as a native object, rather than with ActiveX.
Finally, this matters to practically nobody. Any decently-written code will work just fine in Internet Explorer 7 with no modification whatsoever. Even code written to use browser detection instead of feature/object detection, (a bad idea) will work just fine, assuming that the ActiveX interface sticks around too.
Bogtha Bogtha Bogtha
I'm the web architect of gather.com and we use an invisible iframe as a pipe for our AJAX stuff instead of XMLHttpRequest. This works in a uniform way across all browsers we've tested it on with - even way old ones. The Javascript is 1.0-level stuff and IFRAME is standard since HTML 4. I wonder why more people don't use this approach? I know people hate IFRAMEs, but the ones we use are invisible and 0x0 pixels, so they're little more than an offscreen paint buffer (like BitBlt! :) )
The general approach we're taking is described in this years-old posting on Apple Developer Connection. Anyone else have experience with this approach?
Microsoft invented XMLHttpRequest. Not Firefox, not opera, not KHTML. They all copied it from IE.
So it would be Firefox/Opera/KHTML that are doing the "embracing and extending" in this case.
On a side note, I don't see why this is a big deal. They are likely still going to use a COM object underneath. All this is is a coding shortcut, that no one will be able to use anyway because you're still going to have to support IE6 for the next 3 years at least.
Goatse, is that you?
I work on solution designs for a fairly large ISV, anything that increases browser compatibility is a good thing all around. Most of our end-user interfaces and make use of XML with some XSLT on the client, we also use XMLHTTPRequests..
Due to pure market pressure from our existing userbase we develop for the IE platform. IE isn't for everyone and ideally we'd like to target every browser from a technical standpoint and we know it increases the number of potential customers we have. We move one step closer to genuine cross browser compatibility with this.
Despite this we still need ActiveX right now for a couple of key things:
- File uploading, we used Java already and it went badly. Our customers had real problems with getting correct JRE versions out to their users, the users complained about the lack of standardisation in basic things like the Common Dialog. We've had a lot less problems with ActiveX controls but understandably network admins really don't like it.
- MS Office Automation. Part of our product is business reporting, it has features around automated generation of Powerpoint Presentations and Excel Spreadsheets from the web interface. We can't influence our customers decisions around Office systems but we've never encountered pushback over MS Office from anybody. MS Office automation needs ActiveX and is way outside sandbox (local processes are launched and these have access to all kinds of things).
In short, this helps but we are still a way off from being able to deliver fully functional web-based business systems with this but it helps. As an enthusiast I like it, as a real world solution developer it doesn't quite make a dent.
What makes more sense?
Which do you think is the healthy, competitive scenario? Which do you think hands control of the future of the web over to a single organisation?
Bogtha Bogtha Bogtha