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

[Malcolm Rowe]

Jim Ley writes:
>> [usability of form controls]
> No, that was a seperate concern.  Have people looked at the usability
> of different controls? - web pages have a certain paradigm that
> everyone understands currently, richer control types could've been
> introduced before, but now we have huge inertia in the existing types,
> is there good metrics showing that there's an improvement in these
> areas?

Okay, very good point. At the moment, the focus is on providing more 
semantically-aware controls. I believe that the assumption/hope is that UA 
authors will use these to provide more usable controls to their users. As 
far as I know, though, no-one has looked into whether providing 
semantically-aware (i.e., 'strongly-typed') controls has any usability 
implications *per se*, i.e., whether this is of benefit to users 
(intuitively, I'd say 'yes', but my only evidence is the proliferation of 
client-side validation in other applications, or via script on the web). 

>> [designers should developed flowed designs]
> Which they're more than happy with, the problem is more getting
> something they don't expect, designers are still able to design with
> the constraints you suggest (if they weren't they would all be using
> SWF right now) the constraints are just different, the brief chat I
> had with mine had a certain alarm about the idea of not being able to
> tell at all if it was a box or a slider, or if all of a sudden a huge
> calendar chooser would appear where he was expecting a few boxes.  It
> was only a brief chat of course.

And like I said, while that might be possible in theory, it's no different 
to the current situation, where a designer can't (in theory) predict what a 
file upload control will look like. In practice, I wouldn't expect this to 
be a problem, as most controls will, in all likelihood, be implemented as 
thin, rectangular boxes, just like the current input controls are. 

>> >> [over-validation, email / tel]
>> > The email format is very complicated, would you really want the full
>> > email format, comments and all being able to come back to your server?
>> No, because the current spec deliberately excludes comments.
> So it needs to clarify what it does allow, rather than just citing an
> RFC which does allow them.

"email. An e-mail address, based on the definitions in [RFC2822] 
(specifically the addr-spec token, defined in RFC2822 section 3.4.1, 
excluding the CFWS subtoken everywhere and the FWS subtoken everywhere 
except in the quoted-string subtoken)."
 -- http://whatwg.org/specs/web-forms/current-work/#email 

Isn't that sufficient? I agree that we don't want comments in email 
addresses, and made exactly the same point in December/January (see 
www-archive). I thought that the current wording was pretty much ok. 

>> [UA's may screw up validation, making it unusable]
> No, my problem isn't with email validation so much, I doubt most
> clients would actually do much email validation, the problems I
> envisage are more likely in the RegExp engine say - pattern if the
> RegExp engine is wrong (and I doubt there'll be a test suite cover all
> of it as part of thw WF2 spec) if they disagree what can we do?  (as a
> note the Mozilla JavaScript 1.5 RegExp engine differs from the
> ECMAScript Ed.3 and JScript's correct impl. so I don't think we can
> actually have any faith in them being the same.  That isn't a serious
> difference though, but what happens if it is?)

 From my point-of-view, non-conforming is still non-conforming. I suspect 
that we *will* actually have a test suite that provides at least moderate 
coverage of the 'pattern' attribute's functionality, given Ian's past 
history with the CSS specs. 

(Have you raised a bug in bugzilla about the JS differences, or are they 
deliberate differences? If not, could you do so, or let me know what they 
are, and I'll do it on your behalf.) 

>> "Scripted validation is dangerous - it has to be implemented correctly.
>> At least with declarative validation, the UA can provide a 'no submit it
>> really' option in a dialog."
> Great, so this is a proposal for the spec then - Hixie can you include?
> WF2 UA's must provide the ability for Users to submit forms without
> client-side validation.

Well, I'm not sure if I'd support it as a MUST/SHOULD recommendation - I 
just rewrote what you'd put to indicate that a UA could ('MAY') provide such 
a dialog. But it's worth considering. 

>> How many of those 'broken' email validation scripts provide a 'just do
>> it' option?
> All of the client-side ones! by virtue of them being implemented in
> script (I can just disable it :-)

Darn. That's cheating, but I guess you're right :) 

>> [jim's email address is disliked by scripts]
>> Stupid scripts. If the validation was declarative, it'd be much more
>> likely to be correct. :-)
> I don't really see how, in the end the blokey will be putting the same
> regexp in the pattern element as they were in the RegExp test.

Agreed that it's the same test, but simply because of the number of times 
the test has to be recreated (script vs. UA), the UA tests are likely to be 
more correct than a script-based test. 

If the probability of 'getting it right' is x%, with a script-based test, 
it'll be right for x% of sites, while with a UA-based test, it'll either be 
right or wrong for all sites, including sites that have yet to be written. I 
agree that the initial UA implementation only has the same chance to be 
'correct' -- x%, but it's a *lot* easier to fix a broken UA than it is to 
update scripts on all broken sites. This is just centralising logic, which 
declarative programming is perfect for (script-based validation is much more 
flexible; the other side of the coin, of course). 

Regards,
Malcolm