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

[Malcolm Rowe]

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