If I were a SharePoint psychiatrist, (which indeed I may very well be...) I would have a list of panaceas tantamount to what a therapist might actually tell a real patient. For example:
To a patient:
To a SharePoint developer:
The reason SharePoint is sometimes seen as a hostile environment to work with is because a lot of things just don't work, or perhaps more accurately, don't work the way you'd expect them to. But people quickly forget that the nature of this beast is two-sided; the things that cause certain functionality to not work are in turn making many other things trivial to implement.
It's a trade-off, like everything is.
First, the problem: I redid our company's time sheet system as a SharePoint solution. The front-end is an AJAX-y animating user control hosted as a SmartPart. The back end is all Linq to SQL. The workflow is handled by WF. Everything lives in SharePoint, and future releases will have Quick Books integration.
Notice the use of document.documentElmenet in lines 9 and 10. This is what you use to get the number of pixels the page is scrolled in either direction in IE7. Since this is an internal app, I know that all my users will be using IE7, so no cross-browser consideration was necessary.
However, it didn't work; both values just returned 0. I tried my user control on a normal page (not SharePoint) and it behaved just fine. "Oh well," I thought. "It's an internal app; they can just scroll to work around it." Yep: I was about to write this off as something that just didn't quite work in SharePoint.
But that just didn't sit right with me. There has to be a reason why!
So after frolicking around the server for a while, I stumbled onto the default master page (default.master in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\GLOBAL). Always intrigued by SharePoint-inized HTML, I opened it up. The first thing I noticed is what led me to the answer: there was no DocType at the top of the file! I immediately opened up a page in the portal (thinking that the DocType line might be generated on-the-fly or something), did a "View Source" and indeed, no DocType!
So I went back to the master page, and copy-and-pasted in a DocType from whatever Visual Studio generates for a new ASPX page. Next I tried the page again, and guess what? The draggable div now worked in SharePoint when the page was scrolled! However, using a DocType (I tried several different versions and DTD's) CRUSHED the formatting of the page. The colors, gradients, and images were all screwy in IE7.
So what does this mean? Well that SharePoint's HTML is not really confirming to any DocType standards. To me, this seemed very IE6-ish, so, referring to the code above, I switched my "document.documentElement" calls to use to older "document.body" that works in IE6. And guess what? That did the trick for SharePoint in IE7!