Develop Reference

Javascript broken after moving from IE8 to IE11: "Object doesn't support property or method 'all' "

I was just forced into a browser upgrade (IE8 to IE11) while in the middle of testing. I've lost some essential functionality with some javascript that suddenly doesn't work in my .NET site.
This section of the code was written when I was in grade school, so I'm not extremely familiar with it, but what seems to be the problem is a call to form.all. I have to assume that call was built into javascript at some point - there's no definition for it in the code.
There are 7 "if statements" that use form.all and they are all written the same way:
if(form.all(cTag + "PersonNum") != null)
form.all(cTag + "PersonNum").value = personNumber;
The error:
JavaScript runtime error: Object doesn't support property or method 'all'
In newer versions of JavaScript, is there a version of form.all that performs the same action? All I really need is for someone to point me in the right direction.
A weird note: the same JavaScript code IS working in production on IE11
EDIT Ok, I found a line that was minimized. It looks like form is a created variable.
var form = document.forms(0);
EDIT2 Compatibility view/mode was the solution after all. I had added our production site's domain to the compatibility list and didn't think about it; adding 'localhost' fixed the issue. You just have to set it to the right domain first for it to work :)

Check the browser compatability mode when your running in production it's probally on IE8.
You can use obj.getElementsByTagName("*")
You could also add an All method to the prototype if it's not there.

IE introduced an all property for certain DOM objects (e.g. document) but it was never part of any W3C standard. It allowed access to DOM objects by name or ID using:
var element = document(elementNameOrID);
or
var element = document[elementNameOrID];
that is, it is a property that could use the same syntax as a method. Neat. Some other browsers supported it for compatibility, but it pretty much went out of use with IE 6 (not sure when IE started supporting getElementById, I think it was IE 5). But IE continued to think name and ID attributes were the same thing until IE 8 in standards mode.
Support for all has been dropped from IE 11 in standards mode.
If form is a reference to a form element, and cTag + "PersonNum" is the name of a form control, then the simplest fix is to change:
form.all(cTag + "PersonNum").value
to
form[cTag + "PersonNum"].value
which takes advantage of named form controls being made properties of the form that contains them. This behaviour is standardised and supported by browsers from the very beginning (i.e. every where) and is future proof (it's not going to change).

Using type="text/plain" for JavaScript?

I was looking at setting this up, simply out of curiosity, however I was a little bemused when they stated for this to work you need to:
Find any Javascript elements that set Analytics cookies. Examples might include Google Analytics and StatCounter.
Modify the script tag so that the type attribute is "text/plain" rather than "text/javascript"
Would this cause any problems with certain web browsers? Would it cause the HTML to no longer validate?
Also, does the "type" attribute even really serve a purpose anymore? I've only ever seen it assigned "text/JavaScript" before?

It does not cause problems, if the intent is that browsers do not interpret the content of the element as script code but just as text data that is not rendered. It’s there for scripts to use it, but otherwise it’s ignored. Well, in some browsers, the content might be made visible using CSS, but by default it’s not shown.
Using <script type="text/plain"> is valid by HTML specs. Even <script type="Hello world ☺"> is valid, though it violates the prose requirement that the attribute value be a MIME type. The specs do not specify its meaning, but the only feasible interpretation, and what browsers do in practice, is that it is not in any scripting language and no execution as script is attempted.
So type="text/plain" may be used to intentionally prevent execution of a script, while still keeping it in the source. It may also be used to carry bulks of character data used for some processing.
The type attribute may serve purposes like this, and it can also be used to specify scripting languages other than JavaScript (rarely used, but still possible in some environments). Using the type attribute just to specify JavaScript is not needed, and cannot be recommended: the only thing that you might achieve is errors: if you mistype, e.g. type="text/javascirpt", the content will be regarded as being in an unknown language, hence ignored.

Would this cause any problems with certain web browsers?
No
Would it cause the HTML to no longer validate?
No
Also, does the "type" attribute even really server a purpose anymore?
Browsers use it to decide what interpretor to run code through (or if they should download externally srced code at all).
Setting it to text/plain sets it to a type that browsers won't have interpretors for (since it isn't a programming language), which is the point.

Giving JS code the text/plain type is perfectly ok and will effectively disable it. To enable the script after the page was loaded you will need to have JS code to rewrite the type to text/javascript on the fly. Cookie blocking is a common example. Insert a cookie-setting script with text/plain and change to text/javascript when the user gives cookie consent. This will execute the script immediately, on the current page, no need to reload it.

"application/javascript" is what it must be, according to the latest w3 specifications. But as expected, most of the older versions of IE does not support this. So it is safe to use "text/javascript" everywhere.

can we use AJAX with XHTML?

Can we use AJAX for updating a XHTML page?
To connect the html page, we used to write:
xhr.onreadystatechange = function(){
if(xhr.readyState == 4){
document.getElementById("target").innerHTML=xhr.responseText;
}
}
However, we can't change innerHTML to innerXHTML, because AJAX doesn't accept it.

Yes, you can update XHTML pages using ajax. You still use innerHTML (or the DOM methods). The description of innerHTML in the HTML5 spec describes how XML vs. HTML should be treated.
Re the various DOM methods, some reading/reference material:
DOM2 Core
DOM2 HTML (which applies to XHTML documents as well)
DOM3 Core
HTML5 Web Application APIs

My first thought was "of course!". As T.J. Crowder points out, standards-compliant browsers which follow the spec should have no problem.
However, there does seem to be talk of some issues using innerHTML and maintaining well-formed XHTML markup in older versions of IE.
Keep in mind that this is old information. It may no longer be a problem.
http://www.stainlessvision.com/jquery-html-vs-innerxhtml (which uses innerHTML)
http://www.stevetucker.co.uk/page-innerxhtml.php
My experience has been to the contrary, i.e. using innerHTML to insert markup is not a problem.
The AJAX piece is really irrelevant here; the question is whether or not innerHTML can be trusted to preserve the integrity of the markup being inserted into the document.

My site linked in my profile is served entirely as XHTML served as actual XHTML, application/xhtml+xml. Clicking on 'Site Options' at the top-right will in example load content via AJAX.
Code is not text, do not use responseText, use responseXML.
Never EVER use innerHTML, it's a proprietary Microsoft JScript method that is not compatible with the DOM. Using it adds huge swathes of ambiguity to your code, JavaScript may see elements you've loaded via AJAX but probably won't.
Use importNode as I have, these are two different document owners and you have to use importNode to load content from different documents.

HTML data attribute IE6 support

Does HTML's data attribute work in IE6?
I'm using the attribute like this <img id="charm_1" data-code='sdfsdfsdfsdf' data-price='100' class='addition_image' src="img/misc/donut.png" width="55" height="55" alt="Donut">.
As you can see there are 2 data attributes (price and code). I can get this with jQuery using the .data() method and it all seems to work in IE7/8/9. Does this work in IE6? I don't have a copy of IE6 to test this.

IE6 -- and indeed all other browsers on the market -- have always been perfectly happy for you to define your own custom attributes on an element.
The use of data- as a prefix was formalised in the HTML5 standard, but browsers have always supported it, and don't even really require the data- prefix.
The data- prefix is recommended because it is now part of the standard, so there's a chance that a future browser may be more picky about it, and also because of the new dataset property that was added to HTML5 DOM specification at the same time to support it.
Obviously you can't use the dataset property, as very few browsers support it (not even newer ones, let alone older ones), but you can of course always use the good old getAttribute() method instead (which is what jQuery does).
To find out about browser support for new properties, I recommend the CanIUse.com site. For example, here is their page about data- attributes: http://caniuse.com/#search=dataset. They have full browser support tables for a wide range of features.
Hope that helps.

You can use IETester in order to test your websites on the different versions of IE and yes it those work on IE6 , IE has supported getAttribute() from IE4 which is what jQuery uses internally for data().

Will non-IE browsers use script inside a tag with type="text/jscript"?

I inherited an ancient codebase that includes pages with <script type="text/jscript"> -- yes, my life really does suck that much. The script appears to do nothing in modern, decent browsers (FF and Chrome, for a start) and I'm wondering if the stated script type is causing it to be ignored. I spent some time trying to figure out what's going on, and I see things like
As explained by JavaScript guru Douglas Crockford in his talk entitled The JavaScript Programming Language on YUI Theater, "[Microsoft] did not want to deal with Sun about the trademark issue, and so they called their implementation JScript. A lot of people think that JScript and JavaScript are different but similar languages. That's not the case. They are just different names for the same language, and the reason the names are different was to get around trademark issues."
on Wikipedia. So Javascript == JScript? But then, I see conflicting information, like this answer which seems to suggest that script that's declared as JScript will only run in IE.
So: can I just change the type tag and everything will work fine? Is there a simple process for conversion? If not, I may just scrap the whole thing and start over.

From HTML 5 chapter 4.3
7) If the user agent does not support the scripting language given by the script block's type for this script element, then the user agent must abort these steps at this point. The script is not executed.
That same chapter also says
If either:
the script element has a type attribute and its value is the empty string, or
the script element has no type attribute but it has a language attribute and that attribute's value is the empty string, or
the script element has neither a type attribute nor a language attribute, then
...let the script block's type for this script element be "text/javascript".
so I would just remove type="text/jscript" save a bit on bandwidth and live happily ever after.

So Javascript == JScript?
JScript is what Microsoft calls JavaScript
But then, I see conflicting information, like this answer which seems to suggest that script that's declared as JScript will only run in IE.
That doesn't conflict. It just means that other browsers don't recognise the mime type.
Browsers will ignore script elements with a type they do not recognise. text/jscript is non-standard and most browsers don't recognise it (Internet Explorer considers it an alias for text/javascript).
can I just change the type tag and everything will work fine?
Probably. The script might depend on other proprietary Microsoft—isms (such as document.all) or other non-standard behaviour (automatic id attribute to JS global conversion or treating CSS lengths that are missing a unit as pixels) though.

The other answer you linked to is completely incorrect. There are no differences between JScript and JavaScript. Changing the script type to "text/javascript" should work (unless the intent of the author was to force it so that only IE ran the script)

the type= requirements have been taken out of html5. I believe the proper xhtml code would be ...
<script type="text/javascript">
<![CDATA[
// content of your Javascript goes here
]]>
</script>
... but browsers did not follow the requirements of xhtml of forcing an error. Most web hosts keep the delivery of xhtml and html docs as MIME-type "text/html", not the "application/xhtml+xml" which should force an error if the xhtml does not validate.
HTML4 uses are variety of types ... http://www.w3.org/TR/html4/interact/scripts.html ... but browsers do not force html4 validation.
vscript, tcl don't have common support - we are talking about Javascript or any of the other names it gets as in becomes a more powerful language.

A bogus "type" attribute will definitely make scripts not work. The browser thinks you don't want it to run the script, basically.
Really, the "type" attribute is not necessary unless you definitely don't want the browser to run a script (which people do when their "scripts" are actually template bodies, or other data like that). You could either change all yours to "text/javascript" or just get rid of the attribute entirely.