- From: Jim Ley <jim.ley@gmail.com>
- Date: Wed, 16 Jun 2004 09:56:36 +0100
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.
Received on Wednesday, 16 June 2004 01:56:36 UTC