IEBlog

any new news on ie next now that windows 7 has rtmed

Funny thing: I just compared your tool with other ones

http://www.favbrowser.com/internet-explorer-developer-tools-vs-firefox-firebug-vs-safari-web-inspector-vs-opera-dragonfly/

What's a Jscript variable? is that like a JavaScript variable? if so don't bother using MS-only names when talking about web development.

Call it JavaScript or don't talk about it at all.  Nothing is more frustrating to us developers than to hear MS try to apply their own name on something that is already widespread.

Its as bad as hearing people talking about bing'ing things.  You can't be taken seriously when you talk like this.

@Harvey: Let me help you understand.

JScript is Microsoft's implementation of ECMAScript. JavaScript is Mozilla/Netscape's implementation.

If you think the semantics are the most important thing, you probably should be using the term ECMAScript. But, I don't think anyone, anywhere, is likely to be confused or frustrated by this post.

Paul: Your post frustrates me, and your comment does as well.

JScript and JavaScript might have referred to implementations in the mid '90s, but not in the last ten years. Today, JavaScript refers to the scripting language that extends ECMAScript, as implemented by browsers. Mozilla's implementation of JavaScript has its own name: "SpiderMonkey" (technically, Mozilla has two engines, since they also host an engine written in Java: "Rhino"). WebKit has its own JavaScript implementation, as does Opera.

IE may only support its own backward almost-JavaScript language ("JScript"), but we all write JavaScript. When we debug scripts in IE, we debug JavaScript. When we read articles on Ajaxian.com on some cool client-side scripting, we certainly don't go to the "JScript" category.

@Whiner: You need to get over your hate and work on your understanding. That will help you write factual statements.

"SpiderMonkey" is a JavaScript engine. It runs "JavaScript" which is Mozilla's dialect of ECMAScript. Incidentally, JavaScript was a poor choice of name (as JavaScript has nothing to do with Java) but at the time Netscape implemented it, Java was hot and they wanted to ride its coattails in the media.

JScript is Microsoft's dialect of ECMAScript. When you're running script in IE, it's JScript. The fact that it's understandable as JavaScript is true, just as British English is understood by American English speakers and vice versa.

I remember when the IEBlog had worthwhile comments. It's been a while.

That should have read "This post frustrates me, and your comment does as well."

A long day of debugging JavaScript in IE affects my concentration, I guess.

Calling it JScript when talking to web developers is a waste of time.

In this day and age we call it JavaScript.  I don't care if your implementation of ECMAScript is called "head cheese" or "walrus tongue" no one is going to refer to it as anything other than JavaScript.

AJAX stands for Asynchronous JavaScript And XML

have you heard anyone, anywhere call it:

Asynchronous JScript And XML? of course not!

Regardless - lets stop fighting over other names to describe JavaScript and focus on the post topic.

When will the IE Developer toolbar get updated next? there are several bugs with it that have been documented since the early IE8 beta days but I haven't seen any updates since RTM.

Since the dev toolbar does not affect sites or applications running in IE it most certainly shouldn't be tied to the glacial release schedule of IE.

For starters can we get an update that shows the (X)HTML tags in the case we supplied them - not some horrible mish-mash that IE6 used to spew out.

thanks

@The Hater

"A long day of debugging JavaScript in IE affects my concentration, I guess."

I though that IE had JScript not Javascript. Maybe thats why it tool you all day.

Thanks for the links. I tried changing the onsubmit property of a form and it didn't work. Forgot I could just use the console and do it that way :P. (yeah, I generally avoid the attribute-based events stuff but you encounter all sorts of fun in older code)

@Mike

ROFL

@Harvey

Mountain out of a molehill.

@The Hater

So is it "backwards Almost-JavaScript" or JavaScript? Have you made up your mind yet? You could just call it JScript...

How to check the supportivity of tags in IE

such as <basefont> in IE8

I develop a lot of code that makes use of XML configuration files (as well as some XSL file to transform them).  Every now and then I manage to mess them up and they become invalid XML files.

This is fine as I can load the pages directly in my browser and get immediate feedback as to which tag isn't closed or which attribute is duplicated etc.

However when I load them in IE (off my local file system) IE thinks they are magically infected with ActiveX and refuses to render them fully until I give explicit permission.

I realize the risk in doing so, but where on earth do I find the setting that shows this warning bar so I can turn it off permanently for local files. (again, I hereby realize the risk and want to not see the bar)

On a related note, since the file is XML text, with absolutely no executable content why on earth am I even getting this security bar in the first place?

tx

@Jackie - the best resource I know of for this is SitePoint.

http://reference.sitepoint.com/html/basefont

For every tag/attribute available (as well as CSS/JavaScript) they list all the info you'll normally need.

PS for the record though, it looks like it hasn't been updated for IE8 yet. :-(

@laranson: You're seeing the prompt because IE is using an ActiveX control/DocObject (MSXML) to transform the XML with the XSL, and the XSL could contain JavaScript.

I believe you SHOULD use a "Mark of the Web" in the XML rather than turning off security features, but if you're more comfortable putting your security at risk, tick the box "Allow Active Content to run in files on my computer" inside Tools / Internet Options / Advanced / Security.

I should clarify that I'm just loading an XML or an XSL file (with no transformations being applied at all).

I am purely wanting to render the XML in a "pretty" tree format and (if) there are structural issues with the XML formating (e.g. a closing tag is missed) that some sort of error is shown on screen.

What is driving me nuts is that opening any XML based file in IE is forcing me into manual steps that I don't need to worry about in other browsers.

Maybe that is the solution. Just use a different browser that doesn't hinder me.

@laranson: When you open a plain XML file, it will immediately show any errors without an information bar.

If there are no errors, then it will show an information bar that does not block your ability to view the file in any way; the information bar notifies you that the script (which is used to provide the expand/collapse feature of the nodes) has been blocked due to the setting I described.

Of course, there exist far better XML viewing/debugging tools than any web browser provides, including Visual Studio and many free tools.

http://www.msie.com/

You guys planning on doing anything to the RegCure people using that domain?

Interesting claims (nonsense) they're making:

* "Repairs ALL errors"

* "Speeds Up PC Performance by Over 100%!"

@DomainSquatter: I don't see how they could, since they don't have a trademark on MSIE-- it's called "Windows Internet Explorer" these days anyway.

This is definitely better than what I've used before

Jackie, I also use sitepoint for that, it works well.

Will the team start to reply to open Connect bugs soon so we can start to see what is being looked at for the next version?

Will we know if the next version will be a quicker to rtm .5 release or a full blown but longer to market full version?

in the next beta will the offical testers get more than one non public interum build like at least priveate build in between each public build?

@Harvey - "JavaScript" is trademarked by Sun (see: http://www.sun.com/suntrademarks/ ). MS probably calls their implementation JScript to avoid legal issues.

@RegCure Domain Squatting

Yes, registry errors are often a leading cause of Internet Explorer problems. To avoid them, it is highly recommended that you DO NOT use tools like RegCure, CCleaner, or heck, even Windows Live OneCare (http://onecare.live.com/site/en-Us/article/registry_cleaner_why.htm), unless you *already* have a problem that appeared *before* you *ever* used such a tool on your current Windows installation. And even then, it's never guaranteed that you'll clean up the right stuff.

I would gladly tell that to the msie.com site, but they moderate comments, which means they'll ignore anyone who speaks badly of their product, and let only the good ones in.

As for the MSIE team doing something... the best they could do is buy the domain from the owners on an agreeable price, but that seems unlikely. The next best thing would be to simply release various advisories that tell people to avoid registry cleaning tools. While righteous and true, this could be seen as "Microsoft trying to kill people's business", so due to fear of legal issues, that seems unlikely too.

@Will Peavy - yes Sun has a trademark on JavaScript but when talking about Script for the web in general everyone says JavaScript.  You wouldn't go onto StackOverflow to ask a question and say "The JScript on my site isn't working" you'd say "The JavaScript on my site isn't working".

As far as developers and end users are concerned, its all JavaScript.

When my wife goes to a site that fails in IE she says it has JavaScript errors - she couldn't care less what the error is she just wants it to work so she'll load it up in Firefox instead (I've tried to convince her to start using Firefox instead but she's like many that fear newer (likely better) things)

I'd hate to see the reaction if you went for a development position interview and when asked about your web expertise you answered with "I've been programming in JScript for 6 years" - I think it would qualify as the first red flag that you are (a) not a good developer or (b) lying through your teeth about your experience.  I surely wouldn't hire anyone that used the term.

As for the developer tools (topic) the tools in IE8 are much better than previous.  Is there any chance you will merge the stuff from IE sIEve into the tools so we can track IE memory leaks?

The Text nodes don't need the prefix "Text - " it just wastes valuable real estate and the color coding gives away the fact it is text.

The script blocks need to be expandable, and show line breaks and indents properly.

Not showing the closing tag of elements is a really poor choice.

It makes finding issues very difficult because the visual tree does not represent the code specified by the developer, please add the closing tags back in.

When you do this you can get rid of garbage like the "Text - Empty Text Node" because that is so counter-intuitive when a simple open and close tag would have perfectly described the node without the extra fluff.

IIRC generated elements show UPPERCASE tags which is SOOOO wrong on so many levels. Please do not do this.

The CSS data is again in the wrong case for tags, mixed case for some tags.classnames etc.

The order is also wrong for things like borders. should be "1px solid black" not "black 1px solid"

properties should be listed in alphabetical order.

In the script panel (possibly elsewhere) there is a space after the href attribute value of hyperlinks that should not be there.

Finally on the profiler tab when I click on any script in the call tree every function shows an alert message saying there is no source code for this location???

All in all it isn't that bad.  Its still a few hundred nautical miles away from being close to Firebug - but closed development is like that.

A few corrections...

Javascript is called thus because it was, at the beginning, a language developed by Netscape to allow Java applets to interact with a page's content (all there was before was static HTML tag soup, see - and the DOM wasn't even a notion).

It wasn't supposed to become a standalone programming language, but well, it did; and because a language works best when it's normalized, it was standardized through ECMA and nicknamed ECMAscript; and Javascript is ECMAscript-compliant, like ActionScript is. And Jscript is too, supposedly.

Now however, there are several implementations of Javascript:

- Chrome's Javascript engine is V8

- Safari's Javascript engine is JavaScriptCore, based on KJS

- Firefox's Javascript engine is SpiderMonkey, expanded through TraceMonkey

All of these recognize MIME-types such as 'application/ecmascript' or 'text/ecmascript' or (legacy) 'text/javascript'; they ARE Javascript engines, and more often than not they base themselves off Mozilla's documentation for their own Javascript language (it's a safe bet, nowadays, to program to Javascript version 1.5 to 1.7 in any of these browsers).

Jscript is Microsoft's ECMAscript-compliant engine. It is NOT Javascript, eventhough the only MIME-type it understands is 'text/javascript'; it has proprietary extensions such as conditional compilation and isn't based off Mozilla's Javascript language description; instead, it's based off ECMAscript with a few legacy Netscape extensions.

In short, current Web developers that program client-side software, without doing browser detection nor object fallback program to a common subset to both languages: ECMAscript loaded through legacy 'text/javascript' MIME-type with legacy Netscape extensions and core DOM 1.

Mind you, this is enough to do some nifty stuff already; but it would, of course, be much better if IE actually supported Javascript (and, just because event cascading and bubbling is nice and impossible to emulate properly using IE's event object, DOM 2 events...).

When one actually DOES Javascript now, then either IE is left out, or a corresponding bit of Jscript is written and there's browser detection and object fallback somewhere.

The objection that can be made to this MS-created documentation is thus that elements that are part of ECMAscript should be names such, and MS-specific extensions should be referred to as Jscript elements - that would help TREMENDOUSLY in developing cross-browser code, as those parts labeled 'ECMAscript' are cross-browser, while Jscript ones are IE-specific.

@Toman - As far as I'm concerned, you could call all client-side scripts "bananas". I look at someone's code to see if they are any good.

"I'd hate to see the reaction if you went for a development position interview and when asked about your web expertise you answered with "I've been programming in JScript for 6 years"

Some of my users (that have upgraded to IE8) are reporting that between loads of pages on the same site (with very little content change) are now flashing white before showing the next page.  This doesn't occur in IE7 or IE6 or any other browser.  Is this a known issue? Is there a fix?

Thanks

@Mitch74: When you're going to write "corrections," I hope you'll agree that accuracy should be your goal. Unfortunately, nearly every statement you made is incorrect, and since you have cited no sources, it leads one to wonder whether you were misinformed or simply decided to make this stuff up.

Your history of the language is entirely inaccurate, the language isn't "nicknamed" ECMAScript-- it's named that (Google "ECMA 262"), IE recognizes more than one MIME-type, DOM eventing is NOT a part of the scripting language at all, etc, etc, etc.

Please don't write if you can't be bothered to write accurate remarks.

@Philip: Website visitors say all sorts of things. You should provide URLs that reproduce the problem and explain what debugging you've done so far.

When viewing the source of a page in IE the text-highlighting is very anoying.

Not the coloring, but the physical text drag-to-select highlighting.

I dare you to try and select an attribute value that starts with a slash.

e.g. [sometag attributeName="/attributeValue"

Place your cursor (I-bar) just inside the double quote and drag to the right.

You end up selecting {="/attributeValue} how un-user friendly is that?! why would anyone want to select ="/text as a value.

Try selecting it backwards?.. nope! same bug!

Also when editing the HTML of a page in the developer toolbar I'm restricted to edit ONLY the innerHTML of the BODY tag.  If I want to fix something in the HEAD I'm out of luck.

Why the silly restriction?

[I'd love to add this comment to an on-topic post, but they get closed rather quickly, so I'm forced to simply ask at the newest post.]

Can the IE team explain why the .NET CLR details are cluttering up the user agent string? I can't figure out how the information is relevant in the web environment.

We've got user agent strings pushing past FOUR HUNDRED CHARACTERS in length.

If you are trying to communicate browser capabilities, THERE'S A HEADER FOR THAT: HTTP Accept.

The same goes for Media Center PC, InfoPath, OfficeLiveConnector, OfficeLivePatch, and MSN Optimized, and probably dozens of others.

You are filling up our logs, and congesting the tubes with what can only be considered SPAM.

Also: It's time to get rid of the "Mozilla/4.0 (compatible;" nonsense.

Just to illustrate:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)

*Seriously?*

And why is Mozilla/4.0 in there *twice*?

@Brianary - I agree! There is so much garbage stuffed in there that finding anything meaningful is almost impossible.

Mine is:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; InfoPath.2)

Now if I read this correctly I'm running MSIE 8.0.

no, wait, thats MSIE 6.0

no, wait, thats Windows NT 5.1

no, wait, Trident/4.0

no, wait, Mozilla/4.0

no, wait, InfoPath

no, wait, .Net CLR 1.1.4322

oh, silly me I should check the appName and appVersion... that would make it more clear.

.appName: "Microsoft Internet Explorer" - fine

.appVersion: "4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; InfoPath.2)" - yeah not so much on the helpful department.  The first number I get to is 4.0 which makes no sense at all in 2009.

oh wait, I'll use the proprietary window.clientInformation to get real simple details!...... not a chance.

Ugh!

@Brianary: We've talked in the past about how user-agent bloat is a problem, and specifically recommended that folks not spam the UA String, as described here:

http://blogs.msdn.com/ie/archive/2009/01/09/the-internet-explorer-8-user-agent-string-updated-edition.aspx

The case where you're seeing the "Mozilla/4.0" twice is a machine on which some tool or administrator thought they could emulate IE6 by putting the full IE6 UA string in the registry; this obviously doesn't work properly.

Your point that many Microsoft applications spam the UA is absolutely true, and it's the subject of ongoing conversations with the teams doing so. We have strongly suggested that teams refrain from doing this. The .NET team communicates felt it necessary to communicate version information so that websites could target proper versions of the CLR with WPF/ClickOnce content. We are working with them to find better ways for them to achieve their needs.

However, your suggestion that applications spam the Accept header is not an improvement, and Accept-spamming is source of similar problems as described here: http://blogs.msdn.com/ieinternals/archive/2009/07/01/IE-and-the-Accept-Header.aspx

@Marley The Developer Tools that came with IE8 allows you to edit the innerHTML and attributes of tags in the body and the head of the html. If you want more flexibility in your edit, use the Edit command and the sources will be available in text format to add, edit, or remove anything on the page. Click on the Edit command again to get out of the Edit mode and see the changes rendered in IE...

Some more info on the Edit command can be found here: http://msdn.microsoft.com/en-us/library/dd565627(VS.85).aspx#htmltool

Since the last time I brought this up, not only have things gotten no better, they've gotten *dramatically* worse!

The "Mozilla/4.0 (compatible;" needs to go, obviously.

Whether absolutely any string (such as a duplicate user agent string) should be allowed by any random toolbar or BHO is probably outside the scope of this forum, but at the very, very least someone within Microsoft should be asking whether Zune, OfficeLiveConnector, OfficeLivePatch, Media Center PC, MSN Optimized, etc. really need to bloat every single request, and whether it needs to be in the user agent header, which tends to be persisted to logfiles on disk. It sounds like you are trying to do that, and I hope you get some traction.

Until then, can you explain why my other posts were removed, particularly the one in which I proposed a protest against the bloated IE user agent string by including the three longest MSIE user agent strings from web server logs at the top of all comments and communications to Microsoft?

Brianary: if you don't wanna get modded, maybe you should avoid posting (basically) the same rant over and over again, and suggesting that others spam as well?

@Ian: "[ECMA-262] defines the ECMAscript scripting language". ECMAscript is a perfect implementation of the ECMA-262 specification - ECMAscript is NOT the standard, it's its 1-to-1 implementation: strictly speaking it is 'only' one of the implementations (the reference) of ECMA-262 (careful, in Standards language, subtitles usually are there to illustrate, but are not normative). If you feel that I abused this fact by using 'nickname', I apologize: I should have used "ECMA-262-compliant-language" all the time.

IE will NOT load script files and will NOT interprete ECMA-262 compliant code if said code isn't loaded with type="text/javascript" (or, alternatively, text/jscript); which, according to RFC4329 section 7 (2006), is obsolete. If you try loading scripts using a type of "application/ecmascript", IE fails by design: https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=338278

I did mention that I'd like DOM 2 events ON TOP of Javascript support; I also made the distinction that Javascript was created even before a standardized HTML DOM was considered. If you consider that ECMA-262 compliant languages can (and, in a browser, need to) operate with a document through that document's object model, then you'll understand that better Javascript support would work even better with better DOM support. But then, I'll spell it out for you: I'd like Javascript support AND better DOM compliance from IE. Clear enough?

And here I go again, writing more text in comment than there was in the OP. Geeze...

@cashvo - You obviously haven't used the Edit feature of the IE8 Developer tools or you would know that @Marley's comment is 100% accurate.

When you click on the Edit icon  (on the HTML Tab) (keyboard shortcut Alt+E) the resulting view shows you **ONLY** the contents of the BODY tag, all other elements are not displayed e.g. HTML, HEAD, TITLE, META, LINK, SCRIPT, STYLE etc.

This isn't exactly news! This was reported early on in the IE8 beta development cycles before IE8 went RTW.

Fred.

@Joe: So OK when Microsoft spams me over and over in my server logs, but not OK for me to suggest a reasonable protest. Gotcha.

Brianary: Suggesting that people annoy the IE team (who clearly have plenty on their plate) is simply immature and counter-productive.

Mitch: I notice that you're already changing your story, and now correctly note that IE loads scripts specified with the text/jscript type as well. I think you'll soon find that it accepts a few more... keep looking...

If you're going to critique someone, it's important to be factual.

@Joe: it accepts other types - but not for ECMA-262 compliant languages: the others are for VBscript, and there's one for XML (which, as a meta-language, will require you to provide your programming language description on top of your program - we're a bit out of webpage scripting here, don't you think?). Check again the address I provided (pointing to an MS bug report with complete summary).

'text/jscript' isn't recognized by Firefox; Opera and KHTML/Webkit-based browsers do parse and run it, though - they do include at least partial implementations of the IE DOM (using a specific type could be considered a form of browser detection, see). Still, Jscript isn't Javascript, and isn't Ecmascript: it's an ECMA-262 revision 3 compliant programming language.

So, to sum up:

- if the topic is still "is Jscript just like Javascript", then the answer is still no;

- is Javascript the name for the norm? No;

- is Ecmascript the norm or the reference implementation of a norm? It's a reference implementation of the ECMA-262 standard, and could be considered the necessary, compatible subset of all ECMA-262 compliant languages;

- can IE run Javascript? No, as Javascript is Netscape's superset implementation of an ECMA-262 compliant language, of which compatible implementations are used by all GUI-based, majority browsers but IE;

- Can IE run Ecmascript? Yes (if tailored to IE's DOM or W3C code DOM 1), as Ecmascript is a subset of Jscript;

- does IE recognize the 'application/ecmascript' type, which is the proper Ecmascript MIMEtype according to RFC4329? No, probably because types can be used as a form of browser detection, and IE not implementing the W3C HTML DOM like other browsers do and scripts relying heavily upon the DOM to run, accepting this type would be Bad(tm).

So, did I really change my tune compared to my first comment? I explained some of my (admittedly vague and open to misinterpretation) shortcuts; while IE does recognize MIME-types text/javascript and text/jscript, nobody (not even on MSDN) use the latter (which could be considered obsolete, too, as it is improper to use 'text' as a main type for a scripting language), and IE sure as heck doesn't recognize 'application/ecmascript' which is the proper, not obsolete type for Ecmascript, as reference implementation of ECMA-262, of which Jscript is supposed to be a superset, and for which it'd qualify.

Dang, I really did write more than the OP now.

@Joe: You're right. I shouldn't pick on the poor little mom-and-pop Microsoft. I mean, they are costing my company money, but surely we can withstand annoyance better than they.

It wasn't directed exclusively at the IE team, anyway. EricLaw made it clear that the whole organization is to blame for bloating the UA string.

Love the ad hominem attack, BTW. Very classy.

Re what to call ECMAScript...

some history from an interview with Brendan Eich:

InfoWorld: What’s the difference between ECMAScript and JavaScript, or are they one and the same?

Eich: ECMAScript is the standards name for the language. Its number is ECMA-262 and it’s a name that the standards body came up with because they couldn’t get anybody to donate a trademark that was agreeable to all parties. So there’s an issue with marketing the programming languages.

JavaScript would have been the ideal name because that’s what everyone called it and that’s what the books call it. Microsoft couldn’t get a license from Sun so they called their implementation JScript. So ECMA wanted to call it something and they couldn’t get anybody to donate or they couldn’t get everybody to agree to a donation of the trademark, so they ended up inventing ECMAScript, which sounds a little like a skin disease. Nobody really wants it.

And so you have this funny [situation] where you have a standard with a funny name or number and then various implementations that have trade names. And the trade names don’t have a huge value, except JavaScript is the common name. It’s in all the books, it’s what people say. It’s what people refer to on "Saturday Night Live."[Editor's note: JavaScript once merited mention during a skit on the show.]

source: http://www.infoworld.com/d/developer-world/javascript-creator-ponders-past-future-704

@Fred Thanks for pointing that out. You caught me :)

I checked into it and here is what I found out:

- Most of the functionality for the Developer Tools extends existing IE interfaces...

- The Edit mode is one example where it uses innerHTML (http://msdn.microsoft.com/en-us/library/ms533897(VS.85).aspx) to expose content of the body for editing

- This allows the content to be read and written quickly and easily. It comes with the limitation where it cannot edit the head...

- The IE team is aware of this limitation

So...I learn something new today....  ;-)

@CashVo - thanks for the confirmation! I too was starting to wonder if my IE8 dev tools were somehow broken when I didn't see other elements.

thanks also for the extended explanation it helps clarify why there is this limitation.

does this also mean that if in IE8 (the browser) I use javascript to set the .innerHTML of say the head element that it will fail? or doe this work fine, just not higher up on the html element?

thanks

@EricLaw: I've added a comment to your article arguing against the proper use of the Accept header. That seems a more on-topic forum for this discussion.

http://blogs.msdn.com/ieinternals/archive/2009/07/01/IE-and-the-Accept-Header.aspx#9853459

@Brianary Thanks for making an effort to "stay on topic" :)

@Jim - To answer your question, "Yes, because the head element is read-only". So is the html element. Otherwise, the Developer Tools would have used the innerHTML to grab the entire source from the html element for the Edit mode...but since it's a read only tag with this attribute, it cannot be updated...the body tag turns out to be the best candidate.

A list of "read-only" elements for innerHTML can be found here: http://msdn.microsoft.com/en-us/library/ms533897(VS.85).aspx

Hope that helps.

Odd - other browsers don't have any limitation of "read-only" tags.  Is IE going to fix these tags in the next release?

How to use developer tools with the WebCtrl ?

My application embedded IE 8 webCtrl and Web pages are not working in IE. I want to use all developer tools in this scenario

@ejor: Sorry, but the IE8 developer tools can only be used within IE8 itself. I believe that you can use VS or an external debugger to debug script in Web Browser controls in your application.

@Toman,

> Not showing the closing tag of elements is a really poor choice.

It makes finding issues very difficult because the visual tree does not represent the code specified by the developer, please add the closing tags back in.

Toman, I agree with you but there maybe 2 distinct difficulties here. In some cases, a closing tab is forbidden in HTML 4: eg the <col> element. In some cases, it is optional in HTML 4: <li>, <dt>, etc. and displaying the end tags may confuse the web author.

In some cases, the IE dev. tools is just having a bug (most likely related to DOM tree construction of the rendering engine).

a) Eg: <col></col/>

as explained in a comment in bug 409478:

www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug215

b) Eg: <p> element do not close before a non-inline element:

www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug74

www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/Unclosed-P-Preceding-Form.html

> properties should be listed in alphabetical order.

I fully agree with you on this. All debugging tools (not just Microsoft) should do that. All web authoring softwares should output CSS code according to lexico-graphical/alphabetical order of property names so that code can be much more consistent (source code would be easier to review, maintain, figure out, etc) for all interested+involved parties.

Shorthand form should also comply with such order:

border-color, border-style and then border-width. Alphabetical order is generally well understood, known and would be easy to remember, to apply, to comply with, etc.

@ Mitch 74

Please visit, validate and vote for bug 338278 if you haven't done so already.

regards, Gérard

@Toman,

> Not showing the closing tag of elements is a really poor choice.

It makes finding issues very difficult because the visual tree does not represent the code specified by the developer, please add the closing tags back in.

Toman, I agree with you but there maybe 2 distinct difficulties here. In some cases, a closing tab is forbidden in HTML 4: eg the <col> element. In some cases, it is optional in HTML 4: <li>, <dt>, etc. and displaying the end tags may confuse the web author.

In some cases, the IE dev. tools is just having a bug (most likely related to DOM tree construction of the rendering engine).

a) Eg: <col></col/>

as explained in a comment in bug 409478:

www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug215

b) Eg: <p> element do not close before a non-inline element:

www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug74

www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/Unclosed-P-Preceding-Form.html

> properties should be listed in alphabetical order.

I fully agree with you on this. All debugging tools (not just Microsoft) should do that. All web authoring softwares should output CSS code according to lexico-graphical/alphabetical order of property names so that code can be much more consistent (source code would be easier to review, maintain, figure out, etc) for all interested+involved parties.

Shorthand form should also comply with such order:

border-color, border-style and then border-width. Alphabetical order is generally well understood, known and would be easy to remember, to apply, to comply with, etc.

@ Mitch 74

Please visit, validate and vote for bug 338278 if you haven't done so already.

regards, Gérard