Main Points
- Contact Form: Server Side Code The revised markup as seen on the server side.
- Contact Form: Client Side Markup The actual XHTML output from the server that visitors see.
- Skip to Main Points links return to the Main Points menu.
Contact Form: Server Side Code
In implementing an ASP.NET master page based template across the site, this testing page or its dependencies may have been moved. Therefore, some of the references have been changed possibly including master page friendly techniques like application root relative references. They are not original.
[chroniclemaster1, 2008/11/07]
Oops. I forgot to save the HTML when I had the contact form floated right beneath the main points box. Suffice it to say, it was unsuccessful. There were two main problems, neither technically about the form. First, a short page doesn't even creep all the way down past the contact form. Everything reaches past the main points boxout, but adding the extra height with the floated contact form meant that shorter pages didn't clear the bottom - some by quite a bit. It looks much different visually, like a two column layout, and worse two columns of very different length.
Second, occasionally there are long words (typically caused by headings with larger font size) where the word won't fit in the ~60% room left by the main points boxout. In that case, the word drops all the way to the end of the boxout causing a gap between where it should have been and where it has fallen to. This is pretty much unavoidable with a boxout. This puts a premium on keeping the boxout short so the effect is minimized when it does occur. Doubling the boxout length by adding the contact form dropped the word below the fold making it look at first glance like the page was simply broken. Between the two problems that nailed the coffin for floating the contact form right. However, all was not lost.
The XHTML code has been polished and is now nicely semantic. We've been converted to the POSH movement, Plain Old Semantic HTML. POSH states that you should write your webpage to contain your content. It dictates using HTML tags for what they are supposed to be for, lists for lists, etc. POSH is basically part of web standards and wants to write HTML that adheres to good code separation ideals. It is a backlash against using HTML primarily for styling. By using POSH principles we simplified the form design by just designing a form. We didn't bother even looking at the results on the page until we started to work on CSS styling. In that sense POSH is part of our code separation goals and a very sensible one. POSH has also allowed us to create fully accessibile HTML. Forms are notoriously difficult to use without a mouse, but the art of creating accessible forms has been fairly well developed if you take the time to track down all the information spread across the internet. Primarily adding label tags, creating a legend, and a few other adjustments make the form much more accessible to visitors. Here's the server side markup including the webform.
<asp:textbox id="tbEmail" runat="server" cssclass="tbEmail"> </asp:textbox>
<asp:textbox id="tbComments" runat="server" cssclass="tbComments" textmode="multiLine"> </asp:textbox>
The first thing you'll notice isn't even ASP.NET stuff. We're having a javascript problem developing something unobtrusive to swap images. The functions we've built so far either haven't worked or have interfered with the menus, we're still trying to figure out why. The ASP.NET code had to be fairly carefully tested, but these settings for the web controls translate pretty well into semantic markup.
Skip to Main PointsContact Form: Client Side Markup
Not to be outdone, let's take a look at the end result. What we have above is server side code. Here's the "real" code as it outputs to a visitor's browser. For the sake of simplicity, I've only copied the portion of the code that changes, the webform itself (ie everything inside the <form> tags).
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="blahBlahBlah" />
</div>
<input name="tbEmail" type="text" id="tbEmail" class="tbEmail" />
<textarea name="tbComments" rows="2" cols="20" id="tbComments" class="tbComments"></textarea>
<span id="lblSent">Test.</span>
You can see it's a little messy. ASP.NET doesn't pay a whole lot of attention to clean coding practice, so once the server gets finished with it, the spacing and indenting of the .NET web controls come out a little interesting. Yes, I also took the liberty of replacing all the ViewState gobbledy-gook with something shorter. The original just runs insanely off the page which messes with the page width, so I clipped it. I hope it makes the demonstration easier to read.
However, I hope you can see that with a little patience and a Lot of careful checking -- one change in the ASP.NET properties, check the XHTML output from the server, back and forth -- you can achieve semantically good XHTML. The form and all the web controls have semantic names that correctly identify what each item is. They set appropriate classes and ids that allow all visual appearance to be controlled by CSS. ASP.NET may not be CSS friendly, but it is compatible; it just takes a little longer to set up. Once the .aspx page is constructed properly, you gain the power of .NET in a standards-based design. You can even achieve code separation for the server side programming. Contrary to the usage of PHP -- the only other major server side script -- even the VB.NET code is separated from the file. So while it takes takes more time, the results are certainly worth it.
Skip to Main Points