SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 37
  1. #1
    SitePoint Evangelist TomTees's Avatar
    Join Date
    Apr 2010
    Location
    Iowa
    Posts
    553
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question about Forms

    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

  2. #2
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    all of the above are valid

  3. #3
    Keeper of the SFL StarLion's Avatar
    Join Date
    Feb 2006
    Location
    Atlanta, GA, USA
    Posts
    3,748
    Mentioned
    69 Post(s)
    Tagged
    0 Thread(s)
    well i dont know that 'thingies' is a proper technical term.

    I believe the phrase you are looking for is 'form fields'.

  4. #4
    SitePoint Evangelist TomTees's Avatar
    Join Date
    Apr 2010
    Location
    Iowa
    Posts
    553
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by StarLion View Post
    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.


    TomTees

  5. #5
    SitePoint Wizard bronze trophy cydewaze's Avatar
    Join Date
    Jan 2006
    Location
    Merry Land, USA
    Posts
    1,096
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by StarLion View Post
    I believe the phrase you are looking for is 'form fields'.
    That's the term I've always used.
    <cfset myblog = "http://cydewaze.org/">

  6. #6
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    or even form controls - I'm not sure there is a "one size fits all" answer

  7. #7
    Keeper of the SFL StarLion's Avatar
    Join Date
    Feb 2006
    Location
    Atlanta, GA, USA
    Posts
    3,748
    Mentioned
    69 Post(s)
    Tagged
    0 Thread(s)
    Strictly speaking, input elements would be things contained within/defined by <input> tags. TextAreas and Select Boxes would be excluded from this definition.

  8. #8
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by StarLion View Post
    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"

  9. #9
    Keeper of the SFL StarLion's Avatar
    Join Date
    Feb 2006
    Location
    Atlanta, GA, USA
    Posts
    3,748
    Mentioned
    69 Post(s)
    Tagged
    0 Thread(s)
    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.

  10. #10
    SitePoint Evangelist TomTees's Avatar
    Join Date
    Apr 2010
    Location
    Iowa
    Posts
    553
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well this is what W3C says...
    HTML 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.
    http://www.w3schools.com/html/html_forms.asp


    TomTees

  11. #11
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  12. #12
    Keeper of the SFL StarLion's Avatar
    Join Date
    Feb 2006
    Location
    Atlanta, GA, USA
    Posts
    3,748
    Mentioned
    69 Post(s)
    Tagged
    0 Thread(s)
    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.

  13. #13
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    and there is nothing wrong with "form fields" just like there is nothing wrong with "form controls".

  14. #14
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    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.

  15. #15
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,272
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    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.

  16. #16
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by xhtmlcoder View Post
    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.
    Imho the w3schools website, although not affiliated with the W3C, is a very good resource for anyone learning html, php and javascript.

  17. #17
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    Probably the writing style is good but it is riddled with inaccurate information.

  18. #18
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  19. #19
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    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.

  20. #20
    SitePoint Evangelist TomTees's Avatar
    Join Date
    Apr 2010
    Location
    Iowa
    Posts
    553
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  21. #21
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by xhtmlcoder View Post
    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.
    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.

  22. #22
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,272
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    <labels> are not compulsory. I don't always use them with <input> and my markup still passes as xhtml strict.
    Neither are <h1>header text</h1> in place of
    <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 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 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 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.

  23. #23
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  24. #24
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,272
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    It's all well and good to have WCAG but at the end of the day they are guidelines and not enforceable onto everybody.
    Same goes for strict validation. W3C are also but guidelines.

    f a web page passes the w3c validator as xhtml strict, then my job is done.
    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.

  25. #25
    Non-Member Kalon's Avatar
    Join Date
    Aug 2010
    Location
    At my computer
    Posts
    2,012
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Same goes for strict validation. W3C are also but guidelines.
    .
    yes totally agree, but I choose to code in xhtml.

    Quote Originally Posted by Stomme poes View Post
    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.
    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.


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
  •