[whatwg] Re: Web Forms 2: Altenative to <select editable>

[Malcolm Rowe]

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'. 

Regards,
Malcolm