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

Hi Jim, 

[I assume the omission of the group in the cc: line was an accident rather 
than a wish to keep this private. If not, sorry!] 

Jim Ley writes:
>> I may be mistaken here. Ian's original announcement suggested that a
>> 'snapshot' would be released shortly, IIRC.
> I think you're right it did, I just think it's incredibly premature in
> light of the feedback he's since recieved and the ongoing discussion.

Ian can judge the degree of feedback he's received better than I can. I'll 
let him respond to this. 

>> With respect, I don't think that's how the discussion has been proceeding
>> over the last few months. I think it's been more like "We want this
>> feature.
>> How would we express it in markup so that it can still be used by older
>> clients, while allowing new clients to present a richer interface?"
> Yep, I understand the goals (the archives don't seem to be about
> though for these few months, could you point me at the discussion).

Prior to whatwg, discussions were carried out both in private email and IRC, 
and on www-archive. fwiw, all my comments are in the latter's archives, 
http://lists.w3.org/Archives/Public/www-archive/2003Dec/ et seq. Note that 
early versions of the draft were called 'XForms Basic'. 

I think the first public announcement was on Ian's blog, here:
http://ln.hixie.ch/?start=1070555652
but even then he mentions that he's been working 'for the past few months'. 

> Ah, I obviously wasn't clear in my example - the WF2 client would see the:
> <fieldset type=selectEditable> and use that for rendering the advanced
> control, discarding the inside which is for the legacy browsers.

Ah, ok. That wasn't actually in your original (select-single) example. I 
agree, that's another valid alternative. 

> [...] You still get the richer
> control, and you get the full fallback, the only cost is in the slight
> server work needed to deal with the split returned data across 2 form
> elements in the legacy client.

Well, I imagine the newer clients could just emulate the legacy clients in 
terms of form submission. That way, the server doesn't need to do anything 
(and it's not that bad an option, is it?). 

> We can't implement it in a backward compatible way without making
> allowances on the server I'm sure of that [...]

Sure we could. My proposal just added functionality to a generic <input> 
control. I'm not saying it's the best, but it doesn't need any server-side 
support. 

> Without [including] it I don't see much
> value in the spec at all, it's one of the few features in the spec of
> use to me, [...]

Well, from my point-of-view, I think I'd find the 'strongly-typed' input 
controls and validation enhancements the most useful, more so than the 
replication model, for example. 

> but if it can't be made to degrade then no I don't want it.
Agreed, especially since we can make it degrade (as you and I have just 
demonstrated). 

>> [Note that we do have such a 'control' is most modern GUI browsers
>> already: the forms-based autocomplete 'suggestion' lists.]
> Oh right, so what's the motivation for introducing a new one, if we
> already have it?

There's no way for a server to pre-populate such a list with suggestions, as 
it's purely a client-side thing at the moment (what you've typed before, on 
that client PC). 

I could imagine UAs merging 'their' autocomplete list with the 
server-provided autocomplete list, allowing the server some control over 
suggestions (the server may know more than the client, especially so in 
intranet applications). 

I can also imagine UAs rendering the control as a standard drop-down 
Windows-style combo-box, though, so it'd probably depend on the UA. 

Regards,
Malcolm

Received on Tuesday, 15 June 2004 07:48:18 UTC