Web form experience
My experience with web form elements formated by help of CSS are collected in this atricle. Some issues, problems and differences in elements rendering and in features follow. There is no official prescription, no regulation, nor reference model of how single form element should satisfy CSS properties. Therefore it is difficult to find correct face of styled element.
Many blogers reject an attempt to style form and they advice to let operating system render form elements according to its rules. Operating system draws form element perhaps only in IE and perhaps partly in FF. Take as an example element select in IE, it is nearly impossible to style it. Better way is let the browser to render form elements.
Web form tutorials mostly concentate its code on login forms, contacts forms, blog discussion forms and on sematic correct using of element label. Motivation of articles in this section is possibility to insert form elements to the compact forms for intranet. Such forms remind part of spreadsheet table. Besides majority of structured data are entered just to the spreadsheet tables and such a type of "form" is very natural. Can you imagine Excel table where cells are framed in the way of classic web input element?
Often Windows are switched to motive classic, another time IE is set up to not use style for form elements (menu IE: Tools / Internet Options / Advanced / Enable visual styles ...) Result is over framed elements with bulky pseudo-3d borders.
According to my very personal taste, the best graphic design of form elements is applied in Opera. Decent gray, shadowed elements which fit into any background, border are noteless. Classic elements in IE require gray background, because some parts of element are white, black parts creates too high contrast. XP motive use too much colors.
Web form common issues
If you want to apply CSS for adjustment form elements appearance, do not forget to switch page with web form to the standard mode. It does not matter if you prefer standard mode XHTML, or HTML, however one of the two following definition has to be used.
Originally I had been using simple HTML code. With arrival of XHTML and its big promise of future, I had rewriten all my intranet pages to the standard XHTML. At present I write new pages in standard HTML because it seems to me that XHTML is moving no way.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml/DTD/xhtml1-strict.dtd"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Selected DOCTYPE definition have to be located in the first line of code, ahead of section <head>. That ensures IE browsers to use standard box model at fixing dimensions of all (not only form) elements. Other browsers use standard box model by default.
Font, which is used in form elements is not inherited from style of global elements html {}, or body {} which are marked in red. For set-up font it is necessary to use star notation * {} (universal selector), or enumerate all form elements (marked green).
<style type="text/css"> html {font: normal 13px Arial, SansSerif, Verdana;} body {font: normal 13px Arial, SansSerif, Verdana;} * {font: normal 13px Arial, SansSerif, Verdana;} input, textarea, select {font: normal 13px Arial, SansSerif, Verdana;} </style>
Almost all form elements are able to set dimensions according to CSS properties width and height. There are two groups of form elements in relation to box model. Proportions of some elements are specified according to standard W3C box model, others keep traditional, qirk model. More you can find in article box model of form elements.
Majority of browsers meet unofficial practice to switch over the look of element to the classic face by using property style background. This practice is not always kept in Safari. In some cases is switch over effect done also by property border.
<input type="text">
Possibilities of styling this element was described in article input type="text". Here I would like to remind of text cursor disappearing bug in browsers IE and Opera. When text in element is aligned to the right side, or when input text is longer than the width of element, text cursor at the right side of element takes away. Reason for text cursor fade away is property padding: 0; that is sometimes part of CSS reset frameworks. Bug can be adjusted by setting padding: 0 1px 0 0; which creates room for text cursor at the right side.
Browsers IE6, IE7 and Safari create empty space around elements <input type="text"> and <textarea>. Current method of this space elimination (margin: 0;) works only in Safari. In case of IE6 and IE7, property float: left; have to be used. IE8 RC1 finally works as expected, elements do not require any empty space.
<textarea>
Code validators require using attributes cols and rows, which are indeed useless if element size is set by CSS properties. If you want to keep valid pages, you have to fill in mentioned attributes. Detail description of styling this element is in article textarea.
In FireFox you can find another type of inaccessible text bug. That comes when continual long text (without spaces), longer than the width of element (typical address link) is entered and at the same time horizontal scroll bar is disabled (overflow-x: hidden;). Then right part of continual text becomes hidden and unable to edit. Other browsers break long continual text on border of letter, or force to show horizontal scroll bar.
<select>
Basic problem when styling element select is inability of IE6 and IE7 browsers to work with border property of this element. It is impossible to override default setting, it means to set another border width nor to set border color. IE8 RC1 finally enables to set property border for this element. Other basic problem of select element in IE is inability to overlay this element by any other element. That was corrected as late as in IE7.
If you really need to remove select element border in IE, try solution described in article select experiment.
<input type="checkbox"> a <input type="radio">
Form elements checkbox and radio button are rendered and work unlike other form elements, that causes a bit confusion. Face of element is based on two-state image. By setting proportions, sensitive area for click (and status change) is reserved, but size of image stay unchanged. Reserved area is invisible, because usually it is not possible to set background color. Problem is also "border", of checkbox , which is almost identical with border of others form elements. That evokes false impression, that it is possible to remove such a border. In fact "border" is part of image, not part of element. Some browsers try to change the size of image, but results are not very attractive.
Other specific feature is submitting element content. Regular elements submit to server name=value pair, even if value is empty. In case of inactive checkbox element, no information is submitted, not even name=. Developer can consider that as malfunction.
<input type="file">
This element was described in article file, and there was approved that this element is almost impossible to modify by use of CSS properties. Only one thing which is possible to set is the width of element.
Questionable is path to file display. You can see start of lengthy path, but no real file name. This problem is perfectly resolved in Safari and Chrome, where only file name is displayed. Lengthy and useless file path stays hidden. Also the look of element in Safari and Chrome is much more better.
<input type="submit">
In general, there are no problems at using CSS properties for styling submit element. Only one differences are in a way of animation when button is clicked on. Mostly user do not notice any variation.
<input type="hidden">
This element has no graphic shape and user cannot directly change its value. Typical use is for storage of id database record at editing that record. When modified form returns to server, server script according to that value can find original record and save new data to the right place. It is possible to change the value of hidden element by the help of JavaScript and so retain result of some client activity (e.g. vertical position of scroll bar).
MS.NET works with forms in much different way. Entire form state is saved in hidden field element named _viewstate. When form contains tens fields, all names and values are encrypted there. Then in net wander tens of needless KB garbage. Other speciality is impossibility to redirect form to another server script. Only one form is allowed on one page in .NET. All that deviations are very different from original philosophy of web forms and for me it is not acceptable.
JavaScript trouble
There is no way how to force the user to have switched on JavaScript in his browser.
Basic function of form is submitting its content to server and it is done without help of JavaScript. Script is usually used for validation and blocking form sending when not correct data are entered. It is necessary to notify, that to overcome such restriction just switched off script is enough. Therefore form validation on the server side always have to be done.
Another issue is form submitting by help of key Enter and not quite clear support of that possibility. Solution dependent on JavaScript help only when script is enabled. Unfortunately there is no attribute enableEnter. JavaScript is often used for activities which should be done by system or browser. Example of such action is focus of elements. That problem is greatly solved in Safari and Chrome.
After many experiments with Ajax and forms, I have to declare, that forms and Ajax integration rather hard. Needed scripts are complicated and at error, script quietly stop running. Then form acts the same way like JavaScript was switched off. In addition, page, form and especially database have to be coded in UTF-8. Otherwise it is not possible to transfer characters with diacritic marks. Using Ajax for complex validation (overlapping terms in calendar) is O.K. Using Ajax as basic method of work with form is for hard core coder only.
Especially code beginners do not realize, that good form is not enough. Script on the server side have to read form data, perform validation, open database, create new or edit existing record. Well designed database, familiarity with its structure, knowledge of used data types, all that is necessity. Real program job starts when form data are delivered on server.
There has been series of tables how every browser supports CSS in common HTML elements. There are even reputable Acid tests. In case of form elements nothing like that exists. Some referential model, list of CSS properties which should be supported and what result is expected for each form element is needed. It is hard to build good web applications without perfect web form elements.
updated 04.02.2009