[whatwg] Re: Web Forms 2: Altenative to <select editable>
malcolm-what at farside.org.uk
Tue Jun 15 10:39:26 PDT 2004
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,
> 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. :-)
More information about the whatwg