(X)HTML and CSS have their own validators, but we need one for Javascript as well. JSLint could be part of it, but what I’m imagining would flag the use of “native” objects/interfaces not defined by W3C or ECMA standards. E.g., document.layers or window.ActiveXObject.

The hard part in doing this is finding a full Javascript interpreter with W3C DOM interfaces, but without the proprietary features that browsers have to support to remain usable on the web. A couple ways come to mind:

1. Rhino

John Resig has just implemented “window” for the Javascript interpreter Rhino, which, supposedly, is already based strictly on the ECMAscript standards. The short term goal of his script was to give Rhino enough of a browser interface to pass jQuery’s test suite, but the code could be branched to implement all current W3C DOM recommendations (and none of the proprietary interfaces). A Java app would set up Rhino, run John’s script, then run your script and simply report any errors.

2. A stricter browser

Most modern browsers are pretty malleable as far as letting user code clobber native functions/objects; in fact it’s a real problem. But this is convenient if you want to, say, overwrite all the proprietary features with your own code! With a whitelist in hand, you could use for-in loops to sniff out non-standard functions/properties and either delete or overwrite them with functions of your choice.

The advantage of the browser solution is that you could still provide the non-standard features (so the script would continue to run) while logging them. Using closures you could, in theory, “wrap” each non-standard function so that each of its calls would also call your logging function before returning the expected value. A crude example:

// may fail spectacularly
var _parseInt = window.parseInt;
window.parseInt = function (str) {
    alert('parseInt was called.');
    return _parseInt(str);
};
parseInt('2');

In practice, you’ll be at the mercy of the browser to allow native functions to be stored in variables like this. Sometimes it works, sometimes not. As for properties, you may be able to similarly log their usage with Javascript’s relatively new getters and setters.

So any idea where to get such a whitelist?

A problem a decade in the making

You can refer to a form’s elements in your code by using the element’s name (from the NAME attribute)
— an ancient Javascript spec.

This means myForm.myElement is a shortcut for myForm.elements['myElement']. I’m sure this was seen as handy and harmless at the time, but the problem is that references to form elements, simply by using valid name attributes, can overwrite important DOM properties and methods on the form element. Make a text input with name=”submit” and you overwrite the form’s native submit method; no more form submission!

Workaround

Effectively, you have to avoid using names that already exist as properties or methods of the form DOM element, from modern specs back to the stone age. To get an idea of how many there are, I created an empty form element with no attributes, fired up the Javascript shell bookmarklet and used its handy props function:

Methods: addEventListener, addRepetitionBlock, addRepetitionBlockByIndex, appendChild, attachEvent, blur, checkValidity, cloneNode, contains, detachEvent, dispatchEvent, dispatchFormChange, dispatchFormInput, focus, getAttribute, getAttributeNS, getAttributeNode, getAttributeNodeNS, getElementsByTagName, getElementsByTagNameNS, getFeature, hasAttribute, hasAttributeNS, hasAttributes, hasChildNodes, insertAdjacentElement, insertAdjacentHTML, insertAdjacentText, insertBefore, isDefaultNamespace, isSupported, item, lookupNamespaceURI, lookupPrefix, moveRepetitionBlock, namedItem, normalize, removeAttribute, removeAttributeNS, removeAttributeNode, removeChild, removeEventListener, removeNode, removeRepetitionBlock, replaceChild, reset, resetFromData, scrollIntoView, selectNodes, selectSingleNode, setAttribute, setAttributeNS, setAttributeNode, setAttributeNodeNS, submit, toString

Fields: accept, acceptCharset, action, all, attributes, childNodes, children, className, clientHeight, clientLeft, clientTop, clientWidth, contentEditable, currentStyle, data, dir, document, elements, encoding, enctype, firstChild, id, innerHTML, innerText, isContentEditable, lang, lastChild, length, localName, method, name, namespaceURI, nextSibling, nodeName, nodeType, nodeValue, offsetHeight, offsetLeft, offsetParent, offsetTop, offsetWidth, onblur, onclick, ondblclick, onfocus, onkeydown, onkeypress, onkeyup, onload, onmousedown, onmousemove, onmouseout, onmouseover, onmouseup, onunload, outerHTML, outerText, ownerDocument, parentElement, parentNode, prefix, previousSibling, repeatMax, repeatMin, repeatStart, repetitionBlocks, repetitionIndex, repetitionTemplate, repetitionType, replace, scrollHeight, scrollLeft, scrollTop, scrollWidth, sourceIndex, style, tagName, target, templateElements, text, textContent, title, unselectable

These are just in Opera; to be really safe you need to add in any extras from all the other modern browsers.

But there’s more

This problem also exists on the document object: Give your form name="getElementById", then try using document.getElementById(). Even worse, IE/win registers all element ids onto the global (window) object.

The real solution

The W3C/WhatWG needs to step up and formally denounce these shortcuts in the HTML DOM specs, and, IMO, also generate warnings in the HTML validator where input names match those in W3C DOM specs, at the very least. Since there’s a sea of legacy code out there using these shortcuts, browser makers desperately need a defined way to handle these collisions.