[whatwg] Suggested changes to Web Forms 2.0, 2004-07-01 working draft

[fantasai]

Matthew Thomas wrote:


>> ...
>> date
>> ...
>> User agents are expected to show an appropriate widget,  such as a  
>> calendar.
> 
> 
> 29. Suggestion: Don't give UA implementors bad ideas. :-)
>     The most efficient method of entering a date with the
>     keyboard is with a datepicker (a multi-part text field
>     with increment+decrement buttons), not with a calendar.
>     This would also be easier to implement, more consistent
>     with the other date/time controls, and more compact
>     (reducing scrolling to get to other controls), than a
>     calendar would be. Even for a pointing device, the most
>     efficient interface (at least for choosing any date not
>     in the current month) would involve menus opened from
>     each segment of the datepicker (one-dimensional menus
>     for year and month, and a two-dimensional menu for day),
>     rather than using a calendar.
>     *   "calendar" --> "datepicker"

That's only if you know exactly which date you want to pick.
Works well for date-of-birth, but not for appointments. If I'm
setting up an appointment or picking a date for flying out of
the country, I'd rather see a calendar with the weekdays lined
up in a grid.

So, ideally, I'd have a datepicker like that given in
   http://www.whatwg.org/specs/web-forms/current-work/sample-datetime-ui-1
combined with a button on the side that pops up a calendar like
the one on http://continental.com/

> 45. Suggestion: Follow this by specifying robust error-
>     -handling for when people stuff up specifying an accept
>     attribute.
>     *   'If an upload control or a form element has an
>         invalid accept attribute, the value is assumed to be
>         "*/*". Such an attribute for a file upload control
>         still overrides any accept attribute for the
>         relevant form element.'
>     (Why? Because the faulty value is much more likely to be
>     the author's attempt at a non-specialization exception
>     to the form's rule, than an attempt at a specialization.

I'd rather see the thing ignored, which is the usual way of
handling errors like this.

>> ...
>> 2.7. Extensions to the  submit buttons
>> ...
>> If a submit button is activated, then the submission uses the values  
>> as  given by the button that caused the activation, with missing  
>> attributes  having their values taken from the equivalent attributes  
>> on the relevant  form element, if any.
> 
> 46. Suggestion: Split the sentence for readability.
>     *   "activation, with missing attributes having their
>         values taken" --> "activation. Missing attributes
>         take their values"

"Missing attributes take their values taken from the equivalent attributes
  on the relevant form element, if any."

This sentence seems to say that when a submit button is activated,
if it is missing attributes, they are /added/ to the submit button
with the values taken from the form -- so if I call GetAttributeWhatever
for 'enctype' on the button and it didn't have it before activation,
it has it now.

>> 2.13.  The autofocus attribute
>> ...
>> UAs may ignore this attribute if the user has indicated (for example,  
>> by starting to type in a form control) that he does not wish focus to  
>> be changed.
> 
> 58. Suggestion: Insist on this, as it is a security
>     vulnerability. (Several times I have accidentally typed
>     a password into a username field because the browser had
>     returned focus to it just after I had focused the
>     password field.)
>     *   "may" --> "must"

Since figuring out if the user does not wish focus to be changed
is rather subjective, this requirement should be a "should", not
a "must".

> 63. Suggestion: Maybe I'm just getting old-fashioned, but I
>     remember not so long ago "construct" wasn't a noun.
>     *   "an invalid construct" --> "invalid nesting"

http://dictionary.reference.com/search?q=construct

~fantasai

-- 
http://fantasai.inkedblade.net/contact