Posts Tagged ‘form’

META Tag ‘MSThemeCompatible’

Wednesday, March 31st, 2010

Okay, so this one’s a little old, and I just found it while looking at some of Microsoft Update’s HTML source, it appears to be relevant for MSIE6 and newer and may be responsible for some interesting styling and behaviour of form components.

A quick search for it turns up lots of discussions about other browers such as Firefox being effected if the value is not defined… as such it’s likely a good idea to define it in your pages to be sure.

An old MSDN entry reads…

When running on Windows XP, Internet Explorer 6 and the content displayed in it sports a look and feel that matches the Windows XP platform. You can opt to have your HTML content not take on the same look as the operating system for elements such as buttons and scroll bars, by adding the following META tag:
<meta http-equiv=”MSThemeCompatible” content=”no” />

Cheers

Tags: , , , , , , , ,
Posted in MSIE bugs, WebStandards, Work | No Comments »

HTML FORM’s unexpected effect on layout

Monday, June 2nd, 2008

I was recently looking back at some websites I’d created years ago and realized just how much of a hastle the HTML FORM tag used to be for page layouts.   This generally resulted in non-valid markup where the FORM tags themselves were improperly nested in TABLE, TR and TD tags.

Other than the obvious accessibility and semantic markup issues, there are two specific items that must be realized about the layout when working with a FORM.

The following examples assume the following source:

Hello<form>Again</form>World

FORM is a block element, forcing content around it to be separated:

Example displays as:
Hello
Again
World

  • FORM generally has a bottom margin to push content down below it.

Example displays as:
Hello
Again

World

  • CSS can fix both of these cases depending upon your specific problem:

<style type=”text/css”>
form { margin-bottom:0; display:inline; }
</style>

Example displays as:
HelloAgainWorld

 Cheers!

Tags: , ,
Posted in WebStandards, Work | No Comments »

HTTP Forward vs. Redirect

Monday, September 10th, 2007

A Controller servlet may perform either a forward or a redirect operation at the end of processing a request. It is important to understand the difference between these two cases, in particular with respect to browser reloads of web pages.

Forward

  • a forward is performed internally by the application (servlet).
  • the browser is completely unaware that it has taken place, so its original URL remains intact
  • any browser reload of the resulting page will simple repeat the original request, with the original URL

Redirect

  • a redirect is a two step process, where the web application instructs the browser to fetch a second URL, which differs from the original
  • a browser reload of the second URL will not repeat the original request, but will rather fetch the second URL
  • redirect is marginally slower than a forward, since it requires two browser requests, not one
  • objects placed in the original request scope are not available to the second request.

There are several ways to perform a Redirect, here are a few common ones:

  • URL Redirection (HTTP 301): 
    HTTP/1.1 301 moved permanently

Location: http://www.example.org/
  • HTTP Refresh Header (Not Recommended) 
    HTTP/1.1 200 ok

Refresh: 0; url=http://www.example.com/
  • HTML <meta /> tag 
    <meta http-equiv="refresh" content="0; URL=http://www.example.org/" />
  • JavaScript (many possible solutions, generally not accessible or searchable) 
    <script type="text/javascript">location.href='http://www.example.org/';</script>

In general, a forward should be used if the operation can be safely repeated upon a browser reload of the resulting web page; otherwise, redirect must be used. Typically, if the operation performs an edit on the datastore, then a redirect, not a forward, is required. This is simply to avoid the possibility of inadvertently duplicating an edit to the database.

More explicitly :

  • for SELECT operations, use a forward
  • for INSERT, UPDATE, or DELETE operations, use a redirect

In HTML, a <FORM> tag can either GET or POST its data. In this context, a GET corresponds to a SELECT-then-forward, and a POST corresponds to an edit-then-redirect.

It is strongly recommended that forms for the input of search criteria should use GET, while forms for editing database records should use POST.

SECURITY NOTE: When using GET, be sure to not expose sensitive data in the URL’s.

Tags: , , , , , , ,
Posted in WebStandards, Work | No Comments »

Single FORM INPUT causes submit on Enter/Return

Monday, September 10th, 2007

This is a browser oddity that I’ve had to code around for years.  In most modern browsers (currently Mozilla Firefox 2.x and MSIE 7.0), when a FORM contains only one editable INPUT field pressing the Enter or Return key will automatically submit the form, but when there are more than one the form is not submitted.   This irregularity in the single field case is responsible for several odd errors, and often results in double-submits of form data to the server.

Here’s a newer solution to the problem, the ‘magic’ is in the javascript events that we’ve added to the FORM object itself, no longer do you have to place event handlers on every INPUT field as has often been done in the past.

NOTE: not completely valid XHTML for ease of documentation and readability.

<html>
<head>
<title>test of input submit</title>
<script type=”text/javascript”>
function keycheckForm(formObj,evt){
if(isEnter(evt)){
//alert(’in form’);
if(checkFormInputs(formObj)){
formObj.submit();
}
}
}
/*
* Added to handle enter key press
* NOTE: this is based on  a ‘legacy’ function [checkEnter(e)] that returned the reverse boolean values.
* @param evt Event
* @return boolean
*/
function isEnter(evt){ //e is event object passed from function invocation
var characterCode; //literal character code will be stored in this variable
if(evt && evt.which){ //if which property of event object is supported (NN4)
characterCode = evt.which; //character code is contained in NN4’s which property
}else{
characterCode = evt.keyCode; //character code is contained in IE’s keyCode property
}
var rc = false;
if(characterCode == 13){ //if generated character code is equal to ascii 13 (if enter key)
rc = true;
}
return rc;
}
/**
* @param formObj Object
*/
function checkFormInputs(formObj){
var rc = false;
var allInputs=formObj.getElementsByTagName(’INPUT’);
var formInputs = allInputs.length;
var textInputs=0;
if(formInputs>1){
var ct = allInputs.length;
var i;
for(i=0; i < ct; i++){
var inputObj = allInputs[i];
var typ = inputObj.type;
if ((typ==’text’) || (typ==’password’)) {
textInputs=textInputs+1;
}
}
if(textInputs>1){
rc=true;
}
}
if(rc==false){
//alert(”blocked because of size”);
}
return rc;
}
</script>
</head>
<body>
<form action=”example.php” method=”get” onkeypress=”return keycheckForm(this,event);” onsubmit=”return checkFormInputs(this);”>
<input type=”text” name=”textfield1″ value=”testing1″ />
<button type=”button” name=”mybutton” onclick=”this.form.submit();”>Click Me</button>
</form>
</body>
</html>

Cheers!

Tags: , , , , ,
Posted in WebStandards, Work | No Comments »

Auto focus ‘first visible’ form field on page…

Wednesday, July 5th, 2006

Occassionally there comes a need to set the focus within a web page to the first ‘visible’ form field, here’s the most convenient I’ve found thus far…

Implementation:
1. Add the following Javascript to the HEAD section of your page.

function formfocus() {
if(document.forms.length > 0)
{
var formElements = ["text", "checkbox", "radio", "select-one", "select-multiple", "textarea"];
var form = document.forms[document.forms.length-1];
for (var j = 0; j < form.elements.length; j++)
{
var field = form.elements[j];
for(var x = 0; x < formElements.length; x++)
{
if (field.getAttribute("type") == formElements[x])
{
field.focus();
return false;
}
}
}
}
}

2. Add the function call to the BODY tag…

<body onload="formfocus();">

That’s it! Enjoy!

Tags: , , , , ,
Posted in WebStandards | No Comments »