[whatwg] Form control consistency

[Ian Hickson]

On Wed, 20 Feb 2008, Markus Ernst wrote:
> 
> I suggest to change the point-of-view for future HTML versions. A 
> consistent structure could look somehow like the following:

Unfortunately since we have to be compatible with the legacy content and 
browsers, we are quite constrained in terms of what we can change.

Changing things for the benefit of a more consistent language doesn't 
really gain us enough to warrant the implementation cost. For example:


> - for a multiline text field, either a "multiline" attribute or a new
> "textarea" type is introduced
> - the textarea element gets deprecated

We can't ever obsolete <textarea> -- so deprecating it is pointless. All 
this would do is just introduce more redundancy.


> - also, a rich text editor could be introduced, either by a "richtext"
> attribute or a new "richtext" type (of course this would introduce new
> questions, such as, how to configure its toolbars...)

We have this with contentEditable. We can't really do more than that, 
since there is so much disparity in what people actually want from a rich 
text editor.


> - checkbox, radio, submit, reset, button, and image types get deprecated

How does this actually improve anything? We can't ever get rid of them, so 
why deprecate them?


> - introduce type attribute to determine appearance:
> type="menu" (default): display as today's select element
> type="boxes": display as group of check or radio boxes

This seems like something for CSS3 UI or XBL2.


> - the current option syntax gets deprecated; the label will be added 
> with the label tag rather than be included in the option tag
> 
> Examples:
> - default selectbox, as we know it
>   <select name="foo">
>     <option id="foo1" value="bar1"><label for="foo1">Bar 1</label>
>     <option id="foo2" value="bar2"><label for="foo2">Bar 2</label>
>     <option id="foo3" value="bar3"><label for="foo3">Bar 3</label>
>   </select>

This wouldn't be compatible with the HTML parsing rules.


> - the "checkbox" element gets no value attribute; the submitted value is 
> "1" when checked, "0" when not checked (this is actually the main reason 
> for introducing a new element - changing input type="checkbox" in this 
> manner would cause severe backwards compatibility problems in many 
> applications; one more reason for the new element is the problem of 
> styling the input element, where i.e. borders or dimensions usually do 
> not apply to checkboxes but only to text fields)
> 
> Example:
>   <checkbox id="chk1" name="confirm">
>   <label for="chk1">I have read and understood the general conditions</label>

Why is the current behavior a problem?


> - button type="image" is introduced in order to totally replace all 
> button functionalities of the input element

What problem does this solve? This seems to just introduce more 
inconsistency.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'