[whatwg] Re: Web Forms 2: Altenative to <select editable>
malcolm-what at farside.org.uk
Tue Jun 15 06:38:44 PDT 2004
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
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:
> Enter <input type="text"> or Select
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
> (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]
> 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)
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
[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
[Note that we do have such a 'control' is most modern GUI browsers already:
the forms-based autocomplete 'suggestion' lists.]
More information about the whatwg