- From: Malcolm Rowe <malcolm-what@farside.org.uk>
- Date: Tue, 15 Jun 2004 18:39:26 +0100
Jim Ley writes: >> The benefit is twofold: immediate feedback, > Everyone does that with script today, there's no problems with this > from a functionality perspective. Declarative beats programmatic, for repetitive tasks. Feedback can be presented in a consistent way (I've seen some scripts that actively prevent non-numerics in a textbox, some that pop up dialog boxes when you move off the field, and some that pop up dialog boxes on submission), it's less code to write, and you're less likely to make mistakes. >> maybe a spin-control or similar. > Have you looked at the usability? Yes. In fact, the ability of the UA to render a control that's easier to use or more appropriate for the device is one of the primary advantages of the way WF2 is specified. For example, if I'm on a hand-held device, an input field could support a thumb-control as a spin-control to set a number. > 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 :-). Authors do not *currently* have any guarantee that form controls have any particular look and feel de jure, only the de facto implementation provided by two or three UAs. > - if this genuinely was an > option, then I think we'd need to have a whole CSS vocab as well to > style it. I believe that there is supposed to be a spec that will cover CSS styling of form controls, but it's not Web Forms 2. I can't remember which one it is, though. > 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. Do the same designers get scared by users who can resize text? Joking aside, in reality, I'd imagine that if a UA decided to use spin-controls for numeric input [by which I mean a textbox with an up-and-down-arrow control on the side, just so we're sure we're talking about the same thing], the UA author would probably make sure that the control was the same size as a standard textbox. Likewise, it's unlikely that a UA would ever choose the 'large-size' calendar control shown in the current draft. However, the spec *does not mandate* a visual representation (and in fact, it can't, since the same stuff could be used for an audio browser). >> [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. > I've not seen an email validator in many serverside languages that > manages the full email grammar from the RFC. Fine - but this is a quality of implementation issue. If the spec is to support email types, it has to mandate something, and what it's currently asking for is sensible, I think. At the end of the day, it's a trade-off between the added usability benefits of an email type (presenting choices from an address book, perhaps), and the difficultly of supporting it properly in a UA. I don't believe that the spec is being written in the absence of comment from UA authors, so there's a reasonable supposition from the appropriate people that what's being asked for is deliverable, at least. > the tel: definition in > the spec is full of problems I believe - users just don't know their > global format, and the UA doesn't have enough knowledge to convert > from local to global (see other post on this subject). I don't have the expertise to evaluate this. However, if the 'tel' format does turn out to have problems that would make it either hard to use or to implement, I'll be quite happy to agree that we should drop it from the spec. Unlike 'email', the use-case and benefits aren't as great. > In a declaritive format, if enough shipped UA's get something wrong, > it renders the whole thing useless to users - if Opera mistakenly > rejects valid email addresses in their <input type="email"> - I can't > use that input control at all in my pages. 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. Unless you believe that email validation is *so* hard that it would be practically impossible to get compliant and interoperable implementations? (and if so, it would be dropped from the spec automatically anyway). > Declaritive validation is dangerous - it has to be implemented correctly. > (at least script > validation the user can disable script, or we can provide a "no submit > it really" method in our scripts) "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." How many of those 'broken' email validation scripts provide a 'just do it' option? With programmatic validation, you need to make sure that every one of those scripts is correct, whereas with declarative validation, you need to make sure that every UA is correct. Number of UAs <<< Number of scripts. > 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. :-) Regards, Malcolm
Received on Tuesday, 15 June 2004 10:39:26 UTC