More Updated Documentation


The information published in this post is now out-of-date and one or more links are invalid.

—IEBlog Editor, 21 August 2012

We’ve recently published some articles and a few updates on MSDN. Here are some particularly useful articles:

As always we welcome ideas for areas where we should focus our documentation efforts.

Thanks
– Dave


Comments (34)

  1. Anonymous says:

    Very useful. I like the update about chromeless popups. I can see some of my old work will be failing, somewhere.

    Something of a shame we have to lose this functionality, but to be honest, I never saw too many valid applications of it on the web.

    Will the documentation for any new restrictions in IE7 be published at the same time as its release?

  2. Anonymous says:

    <sarcasm>Nice to see promotion of standard methods – especially the heavy recommendations about innerText…</sarcasm>

  3. Anonymous says:

    Will IE7 support browser themes?

  4. Anonymous says:

    IE7 will not support themes, the IE team is depending on Maxthon to fill that hole…

  5. Anonymous says:

    > As always we welcome ideas for areas where we

    > should focus our documentation efforts.

    I’d love you guys to document the "layout" issue:

    http://www.satzansatz.de/cssd/onhavinglayout.html

  6. Anonymous says:

    re: faster DHTML

    I’d read about modifying someEl.style directly rather than someEl.className to enhance performance. However, PPK of Quirksmode did benchmarks recently and concluded that changing the element’s class was faster:

    http://www.quirksmode.org/blog/archives/2005/07/benchmark_tests.html

    Try the test for yourself:

    http://www.quirksmode.org/dom/classchange.html

    Might this be different in other circumstances? Say, very large and complex documents with lots of style rules?

  7. PatriotB says:

    "As always we welcome ideas for areas where we should focus our documentation efforts."

    I’d like to see some documentation on the integration between IE components and Windows Shell components. A few months ago, a number of technical interfaces (e.g. IBrowserService) were documented, probably for legal reasons. However it’s highly unlikely that anyone would actually be able to find that documentation of any use. For all of this additional documentation, we need overviews and examples so that we can actually understand what’s going on.

    Thanks!

  8. In the "MIME-Types" article cited above, there are several references to:

    "content-disposition=attachment" in the HTTP header,

    Actually, HTTP headers are of the form:

    Main-Name: value1; sub-name=value2;

    so the HTTP header actually looks like

    Content-Disposition: attachment; filename="the file.txt"

  9. Anonymous says:

    Is there any way of getting IE to display a plain text file (text/plain) containing a HTML DOCTYPE tag the way the author/webmaster intended, instead of displaying it (wrongly) as HTML?

  10. @ ant: yes

    http://www.winguides.com/registry/display.php/1155

    HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersion

    Internet SettingsIsTextPlainHonored

    DWORD – set to 1

  11. Anonymous says:

    Hi,

    I would find it useful if the docoumentation had dates of when it was created and when it was last updated. Sometimes this isn’t essential, but it gives a good feel for the "freshness" of documentation, which helps when troubleshooting a problem.

    Cheers,

    Dave.

  12. Anonymous says:

    I see nothing in the Windows Restrictions about making the window.opener property read-only. This would close a gaping security hole that allows scripts to bypass the warning dialog when closing windows they didn’t open by setting the property to a nonsense value.

  13. UnexpectedBill says:

    There’s a lot to be said for documenting the insides of Internet Explorer…it’s a good idea no doubt so that web developers know what is out (in?) there.

    But what I’d really like to see is a massive overhaul of the "userland" help for IE and Outlook Express 7 (whenever that’s coming). Right now the help system seems to gloss over most topics and assumes that other functions will just "be understood" by the user. It would really be nice to see each feature described with a page of help information.

    Oh, and one more thing I’m really curious about–I know that the Trident Rendering Engine contains debugging information context menus. Is it possible for an everyday person to enable these and see how Trident reacts to certain pages?

  14. Anonymous says:

    > Is there any way of getting IE to display a plain text file (text/plain) containing a HTML DOCTYPE tag the way the author/webmaster intended, instead of displaying it (wrongly) as HTML?

    If I’m reading the documentation correctly, adding this HTTP header will do it:

    Content-Disposition: inline

    It’s a workaround for the bug though, not standard behaviour. It would be nice if this was fixed for Internet Explorer 7.

    Anyway, thanks for updating this particular documentation, IIRC, I asked for this a while back.

    I’m a bit puzzled by your use of terminology though, with sentences like:

    "In the DHTML object model, text content for an HTML element is accessed through the innerText property, whereas the W3C DOM provides a separate child text node."

    You make it sound like DHTML is something exclusively provided by the IE object model, rather than a buzzword covering a range of technologies implemented by most browsers. Wouldn’t it be better phrased as "In the IE object model…" instead? You guys don’t own DHTML.

  15. Well, hopefully if a user is sophisticated enough to be able to read raw HTML, they’re sophisticated enough to make a registry change.

    Although once they make the change, they’ll be at the mercy of all the webmasters that didn’t correctly set the MIME-type. I suppose in the ideal world the registry key would be called

    HonorTextPlainForTheseSites

    and take an array of strings (each of which is a site name)

  16. Anonymous says:

    Wow

    I really do have to go through all those jokes now and change all the references to "complaining old maids" to "webmasters"

    Great, like I really need the extra work to do.

  17. Anonymous says:

    Well, thanks for letting us know your alive, I guess. But MSDN isn’t really the place developers go for enlightenment. Articles like these are partly why. Although it is definitly an improvement from the rounded corners last time. Hopfully it will continue to get better. I for one would really like some articles on the *real* DOM, and mabye even Level 2 😀

  18. Anonymous says:

    Never use document.URL myself, but I’ve been debugging recently.

    MSDN Documentation says: document.URL is an alias for location.href

    However, this does appear to be so for local files. They are not reporting querystrings to document.URL. That’s quite obscure – is that a local machine restriction, or just a documentation error? Perhaps MS can add a bug-reporting link to the documentation pages?

  19. Anonymous says:

    Michael Cherry: we blogged about the Peekaboo bug earlier. http://blogs.msdn.com/ie/archive/2005/04/22/410963.aspx

  20. Anonymous says:

    Christopher: how exactly did MS fix the Peekaboo bug? By forcing hasLayout in certain circumstances (meaning a hack) or did MS implement a new and fundamentaly better solution for the problems with the float-model?

    In the latter case (which I hope is the case) would that mean that we can also expect more and better support of CSS? If it’s the first case (which I suspect is the case) I just keep my fingers crossed it doesn’t break something else.

    Kenneth: document.URL cannot be an alias of window.location.href. location.href can be different from document.URL in case of redirects. Also the specification states that document.URL should contain the full URL of the current document; querystring is part of the URL so should be present (and e.g. in Gecko it is). It seems to me that MS has once again implemented something wrong here…

  21. Anonymous says:

    I’d like to see more up-to-date documentation and examples on IE’s low-level interfaces. Areas I’ve found where improved documentation is helpful:

    DOCHOSTUIFLAG – some flags seem to be missing from the list and others should be on the list

    ISelectionServicesListener – This does not seem to do what the documentation states especially with regards to undo events

    IHTMLChangePlayback – any examples on how this can be used would be useful

    HTML_PAINT_XFORM – this structure never seems to return a transform if ‘zooming’ into an element

    In general, IE’s low-level interfaces are extremely powerful but a lack of documentation makes them difficult to use.

  22. Anonymous says:

    C’mon you guys release a date for the beta release of the next Windows, but you can’t release a beta date of the next IE???

  23. Anonymous says:

    How about if you focus some of your documentation efforts on explaining to people why MSDN blog feeds use HTTPS links, which is unnecessary and annoying, especially when a feed-reader pops up a certificate warning FOR EVERY SINGLE LINK IN YOUR FEED. Bah.

  24. Anonymous says:

    Why isn’t there better information on IE bugs. For example, I have spent several days hunting down a problem that appears to be called the peekaboo problem. Only occurs on IE from what I can tell. Yet cannot find anything about a work around for this on a Microsoft site. What did I miss? Is it hidden somewhere?

  25. Anonymous says:

    Got any ETA on the beta?

    I’ve heard june, and june has passed.

    I’ve heard this summer, and the autumn is fast approaching.

  26. Anonymous says:

    According to Quirksmode and my own tests, innerHTML is faster than createElement/appendChild. Using HTCs also decreases performance. That article needs to some serious revising.

  27. Anonymous says:

    @ Maurits: How do I convince all my IE-using site visitors to go into their registry and do that?

  28. Anonymous says:

    Tell me that documentation is standards compliant.

  29. Anonymous says:

    DXImageTransform & Printing

    Dear Sirs,

    I have tested printing on IE with objects rotated through the DXImageTransform filter and noticed that on some ( all? WinMe? ) Win98 Standard/Second Edition ( with actualized DirectX components ) the objects do not appear. What is occuring?

    Thanks,

    Marcus

  30. Anonymous says:

    Dear Sirs,

    It seems to me that there are a little misconcept in the rotation feature of the BasicImage DirectX filter. Let us take the following code fragment:

    <div id="objectContainer" style="width:100px; height:200px; background:#e0e0e0; filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=3)">

    objCont

    <div id="object0" style="width:30px; height:30px; position:relative; left:10px; top:10px; background:#ffe0e0">obj0</div>

    </div>

    I think that even when "objectCotainer" is not "positioned" ( that is, does not has CSS "position" defined as "relative", "absolute" or "fixed" ) "object0" should be rotated when relatively positioned — what, currently, doesn’t is the IE behavior. This appears a misconcept because "relative position" implies a integral conformance with the recipient’s coordinate system, thing that in the above exposed case doesn’t occur.

    Thanks

  31. Anonymous says:

    Silent Changes on the InfoTech Protocol… and Other Questions on File Extensions

    Dear Sirs,

    It seems that have occurred a slight and silent change on the behavior of the InfoTech Protocol that isn’t explicitly documented anywhere: it no more accepts files with missing extensions. Obviously, this is part of the changes related to "SP2 File Types Assurance", let us say. But, a little question: this should apply to cases where aplications ( HTAs included ) are invocating the address pointing to such a file?! The same question would arise with respect to HTML Documents with missing extensions and an unequivocal DocType declaration, that are apparently also being rejected.

    Thanks

  32. Anonymous says:

    The popup behavior is still bugging the hell out of me, mainly because certain ads have figured out how to bypass it (Drudgereport is particularly nasty). Same thing happened with Google’s toolbar, too. I suspect it’s Shockwave being misused (only ActiveX control I see in my list that is capable of even doing it), but it would be a nice feature to have some kind of detailed logging to see what specifically caused the popup bypass.

    Real good to have the actual behavior documented, though; helps me narrow down what isn’t the cause

  33. Anonymous says:

    I would like the ability to customize the Links Toolbar so that I can create one or more rows and modify the attributes for individual links on the bar. Further, I would like the ability set multiple "home pages" within the TABS so that when I launch IE it auto-launches each of the pre-set TABS into their respective home pages thus allowing me to quickly access key corporate and non-corporate content sources.