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

[Jim Ley]

On Tue, 15 Jun 2004 18:39:26 +0100, Malcolm Rowe
<malcolm-what at farside.org.uk> wrote:
> >                                    have you considered what an author
> > would want in this situation, all of a sudden a spin control appearing
> > where the design needed something different
> 
> Ah. Obviously this is a definition of 'usability' that I wasn't previously
> aware of :-). 

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?

> > My designers understand what an input box looks like, they
> > can allow for it in their designs, if it could be a spin/input/slider
> > etc. they'd be frightened at the lack of "control" all of a sudden.
> 
> Um, tough? Pixel-based design is out; flowing, user-controllable, semantic
> design is in. 

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.

> >> [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.

> Yes, agreed, but "if enough shipped UA's get something wrong, it renders the
> whole thing useless to users" is a valid sentence all by itself. 

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

> 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 :-)

> > It's the + in it that's the problem many people seem to think
> > jim+chickents at jibbering.com is invalid, I've no idea why.
> 
> 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.

Jim.