[whatwg] <input type="text" accept="">
Alexey Feldgendler
alexey at feldgendler.ru
Sun Jun 11 04:52:42 PDT 2006
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
More information about the whatwg
mailing list