Slashdot Mirror

← Back to Stories (view on slashdot.org)

IE7 To Support XMLHTTP Requests

Posted by ryuzaki0 on from the new-tricks-for-an-old-dog dept.

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."

49 of 238 comments (clear)

  1. Program Managers Anonymous? by manastungare · · Score: 5, Funny
    Hello, I'm Sunava Dutta and I am a Program Manager in the Internet Explorer team.

    It's OK, we understand ...

    1. Re:Program Managers Anonymous? by Tackhead · · Score: 5, Funny
      > > Hello, I'm Sunava Dutta and I am a Program Manager in the Internet Explorer team.
      >
      > It's OK, we understand ...

      1) We admitted we were powerless over the cruft - that the code base had become unmanageable.
      2) Came to believe that a power greater than ourselves could restore us to sanity.
      3) Made a decision to turn our specs and our code over to the care of Gates as we understood Him.
      4) Made a recursive search and complete manifest of our source files.
      5) Admitted to Gates, to ourselves, and to another developer the exact nature of our design flaws.
      6) Were entirely ready to have Gates fire our sorry asses.
      7) Humbly asked Him to allocate the budget for the security upgrades.
      8) Made a list of all bugs we had let slip into the released codebase, and became willing to provide patches for them all.
      9) Provided patches to such systems wherever possible, except when to do so would break existing functionality or introduce new security holes.
      10) Continued to monitor the security mailing lists, and when we were notified of an exploit, promptly fixed the bug.
      11) Sought through coding and specification to improve our conscious contact with Gates, as we understood Him, praying only for knowledge of His will for us and the power to carry that out.
      12) Having had a spiritual awakening as the result of these steps, we tried to carry this message to program managers, and to practice these principles in all our projects.

  2. Backwards Compatability by angst7 · · Score: 3, Insightful

    "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
    1. Re:Backwards Compatability by Anonymous Coward · · Score: 4, Insightful

      Yeah, so they shouldn't add it at all, because it's apparently pointless.

      Good call! After all, why in the hell should Microsoft make web developer's lives easier in the future? It's complicated now!

    2. Re:Backwards Compatability by digitaldc · · Score: 2, Funny

      Inclusion of XMLHTTPRequest now is nice, but in practical terms its perfectly meaningless.

      Yes, but look at it this way, how many times do software companies do something perfectly?

      --
      He who knows best knows how little he knows. - Thomas Jefferson
    3. Re:Backwards Compatability by lseltzer · · Score: 4, Insightful

      >>in practical terms its perfectly meaningless

      Not true. The point of it is that a user or company can disable ActiveX completely and still use AJAX.

    4. Re:Backwards Compatability by QRDeNameland · · Score: 2, Insightful

      Amen to that. To say that MS is finally fixing things like XMLHTTPRequest or PNG alpha transparency (which has only been around like what, 11 years or so?) in IE7 ONLY is somehow "making web developers' lives easier" when IE7 will only install to XP post SP2 or Vista is nonsense. You still have several different standards to code around until all those older versions fade into obscurity. Post some of these fixes back to 5.5 and 6.0 and maybe they'll actually make someone's life easier this decade.

      --
      Momentarily, the need for the construction of new light will no longer exist.
    5. Re:Backwards Compatability by Kelson · · Score: 2, Interesting

      Fortunately you can check by capabilities instead of sniffing UA strings, and lump IE7 in with other AJAX-capable browsers:

      if (native XMLHTTPREquest) {
              do native stuff
      }
      else if (ActiveX XMLHTTPRequest) {
              do ActiveX stuff
      }
      else {
              non-AJAX fallback
      }

      In a few years it'll be practical to drop the middle section, assuming XMLHTTPRequest hasn't been replaced by something more useful.

  3. Looks like Microsoft has a winning strategy . . . by mmell · · Score: 4, Insightful
    They've lost some ground to Firefox et. al.; if they can keep corporate America convinced that IE is "just as good" for what businesses want their browser to do, they'll continue to hold the hammer-lock on browsers in the workplace (remember, M$ doesn't need to convince all of us, just the PHB's among us).

    Begun the browser war has (again).

  4. And...? by wombatmobile · · Score: 5, Insightful

    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?

    1. Re:And...? by Daniel_Staal · · Score: 2, Interesting

      Impoved support for several of those is also scheduled for IE7. (We'll have to see how much improved when it is actually out, of course, but the reports at the moment are promising.)

      Microsoft has proven it can make a good web browser. When they are backed into a corner.

      --
      'Sensible' is a curse word.
    2. Re:And...? by Bogtha · · Score: 3, Insightful

      SVG: Microsoft implemented vector graphics in Internet Explorer years ago with VML, which they submitted to the W3C in 1998.

      CSS: A partial list of fixes regarding CSS that will be in Internet Explorer 7 can be found on the IEBlog. They've fixed a lot.

      PNG: Internet Explorer 7 will have support for the PNG alpha channel, bringing it up to the level of support that other browsers have.

      JPEG2000: JPEG2000 is patent encumbered. Mozilla/Firefox doesn't support it.

      XForms: XForms support is available through a plugin.

      The only really valid complaint you have there is their lack of support for the DOM. In particular, it would be very nice if they implemented DOM 2 Events, but I don't think that's likely to happen for Internet Explorer 7.

      --
      Bogtha Bogtha Bogtha
    3. Re:And...? by leighklotz · · Score: 2, Informative

      > are already well advanced with implementations of SVG, DOM, CSS, PNG, JPEG2000 and XForms.


      Only Firefox/Mozilla has XForms; sadly Opera and Safari don't.

      XForms, by the way, is the only stanrd to incorporate all the stuff that XMLTTHPRequest does, and it does so in a very easy way.

      For example, if you want to load up your del.icio.us tags you just do this in the <head>:

        <instance src="http://del.icio.us/api/tags/get" />

      Then you can list them like this in the HTML <body>:

        <repeat nodeset="/tags/tag">
            <output ref="." />
        </repeat>

      using the XForms <submission> tag, you can also do asynchronous HTTP POST of XML, of any instance in the page, and direct the results to come back to any instance. When the instance comes back, the UI automatically recalculates itself, and any UI widgets or groups (i.e., entire <div>s) that were bound to non-existent nodes suddenly appear in the UI when the data updates and the nodes appear. You can even make submission happen automatically when fields are exited or when menu items are changed, so forms can be completely dynamic with absolutely no JavaScript; just plain markup.

      As Rachel Ray says, "How cool is that?"

      Lately I've been using FormFaces (an entire XForms implementation for IE, Safari, and FF/Mozilla in AJAX/JavaScript) and Chiba (a Tomcat-based back end that outputs either plain HTML with no JavaScript for no-brainer ADA compliance, or AJAX-enhanced HTML for dynamic forms). These implementations are running neck-and-neck with the Firefox/Mozilla native one, and are catching up to the very advanced IE plugin FormsPlayer.

      If you want to see how to do the the dynamic XML features you get from HTTPXMLRequest but in a standards-compliant way and using simple markup, see XForms for HTML Authors.

      P.S. Since I got bashed for not saying this before, I have to add that I was one of the editors of the XForms 1.0 recommendation. Since I post under my real name and list the info on my website (and at the top of the spec ;-) I hadn't realized I needed to point out explicitly that I helped. But I'm not involved in selling implementations, only in using them.

  5. Only for Windows? by Johnny+Mnemonic · · Score: 3, Interesting

    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 .sig.tar
  6. IE is changing its tune by Anonymous Coward · · Score: 4, Interesting

    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.

  7. Hopefully, they'll keep the ActiveX Object... by DogDude · · Score: 2

    This is neat-o, and stuff, but I've been using the ActiveX object for back end services for many years now (4+ years?). I really hope that they keep the COM version up to date. It's been incredibly useful for longer than Firefox has even existed!

    --
    I don't respond to AC's.
  8. MS doing what it does best ... by SilicaiMan · · Score: 3, Interesting

    ... 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.

    1. Re:MS doing what it does best ... by AeroIllini · · Score: 2, Interesting

      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.

      But it won't happen that way this time. When Netscape died (the first time), there really were only two browsers in the market. When one didn't keep up, the other took over.

      This time around, there are lots of different browsers all working independently. Even if one browser does not innovate fast enough, there are many others that will. Microsoft is now fighting a multi-front battle, and they will never dominate the battlefield again like they did when the defeated Netscape. There are simply too many contenders.

      --
      For security, the MD5 hash of this message and sig is 09f911029d74e35bd84156c5635688c0.
    2. Re:MS doing what it does best ... by Jugalator · · Score: 3, Interesting

      It's good that MS is supporting web standards

      Just so we stay clear about this: MS was the first to support AJAX via XMLHttpRequest, so this is only a change in how they do it.

      Mozilla and Opera followed Internet Explorer here.

      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.

      Again, IE was the first to do.

      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.

      Hoq do implementing XmlHttpRequest support via non-ActiveX render other browser that already have it obsolete? This isn't some weird "lock out" strategy. Please lose your tinfoil hat, at least in discussions where there's absolutely no need to use it.

      --
      Beware: In C++, your friends can see your privates!
    3. Re:MS doing what it does best ... by Tim+Browse · · Score: 2, Insightful

      Isn't that a bit unfair considering that the feature in question first appeared in IE? They're just making it simpler to access. I'm not sure you can accuse them of 'embracing' something they came up with in the first place. It's a bit like saying that with Vista they're going to 'embrace and extend' the NTFS file system format.

      As I understand it, anyway. I've probably got something wrong though.

  9. Re:I dunno.... by Chokolad · · Score: 5, Informative

    > 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...

  10. But will their web apps? by TerenceRSN · · Score: 2, Insightful

    It's nice that MS is making this change but I'm more curious about whether their web applications will work without MSIE specific technologies. Example: Outlook Web Access isn't feature full on non-IE browsers. Also live.com and the new hotmail interface are still limited. Project Web Access is another one. Until these applications work without IE it won't be possible for a lot of businesses to move away from IE.

  11. A Nice Step by AnalystX · · Score: 2, Interesting

    I was wondering about this very thing just last week. It's definitely a step in the right direction. Now if only MS would care enough to create a browser that behaves and renders more closely to the already superior browsers like Firefox and Safari. Web designers would no longer have to go through the anguish of browser detection for things as simple as page layouts. There's nothing like spending 2+ hours trying to get a single page template to render the same in IE and Safari/Firefox using only CSS. Next on my list: Could Apple please provide better DOM & XPath support in its Safari Javascript engine?

    1. Re:A Nice Step by Bogtha · · Score: 3, Insightful

      Why shouldn't Firefox and Safari render more closely to the way that IE does it?

      What makes more sense?

      1. The developers of browsers A, B, C and D get together and write down how something should work.
      2. The developers of browsers A, B, C and D go off and implement what they've agreed upon.

      ...or:

      1. The developers of browser A implement something.
      2. The developers of browsers B, C and D wait for browser A to be released.
      3. The developers of browsers B, C and D try to reverse-engineer what the developers of browser A have done, while the developers of browser A implement version 2.0.
      4. The developers of browsers B, C and D implement what they hope is the correct behaviour while the developers of browser A release version 2.0.

      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
  12. oh let's not talk standards by ashpool7 · · Score: 4, Informative

    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?

    https://bugzilla.mozilla.org/show_bug.cgi?id=10713

    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...

    1. Re:oh let's not talk standards by unapersson · · Score: 2, Insightful

      And lack of support for this property has exactly how much of a side effect? Surely you can do better than that.

      This is just eye candy, IE6's flaws are deep and pervasive. If IE7 can fix some of these that'll be a big step forward.

      Mozilla's most important CSS2 shortfall is support for inline-block, but as with other properties, no support is better than buggy support.

    2. Re:oh let's not talk standards by mumrah · · Score: 2, Insightful

      And IE6 doesn't fully support CSS1. I imagine there are few browsers that fully support any web compliance. Just sayin

    3. Re:oh let's not talk standards by Carewolf · · Score: 4, Informative

      Bad example. Text-shadow was deprecated in CSS 2.1 which fully supercedes CSS 2.0. Better examples are that Firefox doesn't support:
        * display: compact and inline-block
        * content: counters and quotes (recent version has quotes)
        * min/max-width/heigth (recent versions support it very limited)

      There are a couple more. These are also the primary reasons Firefox cannot easily pass Acid2.

    4. Re:oh let's not talk standards by Bogtha · · Score: 2, Informative

      Firefox doesn't even support "display: inline-block": bug 9458. That's CSS1!

      No, inline-block is present in a draft of the CSS 2.1 specification. Before that, it was a proprietary Internet Explorer property. It wasn't part of CSS 2.0, it wasn't part of CSS 1.0, and it isn't part of any finished CSS specification yet.

      --
      Bogtha Bogtha Bogtha
  13. iFrames? by Bovarchist · · Score: 2, Insightful
    OK, so what is wrong with using iFrames? Is AJAI not a sexy enough acronym?

    Seriously. IFrame support has been around for quite some time and works well in most major browsers. You just hide the iframe and communicate to the server through it. I've done this lots of times, long before AJAX was around. It even worked in IE 4 and NS 4.7x if I remember right.

    Sure, its not as elegant as using XMLHTTPRequest, but when is cross-browser javascript ever elegant? Is it better to have a hidden iframe on your page, or several lines of IE-specific code and dependence on an ActiveX control?

    That's just my 2 clams. I've only just started working with XMLHTTPRequest, so I might be missing something. Please enlighten me if there is some major advantage that I'm not seeing.

    --
    Hell is other people's code.
  14. What Internet Explorer 7 *REALLY* needs... by TodLiebeck · · Score: 5, Informative

    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):

    • Implement document.importNode()
    • Support setting of opposite side CSS positioning properties at the same time, i.e., setting "left" and "right or "top" and "bottom" properties on same element.
    • Fix this problem: http://support.microsoft.com/default.aspx?scid=kb; en-us;177378 Documenting a design flaw does not make it any less of a design flaw.
    • Fix other problems with SELECT element, e.g., the fact that it is not possible to add a ListBox-style select to a document using DOM manipulation.
    • Fix bug where the presence of a vertical scrollbar adjacent to a 100% wide table inside of a CSS positioned element results in a horizontal scrollbar due to incorrect width calculations.
    • Fix issue where 100% wide textareas expand to be a bit wider (creating a horizontal scrollbar) once text is entered. This also only occurs if the text area resides in a CSS positioned DIV.
    • Correctly monitor the DOM for updates and repaint appropriately. Currently there are cases where IE will not repaint the screen even though the DOM has changed, requiring the developer to perform additional DOM manipulations just to trigger a repaint.
    • Fix this completely insane bug (scroll down to a few paragraphs or search for the text "worst bug ever in Internet Explorer 6."
    • And last but definitely not least, simply bring the performance up to a level relative to Firefox/Opera/Konqueror/Safari, especially when dealing with reasonably complex and interactive DOMs.

    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.

    1. Re:What Internet Explorer 7 *REALLY* needs... by TodLiebeck · · Score: 2, Interesting
      IMO, document.addEventListener() is more important than any of those. Many of your issues can be worked around, and some of them can be worked around rather trivially. However, there is no way in IE to match the functionality of addEventListener, with any amount of hacking.

      Definitely agree that all my listed issues can be worked around, but I wouldn't go as far as to say it's trivial to do so. Here are the current workarounds I use in IE for these problems:

      • Implement document.importNode() Workaround: Create your own importNode implementation.
      • Support setting of opposite side CSS positioning properties at the same time, i.e., setting "left" and "right or "top" and "bottom" properties on same element. Workaround: Use IE's proprietary "CSS expressions feature" to dynamically calculate width/height of elements (just make sure you account for padding).
      • Fix this problem: http://support.microsoft.com/default.aspx?scid=kb; en-us;177378 Documenting a design flaw does not make it any less of a design flaw. Workaround: render IFRAMEs behind z-indexed DIVs that must obscure select field elements. Unfortunately this does not work in combination with PNG transparency (using DXImageTransform.Microsoft.AlphaImageLoader hack of course).
      • Fix other problems with SELECT element, e.g., the fact that it is not possible to add a ListBox-style select to a document using DOM manipulation. Workaround: Create your own DHTML listbox implementation.
      • Fix bug where the presence of a vertical scrollbar adjacent to a 100% wide table inside of a CSS positioned element results in a horizontal scrollbar due to incorrect width calculations. Workaround: Limit tables to 95% wide when rendering IE (dirty hack IMHO).
      • Fix issue where 100% wide textareas expand to be a bit wider (creating a horizontal scrollbar) once text is entered. This also only occurs if the text area resides in a CSS positioned DIV. Workaround: Don't use percent widths on textareas.
      • Correctly monitor the DOM for updates and repaint appropriately. Currently there are cases where IE will not repaint the screen even though the DOM has changed, requiring the developer to perform additional DOM manipulations just to trigger a repaint. Workaround: "Tickle" properties of other elements in DOM that are known to cause update, i.e., set value to something different, then set it back. This problem shows up very rarely but can be very annoying when it does. This solution is even uglier than the problem.
      • Fix this completely insane bug (scroll down to a few paragraphs or search for the text "worst bug ever in Internet Explorer 6." Workaround: Fix described in blog entry.
      • And last but definitely not least, simply bring the performance up to a level relative to Firefox/Opera/Konqueror/Safari, especially when dealing with reasonably complex and interactive DOMs. Workaround: Keep your DOM as simple as possible (which is obviously a good idea anyway, but nevertheless can sometimes prevent the development of certain AJAX components from being practical.


      Just curious if you happen to know of better/simpler workarounds for any of the above? (Please note, this is not a rhetorical question/argumentative response, I'm genuinely curious if you've come across something better, as I'd be extremely happy to find better solutions for any of the above!)

      And I do agree on the signifance of not supporting the proper W3C events, at this point I'm simply resolved that event capturing is only a figment of my imagination.
  15. Work vs. Personal Coding by Cyphertube · · Score: 2, Interesting

    Well, this will be a nice change if IE7 is going to play nice.

    For work, I guess I will still have to plan workarounds for IE6. However, I generally only support such browsers officially as long as they receive actual support from their publishers. So, as soon as MS drops support for IE6, so will I (unless I'm ordered to keep it up).

    Personally, I code to whatever standard I've chosen for the day. If I decided to code to CSS 2.1 and I can see it properly in my browser, well, then I'm happy. Because it's my personal stuff. And if IE7 supports something and IE6 doesn't, well too bad. And same goes for Firefox, Safari, Konqueror, and Opera (although it'll be rare that Opera causes me problems, except when a version has tried to pretend it was IE, but that was work anyway).

    Mostly now, since I've grown into being some lazy business analyst with a messy house under renovation, I just blog anyway.

    --
    Linux - because it doesn't leave that Steve Ballmer aftertaste.
  16. Not news by Bogtha · · Score: 5, Informative

    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
    1. Re:Not news by Bogtha · · Score: 2, Informative

      This matters because it will allow people to use sites like GMail while still disabling or tightly restricting ActiveX for security purposes.

      This is already possible today with Internet Explorer's zones. Put GMail etc in a zone with ActiveX enabled, and disable ActiveX for everything else.

      --
      Bogtha Bogtha Bogtha
  17. Ajax over IFRAME - more compatible? by code4fude · · Score: 3, Interesting

    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?

    1. Re:Ajax over IFRAME - more compatible? by AnalystX · · Score: 2, Informative

      There are several benefits to the XMLHttpRequest object over IFRAME. I won't go into all of them, but essentially XMLHttpRequest provides an object interface (with all of its due properties and methods) to help you as the developer manage the synchronization and transmission status at a lower level. On a related note, if one is running PHP, one can also user another alternative:

      http://www.phpit.net/article/ajax-php-without-xmlh ttprequest/

    2. Re:Ajax over IFRAME - more compatible? by drew · · Score: 2, Informative

      I started using the iframe method back in 2001, and I've pretty much converted entirely over to xmlHttpRequest. The two main reasons:

      1) IE makes a 'click' sound every time you navigate to a new url in a window or frame. using xmlHttpRequest gets rid of this.

      2) Using xmlHttpRequest doesn't pollute your history, so it makes it a easier to make something useful happen when the user hits the back or forward button.

      Generally speaking, compatibility isn't a problem- most of the time that I need to implement something using AJAX, any browser that doesn't support xmlHttpRequest will also not support some other feature that I am using anyway. The one exception here seems to be Opera browsers in the upper 7.x range, as IIRC Opera didn't get a usable xmlHttpRequest until 8.0. But personally, I'm not going to lose too much sleep over that.

      --
      If I don't put anything here, will anyone recognize me anymore?
  18. Except that.... by brunes69 · · Score: 4, Informative

    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.

    1. Re:Except that.... by Stan+Vassilev · · Score: 3, Insightful

      "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."

      If you RTFA you'll see the benefit is for those organisations that have ActiveX turned off for security reasons (lots of em).

      On the IEBlog you have a code snippet showing how you create the native XMLHttpRequest object for Opera, FF and IE7, while fall back to ActiveX for IE6 and earlier.

      So there IS benefit. And no, it's not a simple scripting shortcut at all.

  19. Informative my ass! by shrubya · · Score: 2, Insightful

    Complaining that Firefox doesn't support a couple minor CSS2 features is like saying "You can still die in a car with crumple zones and air bags, so you may as well drive a 1972 Ford Pinto".

  20. Embrace and extend my ass... by melted · · Score: 5, Funny

    Goatse, is that you?

  21. IE7XMLHTTP?? by Nanite · · Score: 2, Funny

    OMGWTFBBQ!!

    --
    God is real unless declared integer.
  22. ISV's lives become easier. by Tenk101 · · Score: 3, Interesting


    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.

  23. Re:So basically... by ad0gg · · Score: 2, Informative

    Slower? Umm, no. Firefox is great for casual viewing, but when you doing research for a paper and have 10 to 20 tabs open. Its dog slow and uses 400 megs of ram which is insane. IE is faster than firefox, and opera is faster than IE and if you're on a mac, safari blows them all out of the water in sheer speed and memory usage.

    --

    Have you ever been to a turkish prison?

  24. This is newsworthy? by djdole · · Score: 2, Funny

    This is like reporting about the 12th man to finish a particular marathon. Not really what I'd call newsworthy.

    OK...slightly newsworthy...
    The guy's an inbred, with dumb-as-dirt parents.
    The guy's an overweight diabetic needing constant dialysis.
    The guy's a cripple with glass for bones that can and will break whenever touched.
    AND...The guy is the paperboy/newsman (information provider) for hundreds of thousands of people.

    ...And he finished 12th in the marathon.

    /Firefox. First Place. Falls to ground laughing and pointing at out-of-breath MS finish.

    1. Re:This is newsworthy? by leerpm · · Score: 2, Interesting

      Sorry to burst your bubble, but MS invented the whole idea of the XMLHTTPRequest object. They already crossed this finish line 7 years ago.

  25. true by ashpool7 · · Score: 2, Insightful

    Reference
    http://www.w3.org/TR/2004/WD-WCAG20-CSS-TECHS-2004 0730/#text-shadow

    My point was that FireFox/Gecko is not the paragon of standards compliance, so dragging IE into the "you don't comply" mud is hypocritical. Indeed there are more important things to make work, but nevertheless, compliance is incomplete.

    To that effect, since CSS2 came out in 1998, and CSS2.1 in 2005, I would have expected text-shadow (along with the other things you listed) to get fixed in that time frame. What have the FireFox devs been doing?

    1. Re:true by starwed · · Score: 2, Insightful

      I don't think you really understand the CSS standard. CSS2.1 replaces 2.0, in the process getting rid of some properties which proved too problematic. There are parts of the CSS2 spec which are contradictory. Should Firefox implement that too? ^_^ It doesn't matter whether 2.1 has "draft" status or not; it's the superior standard, and one the w3 advocates adhering to.