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

[Malcolm Rowe]

Jim Ley writes:
>> I know you're working up to a 'snapshot' release soon (how does that
>> differ from a 'working draft', btw?), and so presumably you want to
>> keep the draft fairly stable for the moment, 
> That seems somewhat premature, we've only been commenting on this one
> for a few days, and there's lots of issues to be addressed [...]

I may be mistaken here. Ian's original announcement suggested that a 
'snapshot' would be released shortly, IIRC. I assumed that that was the same 
as 'a stable draft', marked as such, but it's entirely possible that he was 
referring to the version that's now up at whatwg.org. 

>> [select editable] 
> I think on many of these people have been looking the wrong way around
> - "We want this feature, this is some markup for it, how do we make it
> degrade"

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?" 

> Let's look how we do a select editable control in current HTML: 
> 
> <fieldset>
> Enter <input type="text"> or Select
>  <select/>
> </fieldset>

Strictly speaking, that's not an editable select, but a textbox followed by 
a select. I get your point, though: that's probably the closest we can get 
at the moment. 

> That only does select single, not multiple [...]

... as do the ones in the current Web Forms draft, and the one in my 
proposal. I don't think that anyone is really proposing functionality to 
support <select editable multiple> at this stage; it would seem to be a 
solution looking for a use case. 

> [...] but it's a hell of a lot
> better than the javascript approach of the select single in the spec
> (which is not WCAG 1 compatible failing the not pop up windows, or
> WCAG 2.0's don't move focus)

Ok, it's 'better' because it's supported by old clients, but it's not 
'better' in providing any richer controls, which is really the secondary 
goal for Web Forms 2, as I see it. If we were discussing how to do it in 
HTML4 forms, I'd agree with you. 

> how would we do select multiple, well [...]
> [select multiple editable example snipped]

> javascript is not a solution to legacy support, there's too many
> javascript incapable clients out there, too many differences in those
> UA's even when script is available (and whilst there are some
> incredibly capable scripters on this list, they're not perfect and I
> doubt they really have the resources available to support all the
> clients without letting some degrade)

I think that, while JavaScript is not a magic wand that we can wave at all 
the 'legacy' clients (for the reasons you mention), we probably should not 
constrain the WF2 spec to the subset of features supportable in a 
non-JS-supporting HTML4-forms-compliant UA. 

For example: the 'pattern' attribute for <input>. An author using 'pattern' 
should be aware that a UA might not support this functionality. If they also 
use a script for IE6 that allows it to support 'pattern' (for example), 
that's ok, but in the meantime, I can still use lynx if I want, just without 
client-side validation. 

[The one thing I'm not sure about is the replication concept. That seems 
like quite a large chunk of functionality that lynx couldn't ever use 
(substitute 'lynx' for WebTV or whatever if you like). I'm also not sure 
about the use-case for it, but that's something for a separate discussion.] 

> I think the above approach is similar to your proposal with fewer of
> the disadvantages (but maybe a whole load more)

Your approach is 'use HTML4 forms for this functionality', if I understand 
correctly. Are you suggesting that you don't think there's a requirement for 
a single control that allows generic input with a list of suggested values, 
or are you saying that you don't think it can reasonably be implemented in a 
backward-compatible way, and so we shouldn't include it in WF2? (or both, or 
neither) 

[Note that we do have such a 'control' is most modern GUI browsers already: 
the forms-based autocomplete 'suggestion' lists.] 

Regards,
Malcolm