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

[Matthew Thomas]

On 7 Jul, 2004, at 1:30 PM, Ian Hickson wrote:
> ...
> Editorial comments that I disagreed with were ignored without further  
> comment. (In general I prefer not to make editorial changes,  
> especially to normative parts of the spec, because in my experience  
> "harmless" editorial
> changes have a habbit of breaking things without anyone noticing.)

Fair enough, but as you yourself said, "Readability is, IMHO, very  
important". :-)

> ...
>>> *   Ease of authoring for authors with limited knowledge
>>>     about XML, data models, etc, but familiar with
>>>     commonly used languages such as HTML and ECMAScript.
>>
>> 5.  Error: Mismatched tense. Either:
>>      *   "with limited" --> "who have limited" and
>>          "but familiar" --> "but who are familiar"
>>      *   "familiar with" --> "good knowledge of"
>
> Disagree.

To me it expands as:
>
> (1	) authors with limited knowledge about XML ...
> but who are also
> (2) authors with familiar with commonly used languages ...
>
and the latter doesn't make sense. But I can't explain why "with"  
attaches itself to "authors" so tightly. Oh well.

> ...
>>> For instance, visual UAs may use a track bar control.
>>
>> 33. Suggestion: Use more standard terminology.
>>      *   "track bar" --> "slider"
>
> "track bar" is the control's name in the Win32 API. I'm not sure you  
> can get much more standard.

Mac OS, Qt, and WxWindows use "slider". (GTK+ uses "scale".) And even  
for Win32 programmers, even allowing for varying spacing, it seems  
"slider" is *much* more common, API be damned.  
<http://www.googlefight.com/cgi-bin/compare.pl? 
q1=win32+%28%22track+bar%22+OR+trackbar%29&q2=win32+slider&langue=us>

> ...
> [default for time/date fields discussed elsewhere]

> ...
>> 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'm not convinced of your reasoning.
>
>    <form ... accept="image/*">
>     ... <input type="file" ... accept="image/png">
>     ... <input type="file" ... accept="image/gif">
>     ... <input type="file" ... accept="image\tiff">
>    </form>
>
> Do we really want to say that that last input control accepts  
> audio/aiff?

No, but your example is extremely unrealistic in two ways.

Firstly, it's a very unlikely use case. Actually, I can't even think of  
*any* case where you'd want to upload three image files in three  
different and specific formats. (Even if they were the same picture,  
why not just upload the single most faithful format and get the server  
to produce the others? That'd be quicker, more accessible, and produce  
more reliable results than making users do their own conversions.)

More common will be things like an auction site that accepts several  
image/* pictures of something being auctioned, along with a text\html  
(oops!) description of the item. Or an audio archive site that accepts  
several audio/* files, along with a text?plain (oops!) transcript.

Secondly, authors will aim to minimize effort on their part. So unless  
all the file upload controls in a form accept exactly the same MIME  
types, authors will not bother to use the form's "accept" attribute to  
specify the greatest common factor, as your example suggests they will.  
There would no point in doing that anyway, since there will be no UAs  
that implement "accept" for form elements but not for individual upload  
controls.

Instead, authors will use the form's "accept" attribute to specify  
whichever type they want accepted by more of the controls than any  
other type. Then they'll specify "accept" attributes for the upload  
controls that are exceptions to the rule, overriding that global type.

If authors make syntax errors with those exceptions, my proposed  
behavior will still allow people to use the form as intended, whereas  
deferring to the form's "accept" attribute usually will not.

> Also, I really like the consistency of saying invalid attributes are  
> always ignored.

Yeah, it's unfortunate that doing that would be more likely to make the  
form unusable in this case. Still, the implementation effort required  
to treat invalid values as "*/*" should be pretty tiny.

> ...
>> 47. Question: If the disabled attribute can be applied to
>>     <fieldset> elements, why can't it be applied to
>>     <form> elements too?
>
> Because nobody suggested it.
>
> Do we really want that? It doesn't seem that useful. What's the use  
> case?

I don't know. :-) I just don't want to see people putting a cluttersome  
<fieldset> around a form just so they can disable it. (Sure they could  
style the <fieldset> borders etc invisible, but they probably won't  
bother.)

> ...
>>         or if form submission is attempted while the
>>         field is invalid, a visual UA may highlight the
>>         field in some way.[2]
>
>>     [2] Why not display the error as soon as focus leaves
>>         the field? Because I may be temporarily focusing
>>         somewhere else to copy (or refer to) text to put
>>         in the field.
>
> The error handling behaviour is described later. The highlighting  
> would only be compliant if the UA had an equivalent rule using  
> ':invalid' in its UA stylesheet. Both of these are possible but not  
> specifically related to
> the pattern attribute.

Perhaps I'm misunderstanding, but why not? Why shouldn't a field where  
the value entered doesn't match its pattern cause the UA to complain in  
exactly the same way as a field which is invalid any other way?

> ...
>>> For option and optgroup elements that are  not inside select elements
>>>     The elements should be treated much like span
>>>     elements as far as rendering goes.
>>
>> 69. Suggestion: Remove redundancy.
>>      *   "as far as rendering goes" --> ""
>
> That's not redundant.

Okay, how about: "These elements should be rendered much the same as  
_span_."

> ...
>> 73. Suggestion: Encourage more standard text for such
>>      buttons.
>>      *   "Add Row" --> "+" throughout the spec (or at
>>          least everywhere except section 3.1.1, where
>>          more specific text may be educative)
>
> That seems like it would be very bad for accessibility.
> ...
>>      *   "Remove Row" --> "–" throughout the spec
>>          (or at least everywhere except section 3.1.1,
>>          where more specific text may be educative)
>
> That seems like it would be even worse.

True. In the real world I'd use <abbr title="Add a row">+</abbr> and  
<abbr title="Delete this row">–</abbr>. (I already use ABBR this  
way around ← and → on my Web site, for example.) But I  
suppose that would be too complicated for a spec example.

> ...
>>> If the form data set contains characters that are outside the  
>>> submission character set, the user agent should inform the user that  
>>> his submission will be changed;
>>
>> 95. Question: Should the UA do that even if the only such
>>     characters came from <input type="hidden"> controls?
>>     If so, for what purpose?
>
> A good point. The data is getting corrupted, so I think the UA should  
> inform the user of something. But what, I don't know.

Well there's really *nothing* the user can do to correct such an error,  
short of hacking the source code and making their own version of the  
page. So it's roughly equivalent to a script error. So probably the  
most appropriate notification would be the same as the UA uses for a  
script error -- e.g. a message in the status bar.

/!\ This form contains errors and cannot be sent properly

> I added a paragraph to the end of the section, but it is a bit vague.

And it's in the wrong place (it should be immediately following the  
diagram), and it contains a stray "take".

How about:
>
> If the form data set contains characters that are outside the  
> submission character set, the UA should inform the user that his  
> submission will be changed. For example, if the user entered "Asbj
örn  
> meget vær så snill og møtes De." in a text field, but the author  
> specified a character set in which the "ö", "æ", "å", and "ø"  
> characters cannot be represented, a UA might alert the user like this:
>  _____________________________________________________
> |:::::::::::::::::::::::::::::::::::::::::::::::::::::|
> |                                                     |
> | Some characters you entered (including "ö", "æ",    |
> | and "å") cannot be understood by this Web site. If  |
> | you continue, the characters will be changed.       |
> |                                                     |
> |                           ( Cancel ) (( Continue )) |
> |_____________________________________________________|
>
> UAs should not require such confirmation for characters  in _hidden_  
> elements, as there is nothing the user can do to fix the problem.  
> However, a UA may display such an error in other ways (for example, in  
> a status bar).
>
> If the submission is not cancelled, the user agent must replace each  
> character that is not in the submission character set with one or more  
> replacement characters.
> ...

As an added bonus, the new example (I don't know Norwegian, so you may  
need one of your colleagues to refine it) helps demonstrate to  
implementors that:
*   asking for confirmation for every unacceptable character
     would not be reasonable
*   even listing every unacceptable character in a single
     alert wouldn't scale
*   displaying a complete conversion in an alert won't scale
     either (especially if the original is, for example, a
     multi-kilobyte Webmail message).

... Next question: What if the invalid characters are in <option>  
elements? There's pretty much nothing the user can do about that  
either.

I can see a slippery slope here -- UAs' character conversion algorithms  
may differ, but programmers may begin relying on the results of the  
algorithm used by the particular UA they test with. But confirmation  
alerts aren't a solution to that problem either. Maybe the only  
solution, short of specifying exhaustive (and exhausting) character  
conversion behavior, is specifying that UAs must pre-emptively disable  
forms where uneditable controls contain unsendable data.

-- 
Matthew Thomas
http://mpt.net.nz/