Anecdote on client-script compatibility issues

We're gathering real-world feedback relating to compatibility with .net 2.0 with compat devlabs, with folks coming over to Redmond, and now with people from the team going out to customer sites as well.

One trip report I saw caught my eye: 4 out of 5 customers had their asp.net v1.x apps broken with script errors when they transitioned to asp.net v2.0. Not a good statistic. The primary issue with each of these apps was their client scripts referencing the form element via document._formName_ resulted in script errors. Turns out in v1 we rendered the name attribute in addition to the id attribute on the <form> tag, which allowed this script to work. The name attribute happens to be illegal in XHTML1.1 strict and so we render just the id attribute in v2 in this mode. With the new rendering, the correct script needed to access the form element is document.forms['_formID']. The workaround was to turn off XHTML1.1 rendering, or obviously require the app to be updated with new script. Both are sort of sucky.

At that point, I wondered if we could actually do some magic with script, and proposed we output the following:

    <script>
    document._formName_ = document.forms['_formID'];
    </script>

Apparently this worked! So we could output this in our XHTML1.1 rendering, and allow a number of scripts to continue running without changes.

As you try out beta 2, do report any compatibility issues you run into. We'd love to hear about them, and make sure those issues are addressed appropriately, whether its with creative solutions, code changes, adding compatibility switches, or at the very least, documenting them.

A couple of side notes on this solution that I thought were interesting to me personally...

1. First, basically the workaround works by introducing a new expando property on the document object that would have otherwise existed by virtue of the name attribute on the <form> tag. Basically, this is capitalizing on the hacky nature of HTML and script, in this case, specifically the error-inducing-auto-expando-creation-on-typo behavior (as I like to call it - I've personally cursed on multiple occasions in the past when writing script and spent hours trying to debug why something wasn't quite working the way it should). I find it especially ironic capitalizing on this same behavior to come up with a solution. I guess that comes with the platform that is DHTML...
2. Apparently injecting this script automatically for XHTML1.1, breaks the WCAG accessibility guidelines, which flag any script occurrence as an error. One of our PMs was quick to point that out. This is one of the most bizzare guidelines I've ever seen - in my opinion something that looks at all script generically and flags it as invalid only points to a badly designed guideline with an equally incomplete verification story and tools (to put it mildly). I've ranted on the subject several times in our internal discussions, as well as in a previous post. Anyway, we're probably going to have to do some additional thinking on this particular compat-issue: Should we not default to XHTML1.1 strict? Should we have a way to switch between XHTML flavors? Should we have yet another switch for whether or not to output the name attribute or this workaround script? etc. etc. Any thoughts?