[whatwg] Re: Web Forms 2: Altenative to <select editable>
malcolm-what at farside.org.uk
Tue Jun 22 09:27:16 PDT 2004
Ian Hickson writes:
>> I know you're working up to a 'snapshot' release soon (how does that
>> differ from a 'working draft', btw?)
> By "snapshot" I mean a copy on the Web site that doesn't change as I edit
> it. It is equivalent to what W3C people know of as a Working Draft. The
> "current-work" URI is the "internal" copy that represents work progressing
> on to the next snapshot.
Ok. I know you know what a Working Draft is, so I was wondering whether the
different terminology meant something else.
>> Add the 'data' attribute (maybe under a different name --
>> 'autocompletedata'?) from the <select> element (section 6) to the
>> <input> element. [...]
>> * We'd need somewhere to put the <option> elements in the DOM, and it's
>> not clear where that would be.
> As children?
.. of an <input> element? I suppose so; I had just assumed that that would
be invalid, because it is now, but there's no reason that we can't say that
you can have <option> as children of <input>. After all, it's only relevant
for WF2-compliant browsers.
One disadvantage: people would naturally want to put inline <option>
children straight into the document, and that's not very sensible (it won't
degrade). Would you permit that anyway, but suggest that people not do it
for documents intended to be consumed by HTML4 UA's? (shades of XHTML
appendix C). You couldn't prohibit it, since that would mean that the DOM
could legitimately contain something that wasn't valid in a source document,
which I imagine would break DOM Load&Save, if nothing else.
>> inline in a delimited attribute (autocompletevalues="foo;bar;baz").
> That's less good, IMHO.
Very much so. I agree. I only put it in because it's the 'obvious' solution
to including inline 'hints'.
More information about the whatwg