- From: Thomas Broyer <t.broyer@gmail.com>
- Date: Tue, 28 Oct 2008 20:13:51 +0100
On Tue, Oct 28, 2008 at 7:12 PM, Tab Atkins Jr. wrote:
> FWIW, I completely agree with Markus re: the semantic similarity between
> <select> <input radio> and <input checkbox>. In my own programming
> utilities I have a function which does exactly what Markus talks about; it
> takes an array of value/text pairs, a display specifier
> ("collapsed"/"expanded"), and a multiplicity specifier ("single/multiple")
> (also some arguments to specify @name and #id prefixes and such, but that's
> not relevant here). It uses this to transform the array into a <select>,
> <select multiple>, <input radio> group, or <input checkbox> group as
> necessary. This is very easy precisely because of the clear semantic
> mappings between the four types of input.
>
> I haven't given it serious thought, but as far as I can tell his proposed
> solution (piling all four display types onto the <select> tag) would work
> wonderfully as a semantic consolidation/simplification, and be nicely
> backwards-compatible. There are still good reasons to support keeping the
> <input> types of radio and checkboxes, of course (frex, wrapping a form
> around a list, and putting an <input> within each <li>), but this proposal
> would simplify the most common case.
That's what XForms more or less defines (it has select and select1
elements), and I'd say that you can use "XForms within XHTML" to
generate an HTML form ("Web Forms 2.0").
I suspect XForms might more limited wrt complex layouts, but I guess
the new CSS3 modules will help (when shipped and implemented).
--
Thomas Broyer
Received on Tuesday, 28 October 2008 12:13:51 UTC