Replace the definition list in forms with the <p> element

Help / Discuss
,
1

Dear XWiki people,
Although form elements technically need to be contained within a block element, the choice of a definition list is in my opinion the most unfortunate choice of all the block level elements out there.

Firstly because at this moment, the <LABEL> element and the <INPUT>, <SELECT> or <TEXTAREA> element are locked up in their own container, located on the same hierarchical level. This makes it harder for developers to freely customize the design of forms with CSS.

Furthermore, this is not according to W3C specification:

To associate a label with another control implicitly, the control element must be within the contents of the LABEL element. In this case, the LABEL may only contain one control element. The label itself may be positioned before or after the associated control.

Secondly, because the content of a form is very far distanced from being a definition list.

I propose to replace the definition list with <P> elements, which is also the typical way of doing things according to W3C (Forms: Writing a form’s user interface).

So we go from the old situation:

<form>
  <dl>
    <dt>
      <label>name</label>
    </dt>
    <dd>
      <input>
    </dd>
  </dl>
</form>

To the new situation:

<form>
  <p>
    <label>name
      <input>
    </label>
  </p>
</form>

All in favor of this superb proposition?

2

Hi!

Do you have an example of a customization you had trouble with?
IMO it’s nice because you can quickly split the labels from the inputs in your style (without relying on a class). It seems to me that if we use <p> we’ll need to introduce new classes to make some of the styles work.

Read again, this is a description for implicit labelling of input, which is not the only way to label an input :wink:
In xwiki forms, we use explicit labelling with the for attribute. If not, it’s in a ticket and is planned to get fixed because it reports violations in our automatic WCAG tests :slight_smile: E.g. Loading...

The DL here is not necessary for the input semantics, but AFAIK it doesn’t hurt to have it in addition to the standard label association.

The element encloses a list of groups of terms (specified using the <dt> element) and descriptions (provided by <dd> elements). Common uses for this element are to implement a glossary or to display metadata (a list of key-value pairs).

from <dl>: The Description List element - HTML: HyperText Markup Language | MDN

IMO our use matches pretty well the list of key-value example.

The dl element represents an association list consisting of zero or more name-value groups (a description list). A name-value group consists of one or more names (dt elements, possibly as children of a div element child) followed by one or more values (dd elements, possibly as children of a div element child), ignoring any nodes other than dt and dd element children, and dt and dd elements that are children of div element children. Within a single dl element, there should not be more than one dt element for each name.

from HTML Standard

IMO the xwiki forms are pretty much just a bunch of name-value groups. You could argue that it’s a bit more than that because there’s usually hints with the names.

For now I’m -1 overall, it would also probably break a bunch of stuff so I don’t think it’s something we should do without a very good reason.

Thank you for making a proposal though!

Lucas C.

3

I don’t think this proposal is a question of choice for XWiki. I think it is something that needs to be done to streamline the HTML with about every other webform available. If it is done as specified in whatwg, developers around the world are more eager to invest their time in XWiki. This so they can make their own design. Now they back off when seeing the ‘exotic’ style of HTML structure in forms. It’s a big task to go around it in the registration page, the user profile, login, not even speaking of all the rest that is in the background (for ‘simple’ users that don’t want to see the XObjects, XClasses etc).

Don’t get me wrong, I speak from my experience with XWiki and this was among the things that drove me up the wall the most. So I went investing my time in WordPress instead. After a few years I came back to XWiki to give it another go. At the moment I am kicking out the XWiki form style that is visible to users to replace it with something I dare to present my users. I am doing the task so I solved it. But I am not your avarage webmonkey.

Being different than anyone else in the world can be positive, in the case of HTML structure of forms it only works to your disadvantage. No matter how hard you try to explain that it is all OK, it really is not. A definition comes from the literary world, so it’s a completely different creature. Literally a definition means, and I quote, “a statement that explains the meaning of a word or phrase.” Trust me on this, the difference may be subtle on a technical level but semantically it’s absolutely out of it’s element here (no pun intended). If you want XWiki to succeed further, you need to conform (which on a personal level I will never do :wink: ).

I hope to see a future where XWiki is adjustable on every level, to the degree that there is hardly a similarity between different designs on the world. Like a chameleon :slight_smile: