The DOCTYPE tag and SharePoint Master Pages

I came across a new issue this week.  All of my custom master pages that I have done (including the base code I provide here) include a DOCTYPE tag that references the latest HTML specifications (<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>).  Unfortunately, the master page file used by default for SharePoint (default.master) does not specify a DOCTYPE tag at all.   So when the browser page renders the code, it reverts to quirks mode, which renders the HTML according to old rules.

This has a cascade effect. The default SharePoint styles have been coded to style old HTML specifications, instead of the new ones.  This means deprecated styles elements are used since old HTML rules are being applied to the page.  Most notably, the HEIGHT attribute for table cells is used in the SharePoint styles, and this is a deprecated property in HTML 4.0.

So far I have only found a small handful of issues where this becomes a problem if you are specifying a correct DOCTYPE tag. There are a few styles used in the Calendar display that rely on the HEIGHT attribute to set table cell heights.  Click here to see these issues. For the second issue listed, I have a fix.

As a web designer, I am not willing to revert to using quirks mode for rendering the pages.  It is not the appropriate solution IMHO.  Current DOCTYPE tags should be specified for pages. Instead I plan (or will try :-P) to create a new Events feature that styles the calendar differently to correct this issue created by the lack of a  DOCTYPE tag in the default code for SharePoint.

So this serves as a heads up warning to anyone creating master pages, or using my base master page code.

20 thoughts on “The DOCTYPE tag and SharePoint Master Pages”

  1. Hallo Heather,Have you looked at your Master Page after applying the changes using IE6 or IE7? IE6 doesn’t like the transitional DTD and it’s falling directly into the quirks mode as soon as it’s recognize it – just as you mentioned. On the other hand if you use the Strict DTD and your HTML is valid, you will avoid quite a few CSS bugs – even in IE6. I’m curious what steps have you already tried…

  2. BlueBand.Master also includes the DOCTYPE HTML 4.01 specification, so it’s real easy to spot a couple additional bugs. 1) The “New” dropdown button on list toolbars doesn’t span the full height of the toolbar. (Go to any list and hover over “New”)2) List item dropdown menus grow in height by about 2 pixels when you hover over them. Wouldn’t be a big deal, except that shifts all the other list items down and back up as you roll over the list items – very unsettling. (Go to a list with multiple items and hover over the first few.)Neither of these problems manifest themselves when the DOCTYPE definition is removed from BlueBand.Master… but of course others do. 🙂

  3. Hi Heather, I wish I’d found this a couple of days ago … would have saved me some work :)I’ve created my own minimal master page and started styling it up. I’m finding another problem when including the doctype on my master pages. The cause of which is not entirely clear to me.In Firefox 2.0 (and I’m assuming Mozilla based browsers in general) I am finding that the Javascript menus are not working correctly. For example, click on the Site Actions button and the pop up menu no longer appears beneath it but instead is about 100px higher up the page. The pop up menus also have scroll bars in some cases. The same occurs with the menus on the publishing tool bar (eg: the Page, Workflow and Tools menus).Take the doctype out and they all work fine in FF. This appears to be doing the same with your master page.

  4. Hi,I’m trying to use Ajax on SPS. Without a DOCTYPE tag, the Colpasible Panel extender doesn’t work. With the 1.0 Transitional DOCTYPE, the AJAX stuff works – but sharepoints tables etc. fall over!Can anyone suggest a fix for this?Regards

  5. don’t know if anyone else has experienced this, but adding a doctype and using the command “edit in datasheet” from a list menu will cause IE to hang/crash.

  6. The problem i encountered is that document.body applies when the DOCTYPE is not set and document.documentElement applies when the DOCTYPE is set. I had to change the following function MSOLayout_GetRealOffset(StartingObject,OffsetType, EndParent){ var realValue=0; if(!EndParent) EndParent=document.body; for (var currentObject=StartingObject; currentObject !=EndParent && currentObject !=document.body; currentObject=currentObject.offsetParent) { realValue+=eval(‘currentObject.offset’+OffsetType) } return realValue;}To the following function MSOLayout_GetRealOffset(StartingObject,OffsetType, EndParent){ var realValue=0; if(!EndParent) EndParent=document.body; for (var currentObject=StartingObject; currentObject !=EndParent && currentObject !=document.documentElement; currentObject=currentObject.offsetParent) { realValue+=eval(‘currentObject.offset’+OffsetType) } return realValue;}Will post more on my blog

  7. I have the same problem as Evan: adding a DOCTYPE to my custom master page causes the “edit in datasheet” action to crash IE. Does anyone know of a resolution? Thanks for any help.

  8. Yes edit in Datasheet view breaks and so does export to excel. This is a pretty serious issue. There is rumor of a hotfix for this issue in February. I will let you know if I hear anything else.Dave

  9. http://www.heathersolomon.com/blog/archive/2005/08/25/1720.aspxI spent a brief time on the DOCTYPE design wagon… the craze that swept through some time ago where if your web site design didn’t included DOCTYPEs you were waving a giant “old fart from the dark ages” flag. Everything shifted to this huge push for DOCTYPE design where you accomplished all layouts with just standard compliant HTML. I jumped on the bandwagon, I rode the rough trail, and I got off at the next stop. To me the exclusiveness of using a DOCTYPE is insane. In some instances you can spend 4 times the time trying to get a page to look and flow correctly with standards compliant HTML only than you can if you just used quirks mode. I am not saying placing quirks all over the page and quirks within squirks within plurps is the way to go, but a quirk here and there doesn’t hurt anything.Some diehards say quirks mode should only be used for data display and never for layout. Hoorah you are right, they are for data display. But they work pretty nifty for web design too, and why not? In today’s world time is money and quite frankly the client doesn’t give care if you mastered their web site design using standards compliant HTML only. I believe in a nice marriage of the two. Do what you can with standards compliant HTML and use quirks mode where useful and appropriate. They are both great tools and provide ways to do just about whatever you need to do design wise.

  10. I spent a brief time on the DOCTYPE design wagon… the craze that swept through some time ago where if your web site design didn’t included DOCTYPEs you were waving a giant “old fart from the dark ages” flag. Everything shifted to this huge push for DOCTYPE design where you accomplished all layouts with just standard compliant HTML. I jumped on the bandwagon, I rode the rough trail, and I got off at the next stop. To me the exclusiveness of using a DOCTYPE is insane. In some instances you can spend 4 times the time trying to get a page to look and flow correctly with standards compliant HTML only than you can if you just used quirks mode. I am not saying placing quirks all over the page and quirks within squirks within plurps is the way to go, but a quirk here and there doesn’t hurt anything.Some diehards say quirks mode should only be used for data display and never for layout. Hoorah you are right, they are for data display. But they work pretty nifty for web design too, and why not? In today’s world time is money and quite frankly the client doesn’t give care if you mastered their web site design using standards compliant HTML only. I believe in a nice marriage of the two. Do what you can with standards compliant HTML and use quirks mode where useful and appropriate. They are both great tools and provide ways to do just about whatever you need to do design wise.

  11. My team and I ran into the same problem as Evan and Stefanie: adding a DOCTYPE to my custom master page causes the “edit in datasheet” action to hang/crash IE. Initially, I created the custom master page by using one of Heather’s base master pages (thank you VERY much Heather, it was a great help), so I had all of the placeholders that I thought were unnecessary in a hidden panel at the end of the form.One solution that I found to our problem was to take the ‘PlaceHolderBodyAreaClass’ placeholder and put it back to its original spot found in the default master page – after the end form tag (</form>). By doing this, the “edit in data sheet” functionality worked again, and we didn’t have to remove the DOCTYPE tag so all of our styles still worked!Only thing is… I haven’t quite figured out what it is about this placeholder that causes the “edit in data sheet” functionality to work. But when I do figure it out, I’ll be sure to let you know:)

  12. Battling against this problem myself at the moment… Found that the browser doesn’t crash when adding a DOCTYPE to the default.master, so I gather it’s a combination of factors causing the browser to hang.I hate Sharepoint 🙁

  13. I am also having the similar problem. I have acustom master page applied to the site with DOCTYPE defined in it. I am trying to view document library’s datasheet view. The IE is getting hanged again and again. If I remove the DOCTYPE statement from my masterpage, it works fine but the whole page is not rendered properly. As the formatting depends upon DOCTYPE definition. I will appriciate if anyone can suggest me workaround for this problem.Thanks

  14. This has been driving me crazy. It’s all well and good to go back to quirks mode for design (I’ve been doing it for years), but you might as well forget using the ASP.NET 2.0 AJAX Toolkit – neither the collapsible panel nor the modal popup dialog will work without DOCTYPE. But placing DOCTYPE in a SharePoint master page breaks drag-and-drop functionality while editing a web part page (at least in IE7).I really wish that Microsoft would issue a fix for this.

  15. I am having a problem whereby the DOCTYPE is not in the master page and the ModalPopupExtender is not centered because of it. When I add the DOCTYPE HTML 4.01 to it, the page looks messed up. By addeding XHTML 1.0, compile error show in Sharepoint Designer.

  16. If it’s possible, then I suggest incorporating your standards conforming doctype’d html code via an object or iframe in the quirks mode pages.

  17. I found the solution to this issue on another website. There’s an bug in core.js which causes an infinite loop. http://tomblog.insomniacminds.com/2008/07/23/sharepoint-branding-issues-edit-in-datasheet-view/This is the bug:var lGCWindowHeight=document.documentElement.scrollHeight;Changing it to this fixes the issue:var lGCWindowHeight=(document.documentElement.scrollHeight>document.documentElement.clientHeight) ? document.documentElement.clientHeight : document.documentElement.scrollHeight;As suggested by one of the commenters, I’ve added a whole new copy of the affected function to our own JavaScript file. Our JavaScript file is referenced in our master page after core.js, so the redefined function overrides the buggy Microsoft one. It’s fixed the bug with no need to modify Microsoft’s files.

Comments are closed.