What do you call the thingies on an HTML Form where you enter data in some way shape or form?
Controls?
Input Thingies?
What is the formal name for Text Boxes, List Boxes, Check Boxes, Radio Buttons, etc.
TomTees
| SitePoint Sponsor |
What do you call the thingies on an HTML Form where you enter data in some way shape or form?
Controls?
Input Thingies?
What is the formal name for Text Boxes, List Boxes, Check Boxes, Radio Buttons, etc.
TomTees
all of the above are valid
well i dont know that 'thingies' is a proper technical term.
I believe the phrase you are looking for is 'form fields'.
Based on W3C, maybe Input Elements is the best term.Originally Posted by StarLion
TomTees
That's the term I've always used.
<cfset myblog = "http://cydewaze.org/">
or even form controls - I'm not sure there is a "one size fits all" answer
Strictly speaking, input elements would be things contained within/defined by <input> tags. TextAreas and Select Boxes would be excluded from this definition.
I'm not so sure.
I would have thought that textareas and select lists are still effectively inputs from the user, albeit the user input from select lists is limited to the list's options. But does it really matter?
Maybe the easiest thing is to just collectively call them "form thingies"
Well if (as the original poster did) you're going to use the W3C standard, they define an "input element" as the attributes of the <input> tag. So by said standard, 'input elements' would be a collection of <input> tags.
Well this is what W3C says...
http://www.w3schools.com/html/html_forms.aspHTML Forms - The Input Element
The most important form element is the input element.
The input element is used to select user information.
An input element can vary in many ways, depending on the type attribute. An input element can be of type text field, checkbox, password, radio button, submit button, and more.
TomTees
the w3schools website is not run by the W3C and has nothing to do with it.
And in any case, those " w3c standards" are simply recommendations. They are not enforcable in any way.
Well the reason i said form fields, is because there is a container for elements in a form. It's called the <fieldset> tag. As in... a set of fields. in a form. Form... fields.
and there is nothing wrong with "form fields" just like there is nothing wrong with "form controls".
Off Topic:
The w3schools like with many of its markup examples/explanations or definitions are usually inaccurate or poorly defined. Using some of those form examples would also lead to invalid markup. And there is a difference between XHTML and HTML forms unlike what they say.
Form "controls", is the correct generic term used for; buttons, checkboxes, radio buttons, menus, text input, file select, hidden controls and object controls and so forth.
Though typically if you use them in a sentence you would say which particular one you were talking about, e.g. checkboxes. If you were talking about a line of code you may then also refer to whether it was associated with INPUT, TEXTAREA or SELECT element, etc.
};-) http://www.xhtmlcoder.com/
Thinking Web: Voices of the Community
> March 2013 - SitePoint forums: Spot the Error 3: Calling all Sleuths! Winner Announced!... She knows how to spot simple <code> errors but do you?
When talking about screen readers, "form controls" includes legends and labels, which I'd think most developers wouldn't consider the same as inputs.
Interestingly, Javascript considers "fieldset" to be a "form element" but not the legend or the labels.
I personally say "form controls" and if I really mean only the actual inputs I will call them "inputs" (to include all types of form inputs).
The only reason to know which term is the "best" is to know which one you want to use when searching for something on teh googles.
Imho the w3schools website, although not affiliated with the W3C, is a very good resource for anyone learning html, php and javascript.
Probably the writing style is good but it is riddled with inaccurate information.
};-) http://www.xhtmlcoder.com/
Thinking Web: Voices of the Community
> March 2013 - SitePoint forums: Spot the Error 3: Calling all Sleuths! Winner Announced!... She knows how to spot simple <code> errors but do you?
I always thought it is pretty accurate.
Can you post some links to pages where the info is innacurate and state what the coorect info should be.
http://www.w3schools.com/html/html_forms.asp
On that page; those are not samples of HTML markup.
Nitpicking: the forms should also contain a fieldset and legend or a block level element let alone labels. Labels are assigned for "form controls" that don't have their own 'text', i.e. INPUT
Yes, minor issues but worthy of note.
};-) http://www.xhtmlcoder.com/
Thinking Web: Voices of the Community
> March 2013 - SitePoint forums: Spot the Error 3: Calling all Sleuths! Winner Announced!... She knows how to spot simple <code> errors but do you?
I was asking because I was working on some Object-Oriented Programming (OOP) and I was looking for a good name to generically call those items.
For my need, it doesn't matter whether the terms being thrown around are HTML vs XHTML vs whatever.
Thanks,
TomTees
yep, nitpicking
<labels> are not compulsory. I don't always use them with <input> and my markup still passes as xhtml strict.
Whether the code on that page passes the w3c validator will also depend on which doctype you use.
If using transitional, the only error the validator picked up in one of the sample codes is a missing "action" attribute in the <form> which in the context of the code being to demonstrate the <input> element, I can see why it was omitted.
Later on in that page where they talk about the submit button then the action attribute is included in the <form> as it should be according to the context of describing the submit button.
I'm not convinced the w3schools website is riddled with inaccurate information, as you put it, so I am comfortable continuing to recommend it to at least newbies in the future.
Neither are <h1>header text</h1> in place of<labels> are not compulsory. I don't always use them with <input> and my markup still passes as xhtml strict.
<p><strong><font size=20px>header text</font></strong></p>
BUT most of us would argue one is correct on a number of levels, while the other one is code that one should be so ashamed of that they should lock themselves up in the attic and remain there until all who know them have died off or moved away : )
Also, if you're not using labels then you're blocking content from users of some screen readers, because labels are form controls while plain text is not. This is why they are required in WCAG and why they were invented in the first place.
W3Cschools was incorrect about the clip property... I remember someone (Ryan Reese?) coming here confused why their code wasn't working because instead of reading the W3C specs, they read W3schools site, which at the time said elements needed to be positioned or positioned relatively (though their code example is the same as now, with position: absolute) which they have since corrected.
This page explains more and better: http://www.w3.org/TR/CSS21/visufx.html#propdef-clip
however neither page mentions The Big IE Bug (I can understand W3C not mentioning it because they only state proscriptive, not descriptive, but W3schools should have mentioned it!): The commas make clip break entirely in IE6 and 7 (not sure about 8 or 9). Browsers remember the older, ambigious specs where commas were not mentioned and so accept it, BUT IE is the one who insists on no commas. There are a good hundred other sites who do explain this.
I would treat w3schools like wikipedia: if you need quick information that's not necessarily accurate, you can go there, but if you need absolutely correct information, you go to the source (really, wikipedia's real use is that there are sources, though I always get bummed to find the web sources being 404).
If using Transitional, the font tag I used above also isn't flagged. Transitional lets you put any type of garbage code you want on a web page... frankly I'm not sure there's any real reason to bother validating stuff written for a Transitional doctype... maybe for mismatched tag nesting, little more.If using transitional, the only error the validator picked up in one of the sample codes is a missing "action" attribute in the <form> which in the context of the code being to demonstrate the <input> element, I can see why it was omitted.
If you're using a Strict doctype, you cannot have inline elements directly in a form (I think HTML5 was changing this since all the HTML5 form examples I see don't have a block child... BUT then many of the HTML4 examples also don't have it and there they are incorrect), so either a div or a fieldset (or p's as the old specs have it) are necessary.
After getting burned by information of a few elements on w3schools, I was shown the specs (and better sites like HTMLdog) and I haven't gone back to w3schools... however I can't comment on their Javascript accuracy.
It's all well and good to have WCAG but at the end of the day they are guidelines and not enforceable onto everybody.
If a web page passes the w3c validator as xhtml strict, then my job is done.
Same goes for strict validation. W3C are also but guidelines.It's all well and good to have WCAG but at the end of the day they are guidelines and not enforceable onto everybody.
A poor attitude for a web developer to have, but not uncommon. After all, it's so easy to ignore a minority because, well, they're a minority and therefore have no rights (a minority you and I will join as we age, and can join at any moment). To heck with them. To heck with usability, accessibility, or even the whole point of making the site in the first place. Which is why the unfortunate practice of "legislating accessibility" exists: people are resorting to lawsuits to make stuff work for them. Meh. Yugos do move forward, why make them any better? But hey, I get a paycheck. Let's go fishing.f a web page passes the w3c validator as xhtml strict, then my job is done.
yes totally agree, but I choose to code in xhtml.
It's not my attitude because it is totally up to the client, unless he/she is otherwise legally obliged, to decide how accessible they want their website to be.
I don't provide additional accessibility for free and I am not going to bump up my fees to cater for the additional time it would take to code additional accessibility and hence force it upon my client while at the same time make his/her website more expensive if they didn't want full accessibilty.
If a client stipulates they want full accessibility in our agreement then I am happy to provide it at the additional cost.
If the client does not stipulate full accessibility then I don't force it on them resulting in an additional cost to them.
Posting Permissions
Bookmarks