DOCTYPE

Harkernator

Hi,

I'm having trouble using Ajax in WSS 3.0.

My collapsible panel control doesn't work. A bit of digging around told me that I need to set the DOCTYPE on the Master Page.

It needs to be:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

However, when I set this, because Sharepoint uses lots of depreciated attributes/tags, all of the formats fall over and it looks a RIGHT mess.

I was wondering if anyone new an easy way round this

Perhaps there is a way of using something like the DOCTYPE tags around just one section of code

I'm desperate for an answer to this one!!

Regards

Andy-H

When I attempted to add a doctype to my master page for a publishing site I hit a problem in FireFox with the system javascript menus not behaving correctly (things like Site Actions). You could end up sifting through a mind field of issues to resolve as you've seen from your layout problems.

The doctype must come first and its definition is global to the page, you can't hack it to be applied to a section of a page as far as I know.

There is also a setting in the web config to force web parts to render XHTML compliant code which may help improve things, although in reality you can't guarantee what html will come out of a web part. Other than that, you could try correcting some problems by creating your own master page, CSS and page layouts.

Harkernator

I really don't want to slap the whole master page into compliancy - as even after doing this every time a new page is created, it's custom content in the placeholders will have non compliant code.

Also we don't want to edit it too far from the default for the sake of maintainability. This is the reason for using Ajax - managed code meaning that many resources on the internet should we need to tweak it down the line.

Also - the code in the WebParts aren't XHTML compliant so giving them HTML doctypes will fry the lot.

But it may prove to be better than nothing. Do you know what the web.config attribute is so that I can set it correctly

Regards

Andy-H

Yes, this page has the change you need to make and also loads of info on XHTML compliance, but it is easy to get carried away trying to change the behaviour to comply (btw - the change is for controls, not web parts as I said above).

I reached a suitable compromise with my solution, which involved creating a master page, new stylesheet and a selection of page layouts. While I don't have control of the user controls and web parts, my web pages render exactly as I need them and I have more control over the look and feel. It's not a quick five minute job though, but the efforts can be worth it in the long run. Should you decide to go that route, search out information on the minimal master page. In particular there is a lot of information you'd find useful on Heather's blogs.

Hope that helps.

Harkernator

Thanks I'll try that.

I've just discovered something called XHTML Basic:

http://www.w3.org/TR/xhtml-basic/

Does anyone know what <!DOCTYPE> tag I need to use this

I'm wondering if this might do the trick.

What would be fab would be if there was a DTD somewhere that included the depreciated tags and added the new stuff!

Regards

Andy-H

Basic is just a normal doctype, there's a list of them here (and examples of how to declare them). To be honest I would have expected that a transitional would be the most flexible for depreciated elements so perhaps finding one of the older DTD's is the answer like you say.

However by adding a doctype, you are forcing IE (and some other browsers) to render to that specification. As there is no doctype by default (at present) in the SharePoint master page, IE is using quirks mode where other issues (such as the way it treats the box model) are handled differently. By adding any valid doctype, no matter which one, your layout may change as you've experienced because of the differences between quirks and standards mode.

Perhaps you can find the best fit with least impact, good luck.

Harkernator

Firefox renders everything perfectly.

Shame there is no "XHTML1.0-IE-that-works-like-a-real-app-like-firefox" DTD!

Regards

Harkernator

NB - firefox is perfect with NO DOCTYPE. The DOCTYPE tag breaks firefox too.

Regards

rknewbow

We are having the same issue, have you come up with a good solution yet that doesn't involve creating a new master page or dramatically changing the existing one

Thanks,

Ryan

Harkernator

In a word. No.

The problem doesn't stop at the master pages either.

The Custom Content Regions on the pages themselves have none compliant code in too. Therefore you've got to modify them too.

Think it's finished No,

When you create new pages (ie a new view or a list), it will generate non-compliant code. Therefore you've got to rewrite what it uses as templates for the new pages too.

Now you're done. Wasn't that easy boys and girls

Having typed the above, I'm pondering something.

If two CSS pages are attached to one page, and have the same classes defined inside - will they be erroneous or would they be merged together somehow

rknewbow

Harkernator wrote:

If two CSS pages are attached to one page, and have the same classes defined inside - will they be erroneous or would they be merged together somehow

The classes would be merged when an attribute exists in one class but not the other, but when there are conflicting attributes it appears the last .css file loaded wins.

Example:

CSS1 (Loaded first)

.SampleClass

{

font-size: 10px;

background-color: blue;

}

CSS2 (Loaded last)

.SampleClass

{

font-size: 12px;

}

The end result would be:

.SampleClass

{

font-size: 12px;

background-color: blue;

}

Harkernator

rknewbow wrote:

The classes would be merged when an attribute exists in one class but not the other, but when there are conflicting attributes it appears the last .css file loaded wins.

Hmmmmmmm.

Here's my idea

The majority of the compliance issues, from what I've seen (and I don't have the 5 centuries necesary to review the whole thing), come from the height and width tags being used in HTML, that have been depreciated into CSS only.

I'm wondering if we can slap it into compliance by, as a sort of open source project, pick it apart and find all the tags that have this problem.

Then generating a seperate CSS file with classes for all of tags where this is the case.

Hopefully, we could generate a seperate CSS file that could be attached to the Master and would make the site compliant without altering the Master page.

Big problem may be that if MS has used the same class on some differently sized tags.

I might print out my Master Page (if it doesn't take up reams of paper) and see if I can make it work.

If so, I'll post some sort of plan on here to see if anyone wants to take on a small section of code.

Regards

Andy-H

I'm afraid it is not as simple as that. The CSS file does not change the HTML, just how it is displayed. Good XHTML compliant code would separate the presentation from the content, meaning that only the content and structure should be in the XHTML and the CSS would tell the browser how it should be displayed.

There are many issues to resolve, such as attributes in uppercase, attribute values not "surrounded in quotes", unclosed tag elements, depreciated elements and attributes and so on. If your page is visible on the Internet, put it through the W3C Validator to get a detailed report of what needs to be fixed (remember to add your doctype to the top of the masterpage first).

I found fixing the master page for compliancy to be the easy bit, building the CSS to work in quirks mode on all browsers with the SharePoint generated HTML (which I could not change) was more of a challenge. Even updating the page layouts was easy enough. What you then have to resolve is the output from user controls, web parts, web part zones, _layout (application) pages and there could certainly be more. That link I posted above some time ago (it appears to be down right now) goes into some very detailed solutions including intercepting the render method and changing the output before passing it back to the client. I've seen a few other things that can be done (eg: for the ASP:Menu) but it's not going to be an easy journey.

I'd love to see a solution that is compatible with SharePoint and compliant, but I fear we may need to wait for Microsoft to catch up and fix these things at the core.

Harkernator

I think really we may be missing the point slightly.

I, personally, am not bothered about making the whole thing compliant.

All want to do is be able to put the DOCTYPE in - as long as that is in, Ajax renders perfectly.

But the rest of the page does not.

The only problem with making it appear correctly seems to be with heights and widths, and the occasional font-face.

So I hope to be able to make it appear correctly - but I'm not worried if some eagled eyed person spots some tags that aren't perfectly accurate....

We will see what happens!

Regards

Andy-H

Fair enough, as well as heights and widths, you will need to look at padding and margin (CSS) as the box model will change in IE after adding the doctype and you'll notice some layout issues due to that. I can't think of anything else off the top of my head.

Good luck with it.

DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE

Re: SharePoint - Development and Programming DOCTYPE