By now you are probably all familiar with using rich text editors with Domino. It's almost 2 years since I first talked about it, so I'm guessing you've all seen them used with Notes Rich Text fields by now and are aware of the methods involved. It's a technique I've used more than a few times on projects since I discovered these handy little editor plugins. I almost take them for granted. Until recently that is.

Not long back I was working on a "feedback" form for a website. The clients wanted a basic rich text editor for the Message/Body field. Simple enough. Something like this:

The message field is a a standard Notes Rich Text field and saved as Passthru HTML in the backend document.

Another requirement of the system was that it worked in browsers with no JavaScript support. This is where I hit a snag.

The Problem:

What if the user has no JavaScript? Well, most obviously, the editor itself won't load. We can simulate this using the IE Developer Bar. In the shot below I have disabled Script. As you can see the message field is now a plain textarea element.

All is not lost. The form still works, but the user has a limited experience (something they are probably used to having such a backward browser).

However, there's more to it than this. If you studied the LotusScript code involved in my approach to using these editors with Domino you'll have noticed it works by marking the whole content of the field as Passthru HTML. This works fine when the editor is running as it renders news lines using P elements. However, without the editor new lines get stored in the field, but, as it's marked as Passthru HTML they don't render back to the browser in read mode. Therein lies the problem. For a normal Rich Text field with line breaks Domino will render BR tags in their place when sending the field contents to the browser. When we mark the whole field as Passthru Domino doesn't bother with the BR tags and it doesn't look like the user intended it to.

The Solution:

What I needed was a way to tell if the browser had JavaScript enabled or not. If the browser supports script the code goes ahread and marks the whole Body field as Passthru. If JavaScript isn't enabled the code doesn't run and the field is stored as standard Rich Text format.

At first I'd thought this would be straight-forward and expected there'd be a CGI variable or something to tell me if JS was supported. After some quick searching I couldn't find anything. While I'm still sure there must be an easier way I came up with the following simple solution using nothing but the <noscript> tag.

The noscript tag only shows its content to browsers that don't support JavaScript. For example, the following HTML would tell users of non-JavaScript browser what they probably already know:

<noscript>
 <p>Your browser does <strong>not</strong> support script.</p>
</noscript>

Users of more up-to-date browsers will see nothing.

So, on my form I added a hidden CFD field called "JavaScript" which computed to itself (a "temp" field, if you will), like the one below:

Then I added the following PassThru HTML directly to the form.

<noscript>
 <input type="hidden" name="JavaScript" value="Off" />
</noscript>

Can you see what it does?

This "JavaScript" field is hidden on two levels. Firstly it's hidden from the reader - always - who will never see anything. Secondly it's hidden from the actual Form depending on the browser's capabilities. When JavaScript is enabled the field is not sent to the server. If JavaScript is disabled the <noscript> element makes its content available to the Form and, when it's posted, the server receives a value of "Off". This is illustrated below (using HTTPWatch).

First, here's the data POSTed to the server when JavaScript is enabled:

Look at the bottom pane. There you'll see the Parameter/Value pairs for each field being sent. In this case only two fields are sent - Title and Body (we'll ignore Query). Now, here's the data POSTed to the server when JavaScript is disabled:

Notice the extra field called JavaScript, which has a value of "off"? The fact that this name/value pair is being sent to the server is our signal that JavaScript is not supported.

In our WQS Agent it's then a simple case of testing the field's value. If it has any value at all then it must of "Off" and we know the browser has JS disabled. On the flip side we know that no value means the field is missing and that we can go ahead and assume support for script. The code looks something like:

If vWebDocument.JavaScript(0)="" Then 'script enabled
 Call ConvertRTtoHTML( vWebDocument, "Body" )   
End If

In this case the field is marked as PassThru only if scripting is supported. Otherwise the WQS agent does nothing and the field is stored as normal RT format.

Summary:

It's odd that I've been a developer for so long and never considered how I would check for browser script support in an Agent. Now that I have I find myself thinking of other ways it might be useful. E.g: A browser with no script probably can't validate form input, so we'd know to try and do it server-side instead.

Hopefully you'll find some use in this and I'm not going to feel stupid when somebody tells me there's an even simpler alternative. If nothing else it's food for thought and shows yet another trick we can use as developers.