[whatwg] <input type="text" accept="">

On Fri, 09 Jun 2006 08:49:50 +0700, Ian Hickson <ian at hixie.ch> wrote:

> <input> already has 27 element-specific attributes, plus 5 global
> attributes, plus 1 deprecated attribute, plus an uncountable number of
> event handler attributes. Going the road of one-attribute-per-feature
> would escalate that even faster, especially given that these features
> don't affect anything other than the way the user interacts with the
> input field (i.e. they don't affect the actual allowed values, etc).

Maybe features like spellckeching, syntax highlighting and so on should be  
controlled via CSS? That way, they can be fine-tuned to any degree of  
precision without complicating the HTML schema. This will also reduce  
verbosity of <input> elements because they would otherwise have the same  
repeated attributes.
man
For example, a form can have several <input> elements with the same value  
of class attribute, and CSS can bind some behavior (e.g. no spellchecking,  
autoindent etc) to that class.

These CSS properties can also apply to any element, not just <input> --  
they matter when the elements are switched to contentEditable mode.

The lang attribute on <input> should still affect, e.g., the choice of  
spelling dictionary.

Information like "this input field should have autoindent" is  
presentational. Information like "this input field contains program code"  
is semantic, but unless we can derive and encode in HTML every possible  
semantic reasoning for a combination of <input> features, we'll have to  
give presentational information instead. And presentational information  
should belong to CSS, not HTML.


-- 
Alexey Feldgendler <alexey at feldgendler.ru>
[ICQ: 115226275] http://feldgendler.livejournal.com

Received on Sunday, 11 June 2006 04:52:42 UTC