Re: Form "field" Elements

2014-06-10 20:42, Eric Devine wrote:
> +1
> <form>
>    <p>
>      <label>Name</label>
>      <input />
>    </p>
> </form>
> has always felt semantically awkward to me
>
In HTML5, the <p> element has been retrofitted to match such usage. But 
such usage was never necessary, or even a good idea. A <p> element by 
default causes empty lines before and after, so why would you use it 
when you don’t want that? And people mostly don’t want that in their forms.

To separate fields, you can use <br>, or you can wrap each field in a 
<div>, or make each field a row of a table. These practical approaches 
are frowned upon by specs-writers, but there is really no good alternative.

In that sense, <field> would be nice, if it were defined to logically 
group a label, an associated field, and possible additional content 
(such as an explanation or comment) and physically be formatted as a 
block element. But since no current browser supports the element, this 
would not be practical. In the long run, it might turn out to be useful.

However, HTML5 refers to controls rather than fields. A control need not 
be a field of a form, or associated with a form at all. It could be just 
part of a user interface to something driven by a client-side script. 
Hence <control> might be a more suitable name

I don’t think there would be many practical benefits. The element would 
be just a way to write “cleaner” HTML code (and even this might be 
debatable), without affecting the quality of the content, functionality, 
or services offered by HTML documents. But it would remove the awkward 
situation that HTML5 more or less recommends using <p> for 
controls/fields and explicitly suggests a certain default rendering for 
<p>, so that authors are effectively expected to use <p> instead of 
<div> but make <p> act like <div>.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

Received on Tuesday, 10 June 2014 18:45:19 UTC