SitePoint Sponsor

User Tag List

Results 1 to 8 of 8
  1. #1
    SitePoint Guru
    Join Date
    Nov 2008
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Best Practices for naming Form Elements

    Hi I've been meaning to choose a particular notation style in my web code for the last couple of months, and would appreciate some advice on how to name the following:

    Form elements, i.e. the form itself and all its elements within, such as text fields, checkboxes etc.

    IDs and classes.

    I've also read that camel-case (is it the same as hungarian notation?) can be bad as it might be difficult to spot errors eg. myTestclass vs myTestClass. I am thinking of using dashes and keeping everything lower case for IDs and classes, unless there are valid reason not to do so. eg. my-test-class.

    However I'm not decided at all as regards to forms, I've read that namind elements by what they do might not be such a good idea as they might change later on, example a checkbox becoming a radio button, so chkRating might not be such a great idea.

    Anyway would like some advice from all the gurus out there Thanks!

  2. #2
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,888
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by drtanz View Post
    Hi I've been meaning to choose a particular notation style in my web code for the last couple of months, and would appreciate some advice on how to name the following:

    Form elements, i.e. the form itself and all its elements within, such as text fields, checkboxes etc.

    IDs and classes.

    I've also read that camel-case (is it the same as hungarian notation?) can be bad as it might be difficult to spot errors eg. myTestclass vs myTestClass. I am thinking of using dashes and keeping everything lower case for IDs and classes, unless there are valid reason not to do so. eg. my-test-class.

    However I'm not decided at all as regards to forms, I've read that namind elements by what they do might not be such a good idea as they might change later on, example a checkbox becoming a radio button, so chkRating might not be such a great idea.

    Anyway would like some advice from all the gurus out there Thanks!
    My advice would be to use all lower case for everything in the code, including names, IDs and form labels. If you stick to all lower case then you reduce the risk of confusion or mistakes. You're absolutely right that using CamelCase makes it very easy to get capital letters in the wrong place, and as classes/IDs are case-sensitive, that can lead to hours of frustration when it doesn't bl**dy work because you've missed a capital letter somewhere in either your code or your CSS...

    Form elements should be named for what they are, not how they work. It will make them easier to work with, and less confusing for you. Just as you wouldn't use <div class="redbox">, you don't want <input type="checkbox" name="tick-contact"> either. It takes more time to type in, increases the risk that you will miss part of the name when using it elsewhere (eg in the label), and - as you say - increases the risk that it will look silly when you subsequently change the input type.

  3. #3
    SitePoint Guru
    Join Date
    Nov 2008
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks Stevie, therefore using lower case and dashes for separating multiple words seems to be a good solution.

    I am still not decided on forms, I believe I've read somewhere that its a good idea to name forms like this eg. frm-contact, not sure how the form elements would be named though

  4. #4
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Odd, I've never given this any particular thought; it's a part of creating the site vocabulary. I name inputs for their content, e.g. fname for the input that takes the user's first name. The key in my mind is to make it easy for the mid tier coder to know and understand just what datum is being passed with each name/value pair.

    If an id is needed for the form itself, consider how you'd ask someone to hand you a print version of the form.

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  5. #5
    SitePoint Guru
    Join Date
    Nov 2008
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for your insights

  6. #6
    SitePoint Wizard silver trophybronze trophy
    Join Date
    Jul 2008
    Location
    New York, NY
    Posts
    1,432
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Essentially, the naming convention should dictate some sort of unified convention without using to specific of a name.

    Form control naming convention:
    control-1:
    control-2:
    control-3:

    E.G:
    <input class="control-1" type="text" name="" value="" />
    <input class="control-2" type="checkbox" name="" value="" />

  7. #7
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    I'd be careful with - since older browsers had issues with them (as far as I know it's still a source of the only Opera hack I've ever used : ), and you might want to use things like id's as hooks for Javascript.

    For those reasons, if I wanted space between words I would use the _ as I find it safer (except in links where an underline can hide it).

    I've used camelCase for my names and id's and haven't been unhappy with it yet. This might be because I've settled on a pattern and so everyone is following a set of rules... re-using the same set of rules eliminates mistakes more than anything else, I think.

    My forms are always #formWhatItDoes, so in CSS it's clear that it's a form, and which form.

    #formLogin
    #formAanmelden
    #formImageUpload

    For radios and checks, the values are often the names and id's.

  8. #8
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,151
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Most of the time for form element names I use the table column name which the field pertains. The form is named based on the entity which it manages and/or the action which it corresponds. I always try to make my names and ids relevant to the data in which they are meant to manage. In the end that is the only rule I stick by because different situations call for different ways of doing things. It all depend on the what the responsibility of the form and its fields are, whether data management has been abstracted, etc. There is no hard and fast straight forward naming conventions, it all depends on the situation. In regards to names though I always place all the form data in an array to be sent through $_POST. Never do I place field data at the root level of the post.

    HTML Code:
    <form id="login-1" name="frmLogin_1" action="http://local.test/index.php/" method="post">
    	<fieldset>
    		<legend>Login</legend>
    		<ul>
    			<li class="username">
    				<label for="login-1-username">Username<span class="required">*</span></label>
    				<input type="text" name="frmLogin_1[username]" value="" maxlength="25" id="login-1-username" class="">
    
    							</li>
    			<li class="password">
    				<label for="login-1-password">Password<span class="required">*</span></label>
    				<input type="password" name="frmLogin_1[password]" value="" maxlength="10" id="login-1-password" class="">
    							</li>
    			<li class="login">
    				<input type="submit" name="frmLogin_1[login]" value="Login">
    			</li>
    
    		</ul>
    	</fieldset>
    </form>	
    Where the name frmLogin_1 references the array of data pertaining to that form. Then by convention I use the form element ids as classes on the encapsulating element to have some way to differentiate element containers if the need arises. The reason why 1 has been appended to everything in this instance is so that multiple instances of this form can be created without id and naming conflicts.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •