Tip: Do NOT Close a Form Inside a DIV
Sometimes even the painful lessons don't teach me anything. Today I learnt again a valuable lesson in HTML structure.
A badly nested combination of <form>s and <div>s is bad, bad, bad. For example, don't ever do this:
<form name="DominoForm"> <div id="container"> </form> <form name="MyOwnForm"> </form> </div>
Not only is it just plain wrong in terms of valid HTML structures, but IE 6, at least, does not like it and all sorts of unpredictable stuff can start to happen.
So, next time you want to close Domino's default form and start your own make sure the closing form tag is right up at the top of your Form in Designer and before any divs get opened.
Skip to the 
You can subscribe to an individual
This is because both the div and form tags are "container" tags right? I think the same then would apply to span, tables, and other "container"-type tags.
Container tags? Well, they're both block-level elements which might have something to do with it.
Well here's a trick if you don't like playing silly buggers with Domino's FORM tags. Just leave Domino alone to do it's thing and add additional FORMs dynamically.
Now you can have a search form on the same page as a xxxx?OpenForm.
<script type="text/javascript">
sRet = "<form name=\"Search\" method=\"post\" action=\"/path/database.nsf/frmSearch?CreateDocument\" style=\"display:inline;\">" +
"<table id=\"tblSearchtext\" border=0 cellspacing=0 cellpadding=0>" +
"<tr>" +
"<td align=left valign=middle><input name=\"Query\" id=\"hd_txtSearch\" type=\"text\" class=\"searchbox\" /></td>" +
"<td align=\"left\" valign=\"middle\"><input type=\"image\" name=\"Query\" src=\"/graphics.nsf/submit.gif\" alt=\"Search\" align=\"AbsMiddle\" style=\"border-width:0px;height:18px;width:17px;\" /></td>" +
"</tr></table></form>";
var ni = document.getElementById('headersearchform');
if (ni!=null) {
var newdiv = document.createElement('div');
var divIdName = 'searchformin';
newdiv.setAttribute('id', divIdName);
newdiv.innerHTML = sRet;
ni.appendChild(newdiv);
}
</script>
Put it in a function and call it with onload and you now have forms[0] (Domino's default form) and forms[1] your new search box. A word of warning though. IE6 still tries to play silly buggers with it if you have input fields with the same name.
I tend to think of tags like div, form, span, etc. as "container" tags - sorry, interjection of my own nomenclature.
I'm a very visual person, so it helps me structure UIs by thinking of each of these "container"-type tags as cups - each container their relative contents in their own container. Now, if I start a form (1 cup), put a div inside the form (another, logically smaller cup), but try to end the form before I end my div, I'll have a broken container - and thus my UI could go all wonky.
Just a methodology that keeps my mind in check really - I've gone through firebug more times than I'd like to admit trying to find out why something isn't working as I think it should only to realize that my dynamic-generating "container" tags are cracked and leaking markup!
Both div and form elements are block elements. It is always best to have well formed HTML. CSS works better and it makes it easier to debug. Also if you port your application to a Blackberry it really does not like it if you don't have well formed HTML. For instance if you have a table without an end tag, the Blackberry will not honor the table columns and will display everything as if it were one run-on sentence.
If you create a Domino web application for a mobile device is doesn't always have javascript, so I would not count on javascript to create forms. I use javascript to enhance the user experience and don't always count on it being available.
Another common problem I see often is people who place forms inside tables, where the form elements span several cells or rows. They often try to do this:
TABLE
TR
FORM
TD
TD
TD
/FORM
/TR
/TABLE
or something like that. The same problems occur: some browsers seem to be unable to sort out the DOM properly. Also DOM references in Javascript tend to fail silently in these cases.
I don't get it. They're not nested - period. That's all there is to say there. Doesn't matter what you call them, they're just not nested properly.
@Chris
I hear you. The "cup"-analogy makes good sense to me.
If you use the Web Developer toolbar for Firefox (and you shoud be), there is a keyboard shortcut to submit the current page to the W3C validator (default is Ctrl-Shift-A). This uses the method where you can paste your code on the W3C site, so works even when doing local development etc.
If something is screwy on your page the first thing you should check is if the HTML is valid. This will pick up things like putting a form tag in between table elements as it is not allowed in that context according to the HTML spec. Even if nothing is screwy, you should still validate every page your create to ensure you're producing proper HTML and not just tag soup.
Having valid HTML won't magically make your site work cross-browser, but it is a good starting point.
And it is possible to make Domino pages validate - you just have to know that Domino's default DTD means your pages are HTML 4.01 (not XHTML), so you can't always use XHTML style tags (eg. the meta tag has no closing tag). At least this was the case in the last version I used, which was 6.5.
Web Developer Toolbar ist great, but for validating markup, I find Html Validator way more convenient. It's a bit heavy-weight, since it contains a full Tidy implementation, but that's why it is faster than online validation.
I may be mistaken, but the expression likely comes from Russian nesting dolls. Apply that to your code and your good.
I may be mistaken, but the expression likely comes from Russian nesting dolls. Apply that to your code and your good.
it's not valid XML either...
@Marcin
I've been using the web developer toolbar and Firebug for a while and never noticed that shortcut - Thanks!
As for XHTML - I know that's fixed in R8 (look into $$HTMLFrontMatter) and I think they snuck that into 7.0.2