4

There is a <fieldset> tag for a set of fields.

Why isn't there a hierarchical child for fieldsets?

<form>
    <fieldset>
        <legend>Thin Sandwich Options</legend>
        <field>
            <label>Meat</label>
            <div class='inputs'>
                <label>
                    <input type="radio" name="meat" value="turkey" />Turkey</label>
                <label>
                    <input type="radio" name="meat" value="monkey" />Monkey</label>
            </div>
            <div class='desc'>Pick one meat for the thin sandwich.</div>
        </field>
        <field>
            <label>Cheese</label>
            <div class='inputs'>
                <label>
                    <input type="checkbox" name="cheese" value="chedder" />Cheddar</label>
                <label>
                    <input type="checkbox" name="cheese" value="swiss" />Swiss</label>
            </div>
            <div class='desc'>Pick one meat for the thin sandwich.</div>
        </field>
    </fieldset>
    <fieldset>
        <legend>Beverage Options</legend>
        <field>
            <label for="carbonated">Carbonated</label>
            <div class='inputs'>
                <label>
                    <input type="radio" name="carbonated" value="coke" />Coke</label>
                <label>
                    <input type="radio" name="carbonated" value="mtn-dew" />Dew</label>
            </div>
            <div class='desc'>Pick one beverage per combo.</div>
        </field>
        <field>
            <label for="non-carbonated">Non Carbonated</label>
            <div class='inputs'>
                <label>
                    <input type="radio" name="non-carbonated" value="tea-sweet" />Tea (non sweetend)</label>
                <label>
                    <input type="radio" name="non-carbonated" value="tea" />Tea</label>
            </div>
        </field>
    </fieldset>
</form>

http://jsfiddle.net/5dC8c/

I keep coming back to this question whenever I am working on my HTML form layouts.

As MDN defines it:

The HTML <fieldset> element is used to group several controls as well as labels () within a web form.

I see a <field> element as grouping a single control (or set of radio buttons) with a single label and a description. The field tag would have some of the same attributes that the input tag has, readonly, required, etc.

Why does bootstrap use the class 'form-group'?

Why does Wufoo use li tags for each field?

Enclosing related form elements into fields would add clarity.

Every major front-end framework has some class or tag to differentiate each field.

Why the heck don't we have a single HTML tag to bring some normality to form design?

Update: added a better HTML example of the usage of a <field> tag.

4
  • 8
    Field makes sense to me. I feel like i always have a div named that. I disagree with the answers below. Field would not only hod the input. It would also hold the label, validator and whatever else a field needs
    – Andrey
    Apr 14, 2014 at 14:21
  • 1
    Thanks Audrey. I am glad someone understands what I am talking about. Apr 14, 2014 at 14:24
  • @iambriansreed Been coding for over 30 years now, doing HTML for over 15 and I still keep looking for some tag, any tag, better than div for this. It's just not there... But hey we have a strong tag so we can replace b with it. Thanks W3C, just what we needed. Jul 31, 2019 at 13:57
  • Seriously, its all meaningful names until you have to write <div class="field"><label...><input...></div> to create any sort of containing element for fields. IMO field would be semantically useful / natural. As to other people's arguments about "Why would you need this?", why do we need a main, header, or footer tag? It's readable and is about semantics. Sep 13, 2021 at 12:11

4 Answers 4

13

There is, it's called <input>.

The <input> tag came first. But then came the desire to group inputs (and typically the radio button variety in particular) into visually-distinct groups. Names like <inputgroup> or <inputset> just wouldn't fly. But <fieldset> sounds pretty good, so that's the name they used.

<input> wasn't renamed to <field> for consistency because that would break all sorts of stuff. And honestly is that sort of consistency really necessary? This is HTML, after all.

FWIW, <legend> was introduced at the same time to complete the visual experience. Combining the two allowed you to draw a box with a label around the form like this:

Glorious Fieldset

It's like Windows 95 all over again. This was a level of UI sophistication previously only available in such fine development environments as Visual Basic 5.0. Bringing that sort of design capability to HTML was a big deal.

2
  • 1
    Please read the updated question. Apr 14, 2014 at 20:57
  • 2
    input on it's own is useless. what are you inputting? You need to add a label... which means you now have 2 distinct elements for one control. And need to use the for attribute and an ugly id (ugly, because it has to be unique page-wide, which you cannot typically guarantee) to tie them together... Jul 31, 2019 at 14:00
4

Why does bootstrap use the class 'form-group'?

Why does Wufoo use li tags for each field?

The people you should be asking these questions are the authors of these frameworks.

Enclosing related form elements into fields would add clarity.

You can do this easily enough with the standard elements as they are now. A fieldset allows you to group multiple inputs. The label tag can be used to tie an input to its description.

Every major front-end framework has some class or tag to differentiate each field.

This is because each framework has a specific approach to styling these fields and no matter what standards you come up with, people will keep inventing their own ones... which leads us to the point...

Why the heck don't we have a single HTML tag to bring some normality to form design?

Because HTML tags are not about design. HTML is supposed to represent content, the structure of information and not how something looks. Apparently, the people responsible for the development of the standard consider the current state of the language sufficient in this matter. Web designers are given a lot of freedom as to how to style these elements with CSS as well as to use additional elements around them, which is exactly what you observed.

To sum up, design is not what the language is about. Semantics are the core of the specification. If you ever try to standardize designs, there's only one way this can turn out. Randall Munroe, the author of XKCD makes an excellent point about this phenomenon:

XKCD

3
  • Ugh. Design is a broad term. How do you mean it here, visual design, interface design, etc? There is more (can be more) to a field than simply it's input and title. By asking the first two questions I am stating a need for a standardized tag much the same way we have an article tag and section tag. Apr 14, 2014 at 20:00
  • @iambriansreed what I meant was visual design. I just don't see how what you're suggesting would improve the situation. Is there anything you could potentially do with a new field tag that you can't do with input, label and fieldset in terms of semantics? Apr 14, 2014 at 20:07
  • You can indeed wrap a fieldset inside a fieldset. This is prob my solution moving forward but it behooves the community to demand more focus on the framework for html forms. We got more input types with html5 but nothing more. Apr 14, 2014 at 20:51
0

It's an optional element to allow for grouping of form elements.

The form elements, such as input, exist outside of the fieldset, do wrapping them inside field tags when inside a fieldset is redundant.

0

The short answer is: because <field> would be redundant (or worse).

What would a "field" be in this context? Well, I would expect it to mean any form-associated element in the field set that potentially delivers input.

But the there is no need to designate these as "fields" because ... well ... we / the browser already know they are fields. Wrapping them in a <field> element achieves almost nothing1. From the perspective of someone reading / writing the HTML <field> would just be syntactic noise.


1 - I can see a small benefit for javascript (etc) code. A <field> element would make it simpler for javascript to query the DOM to find all designated fields in a fieldset ... or a form. But the flipside is that if <field> has a special meaning (e.g. to Javascript programs), then forgetting a <field> tag is a potential source of errors.

5
  • I answered you on how a <field> tag would be used. Apr 14, 2014 at 13:21
  • 1
    So it is actually a way to group an <input> with some markup. Why can't we just use (say) <div>? What would <field> add? What is the point of moving some of the <input> attributes to an enclosing element?
    – Stephen C
    Apr 14, 2014 at 14:59
  • Not grouping just some markup. Specific titles and descriptions related to the input. See my update. Apr 14, 2014 at 15:14
  • As far as I can see, this is just markup for the sake of it. You have not made a concrete case for why it is needed, or what it means. Saying "it adds clarity" is missing the point. Why is clarity needed? To what / who? And what exactly is it saying? Anyway, it is moot discussing it here. If you really want something to change, you need to talk to the HTML 5 specification team.
    – Stephen C
    Apr 18, 2014 at 1:53
  • In that case why do we need header, main, aside, or footer tags if they're all just divs? They're all optional but still useful when understanding the html structure itself. It would just serve as a convenient container for the 2 optional elements that are included for the input. Do you have 3 fields or label + input + label + input + label + input? And most people just wrap them in p tags anyways (because wrapping a paragraph tag around a label / input makes more sense... right?). It's a semantic container for input and label tags. Sep 13, 2021 at 12:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.