Domino Does Standards Modes
IE users might notice the top blue banner on the site is now the height I intended it to be and the same height as in Firefox. Wondering why? Read on.
Remember last Tuesday I turned off JavaScript for this site. Well, on Wednesday I went a step further and turned off Quirks Mode!
If you look at the source to this page you'll notice the first line looks like this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Normal Domino websites have DocTypes that look like this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
The difference may seem slight, but it has a huge impact on how the page appears in browsers. The normal Domino doctype isn't sufficient to tell the browser how to display the document. This means it's falls back on Quirks Mode. With the more verbose doctype the browser is happier to render the page in Standards Mode.
Quirks Mode is used to emulate the non-standard behaviour of version 4 browsers. Standards Mode is used to display pages as they should be seen. As a developer and guardian of the future of the web you should want to work in Standards Mode.
To enable Standards Mode in Domino you need to make a server-wide setting, via the Notes.ini file. To do this I added a server configuration document to set DominoCompleteDoctype to "1". You can read more about this setting here.
Now all pages delivered by this server are in Standards Mode. More on that later. First, how I got this site to behave with the new doctype. All I had to do was change a few lines of CSS.
Remember how quirky browsers don't apply the font size setting for the body to tables cells. This meant having to use the following CSS:
body, td{
font-size:0.9em;
}
This is no longer needed when developing the standard way. On this site it meant text in cells was even smaller than expected (0.81em). There were a few other quirks, such as the way styles applied to nested divs, but I won't worry you with that for now. There's a good list of the differences between the two modes in Mozilla.
This is all very well for codestore.net, but what about your servers? My server hosts a few other databases, but I control them all. If you enable this setting on your server it will almost definitely have an affect on all sites it hosts. What if you don't have the ability or time to check and fix all the quirks? This setting is only really practical for servers that host one site or for new servers where all development is to start afresh.
To me, this setting looks like a quick way for IBM to appease us winging geeks out here in developerland. In reality it's of little practical use. What we really need is a way to set the doctype to anything we like and to be able to do this for individual databases. That's obviously too much to ask for though. Even for this year's Dear Santa letter.
Remember, turning off JavaScript and enabling Standards Mode will make a better web developer out of you.
Skip to the 
You can subscribe to an individual
I had tried that a few months ago, only to find that IE 6 started displaying Domino tables and their contents centered. Firefox and Safari were fine. Because of the large number of affected pages I reverted to quirk mode. I agree, this should be a database level setting to be useful.
Asking too much???
- How difficult would it be to implement an optional
$$HTMLDocType
predefined field that takes precedence?
I'd rather see this option at the Internet Site level first.
Then, ideally, have the option to override this at the database level.
Finally, the option to override this again at the design element level (with something like the $$HTMLDocType that Christian K alludes to).
How I dream of setting a language in the html tag!
One step at a time Sma ;o)
Well, at the point you do one, you should do all! This new ability was added in 6.5.3. Are there some ... undocumented enhancements along this line in 7.0 that some one may know about?
Conjecture: I take it that it was done at the server, instead of database or rather, form level, so as to speed up the processing that the HTTP Stack has to do. It's faster to grab an ini variable from memory than it would be to check for a field on a document (or form page property) or even database property, every single page load/response. Again, conjecture. Next time, world peace.
@Bill - there are other database properties that the HTTP stack needs to check specific to a database (such as "use javascript..."
Nope, I think this was a quick and dirty hack by IBM - with no thought for us developers other than a "there! Domino does a correct doctype".
Whats frustrating is the all or nothing approach - which mostly serves internal intranet servers/sites which are all probably running the same browser anyway. For me, running my sites on a shared server at DDN, the capability may as well not be there.
The feature was added in mid-code-stream as an alternative to a very dangerous hack that was being used and promulgated through the community. A switch value in the Notes.ini is relatively easy to implement, since the doctype statement is just a text constant added to the top (without a great deal of computatin') by the Domino web engine -- switch the cached value on server start-up, and the new value is put in place of the old on all subsequent pages. Yes, it is a bit "dangerous" to badly-written applications, but not nearly as dangerous as going to HTML 4.01 in the first place -- a HUGE number of applications were written on R5 that were just barely legal in HTML 3.2 (and that's saying a lot, since HTML 3.2 was not a prescriptive standard so much as a description of what people were doing at the time).
I'm not in a position to know for sure, but it looks like the doctype *may* be database- or page-settable in the next server release (post 7.0.x). That supposition is based on mini-polls in the developerWorks fora thrown out there by some Lotus developers. The slant was towards XHTML, but the only way to make XHTML a realistic possibility in Domino (as opposed to hand-crafted hacks) without destroying existing applications is to make the doctype settings and output switches more "local" than they are now.
Stan. Where do you find the time to do any actual work?
XHTML in Domino? I'll believe that when I see it. Domino markup that follows rules? Ha!
Somehow, I think they'll be able to pull it off, even if it's only for new development (or SEVERELY rewritten old applications if they've been tweaked for the web previously). As for finding the time, well, I have rather a lot of it on my hands lately, none of it for "actual work". I'm kinda laid up right now, and am conscious and lucid on an unpredictable schedule, something clients and employers find less than desirable. I barely have the ability to harass other Domino bloggers anymore....
THis may be a blatent hack, but you can have the doctype you want.
On the form properties, on the beany tab (second tab) set the content type to Other and leave the box blank.
Make your standard Jake Howlett $$HTMLHead field visible instead of hidden, add in the HTML, HEAD, and BODY Tags on your forms and your ready to rock. Seems like that is the granular control everyone wants, and the obfuscated method IBM chose to deliver it through.
Maybe you already covered this the other day, Jake? Can't remember... too lazy to look after trying this method out.
Oh, forgot to mention, put the doc type in your header subform right up front.
Be warned, with the content type set this way, plain text and passthru html both render as html.
@Jerry
You don't even need the $$HTMLHead field!
But if you change the ContentType to blank then you're not able to open the form using ?OpenForm.... only ?ReadForm will work as you can't edit HTML based forms!
@Jake
Another wish for Santa (aka IBM/Lotus): A @Formula to check wether the active webuser have edit access to a document:
@If(@IsDocAuthor("<unid>"); "<a href=''>EDIT</a>"; "") This should of course be possible to use in forms, pages, views(!) etc.
Lots of great info in the responses!
Based on what I've read, idle conjecture would assume if they can put native XML storage into DB2, they'll figure out how to get Domino to product XHTML code...and doctype to be more granular.
I guess I have only the following question: how much more exposure are we going to see? Or is this really something that will wait till Hanover?
@ John F - If we're "working around" (as opposed to hacking) everything else domino does, I don't need to edit a form anyway. Domino forms essenitally become like JSPs, where I'm going to write my HTML out myself and use form tags with action parameter to submit to controllers that handle writting the document back to a data ource, whether domino or not.
If I understand Jake's thrust over the past year or more, it's been to wrest control of the HTML from Domino's grasp. If we still insist on Domino after that, using it in the fashion I am outlining seems "better". Less crutching on Domino means less hedache working around Domino.... or so it seems to follow.
Happy Thanksgiving (tomorrow) to everyone in the States.
I have little faith in seeing alot of these features making it into Domino since they give far too much power to the Domino web developer, and I have not seen IBM try very hard on this front over the last few years. IBM has consistently hobbled Domino to give more of the true power to Websphere (native jsp support anyone?).
I will continue to hope and wish, but I will not hold my breath for them.
@Jerry -- unless Jake's been using hide-whens to let us read different articles, what you are suggesting is far from what Jake has been outlining. These are not "Treat as" forms, nor are they meant to be -- the Designer form works (and is supposed to work) just like a "normal" Domino form, using the standard form method and action values for editing and opening with a document for reading as normal. All he's done is turn off JS and supply a "what was clicked" field to receive the values posted by various submit buttons so he can determine server-side processing (essentially home-rolling the __Click field to trigger or fork WQS agents). That is a far cry from throwing away Domino's basic functionality, and certainly nothing like recreating JSP methodologies on the Domino platform. This is about using what Domino does, and does well, while trying to do away with features that may interfere with compliance with accessibility and usability guidelines. And while I think the process is going too far (mostly because of a misunderstanding of the capabilities of user agents), it is most certainly not throwing the baby out with the bathwater in the way you are suggesting.
@Jeff -- there is a perfectly workable JSP (and servlet) container available for no additional software cost. Garnet was a non-standard implementation, and while it may have had some kewl going for it, keeping it would have been the wrong decision both for Domino and for IBM as a whole. Get over it. Removing Garnet from the Rnext (Domino 6) code stream has absolutely nothing to do with the current real efforts to expand DXL on the web and create a genuine, fully-compliant XHTML output. Mark Vincenzes is the point man (public face) of these efforts; it would be worth your while to keep an eye on his developerWorks postings.
I will keep an eye out Stan. You simply have more faith in this than I do.
Whoa! I tried this on my dev server and it immediately broke all my intranet sites!
In fact, it broke IE 6.0 which went into a 100% CPU loop and had to be killed with task manager.
I guess I'm using too many IE-only features (all MS standard stuff though). It will take me weeks to find out what is going wrong.
Is it worth it?
Is it worth it? Good question. For you or for the greater good of the internet? For the internet, definitely. For you? Only you can answer that question. It depends how much you care about yout work I suppose.
Hi,
As a test I've turned off the Quirks mode for our websites. Apart from some minor bugs everything works fine in IE.
When I load the websites in Firefox of Chrome however, the css doesn't load.
Do you have any idea what's going wrong?
Peter Franken
The Netherlands
Hi Peter,
Have you made sure the content-type of the CSS is "text/css" and not "text/html" ??
Jake
Hi Jake,
Thanks for the quick reply.
Yes, i've made sure the content-type of the CSS is "text/css". See below:
<BASE HREF="http://prod01/cloud-id.nsf/">
<META HTTP-EQUIV="content-type" CONTENT="text/html; CHARSET=iso-8859-1">
<META NAME="robots" CONTENT="index, follow">
<LINK HREF="styles/validation.css" REL="stylesheet" type="text/css">
<LINK HREF="style.css" REL="stylesheet" TYPE="text/css">
I think the problem lies somewhere in the fact that I've saved my stylesheet as a page in the database (because it's easier to edit), but Firefox and Chrome never had any problems with it before.
I also have tried to upload the stylesheet as a file into the database, but no luck.
If I upload it to our server (outside the database) and put a hard URL to it, it works.
Peter Franken
That's not what I meant Peter.
What is "styles.css"? Is it a Page? If so you need to make sure the content-type of the page is text/css. You do this in the Page properties. This is different to the HTML "type" you've set in the code above.
Hi Jake,
That's seems to have done the trick!
I feel a little bit stupid right now ; - )