Looking for ways to display forms within HTML elements

[eluser]Xeoncross[/eluser]
[quote author="xwero" date="1221143544"]I think it's a misuse of the dl tag looking at the examples in the starter topic.[/quote]


It kind of is, a DL list is meant to have 1+ DT/DD elements in it. So IDEALLY it would be one DL with 2 or more DT/DD and not one DL for EACH DT/DD. But it still is technically correct and offers more than just a UL or styling a INPUT tag.

Each input needs to be styled. But you can't style an input and still position it correctly in all browsers - it needs something around it.

[eluser]beemr[/eluser]
Actually, a DL doesn't need to have more than one pair of DT/DD to be meaningful. The DL spec is very flexible, giving the affordance for a term pairing to include more than one definition or more than one term. eg.:

Code:

<dl>
<dt>Death</dt>
<dt>Taxes</dt>
<dd>Sure things in life.</dd>
<dd>Government services</dd>
</dl>

Think of it more as a UL with two ways of presenting its items. You could even argue that encasing each pairing in a DL is even more semantically meaningful, especially as far as DOM operations are concerned.

Consider the semantics of most forms. Aren't they just definition lists for which the user must provide the definitions?

[eluser]beemr[/eluser]
Just changed my definition list helper to reflect my last opinion.

Now a <dl> will contain only one dt/dd pairing. There can be multiple dt's or dd's, but the each definition group is its own <dl> inside of its own <li>. Like so:

Code:

<ol>
  <li>
    <dl>
      <dt>Death</dt>
      <dt>Taxes</dt>
      <dd>Sure things in life</dd>
      <dd>Government services</dd>
    </dl>
  </li>
  <li>
      etc...
</ol>

[eluser]Colin Williams[/eluser]
What you've done is, with the support of a flawed semantic argument, replaced superfluous DIV markup with superfluous DL, DT, DD, OL, UL, LI markup. Forms aren't "just definition lists for which the user must provide the definitions," unless of course the form is part of a dictionary creator.

When you ask a user for their username, you aren't asking them to define the term 'username.' You are asking them to provide or supply their username. Clear difference. This is why there is a LABEL element for form controls, not a TERM element.

Also, just because a form may be laid out and meant to be completed in a sequential matter does not necessarily make it an ordered list. I think the same thing holds true for unordered lists. Think about a list of paragraphs. You wouldn't mark that up as <ul><li><p/></li><li><p/></li></ul>, would you?

I don't think any of these methods are necessarily wrong or bad. The more hooks CSS has, the better. I just don't think there's a strong semantic argument for any of them.

The vagueness of the humble DIV element lets one create their own suitable semantic structure. Using meaningfully classed DIVs, in my opinion, is much better than stretching the definitions of other inadequate markup elements.

[eluser]Colin Williams[/eluser]

Also, why even add the div class?

There's a good reason to have an immediate DIV child for all FORM elements. All form controls must be a child of a block-level element WITHIN the parent FORM element. Most of the time this occurs naturally (typically fall within a DIV or FIELDSET) but there's often not a reason to put type="hidden" elements within any block-level parent. The immediate DIV eliminates this possible validation blunder.

[eluser]Nick Husher[/eluser]
+1 Colin Williams: Use DIV and SPAN tags rather than contort the semantic meanings of other tags. Use fieldsets to group semantically-similar fields, using nested fieldsets where appropriate.

It would be reasonable to have elements within an ordered list if you expect the form to be filled out in a set series of steps, although the case is less clear for an unordered list when you could use a semantically-neutral collection of div/span nodes.

[eluser]beemr[/eluser]
Obviously, this is a point of much debate and not just under this thread. Richard Rutter posted a great article about this some time ago. He is a well-recognized voice in Web Standards, and his argument suggests a semantic advantage to <dl> forms. Beyond that, however, I also suggest that there is an advantage to be gained in DOM-scripting and CSS, allowing for tag-level operations that can discern between the listed term and the listed definition. Listings under an OL or UL will need extra attributions in order to be collected into different groups, and that is a much less elegant solution overall.

As far as nested OL/DLs, I think anything that is sequential is most definitely an ordered list. An unordered list implies parallel priorities. Most forms have a definite sequence of priorities. A ZIP code field is useless unless it follows either the shipping or billing address fields, right?

[eluser]Colin Williams[/eluser]
Yes, beemr, they are sequential in a certain regard. However, just because the "Once upon a time" paragraph comes before the "frog turned into a prince" paragraph doesn't mean we load those paras up in an unordered list. You can argue that paragraphs are inherently sequential, but so can I equally argue that form controls are inherently sequential.

But, if you require the extra markup that DLs provide and using semantically meaningfully classed DIVs and SPANs is against your religion! by all means. I just don't agree with the use of DL in that context, regardless of how great Mr. Rutter's article is. (I'm being overly dramatic on purpose, by the way.)

[eluser]Xeoncross[/eluser]
There is one point that is missed by this valuable discussion - what if CSS isn't an option. DIV/SPAN tags ONLY work if you have CSS to style them.

The reason that I choose DL tags to begin with is that they work even without a CSS file to back them up. Also, as you pointed out, UL/OL don't provide enough elements for full display control, therefore extra span's/div's must be added so why even use UL/OL to begin with?

After searching the HTML elements I found that a fieldset/dl/dt/dd/label/input worked without CSS, with CSS, and almost matched the semantic meaning of the tags.

If someone knows of a element group that can top this - please let me know - that was the whole point of this post to begin with.

[eluser]Colin Williams[/eluser]

The reason that I choose DL tags to begin with is that they work even without a CSS file to back them up

What exactly do you mean that it "works?" You stated that a few times. If what you're saying is that it still looks distinct in the browser, I have a secret for you: Browsers have there own stylesheets.

Also, the fact that you said a DL-based structure "looks" better already hints that you are thinking of these elements visually and not semantically. You know what also "looks" better without CSS rules? Table-based layouts. Like I said earlier, you're just replacing one superfluous markup scheme with another. It may be less evil than tables, but that's not the argument anyone has made, and it would be a silly argument to make.