- From: Malcolm Rowe <malcolm-what@farside.org.uk>
- Date: Tue, 15 Jun 2004 14:38:44 +0100
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
Received on Tuesday, 15 June 2004 06:38:44 UTC