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

[Ian Hickson]

On Thu, 8 Jul 2004, Matthew Thomas 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". :-)

Yeah; if the changes improve readability enough to warrant the risk, I'll
make the changes.


>>>> *   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 me it expands to:

 *   Ease of authoring for authors
      (a) with limited knowledge about XML, data
          models, etc,
     but
      (b) familiar with commonly used languages
          such as HTML and ECMAScript.

...which makes sense to me...


>>>> 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>

Okie dokie.


>>> 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.
> [...]
> 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.

Good point. Fixed.


> >> 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.)

I've never seen an entire form be disabled, and authors seem more
concerned with look than usability, so I doubt they'd forget to remove the
fieldset borders! :-) So I think we'll punt on this for now. Maybe a
feature for WF3 if there is a use case.


>>>         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?

Yes; what makes you think it shouldn't?


>>>> 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_."

That works.


>>>> 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.

Fair point. Added some text to that effect. Let me know if it's ok. (It's
similar to yours, but not quite the same.)


> As an added bonus, the new example (I don't know Norwegian, so you may
> need one of your colleagues to refine it)

Apparently it would have needed more that just refining, we couldn't work
out what you meant at all! :-)


> 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.

Been there, done that. Servers already rely on such characters being
converted to fake entities. (Try searching Google for "Ӓ".) This is
just trying to put an end to that. (Probably in vain, but one can hope.)


> 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.

| Users should not be exposed to authoring errors
|   Specifications must specify exact error recovery behaviour for each
| possible error scenario. Error handling should for the most part be
| defined in terms of graceful error recovery (as in CSS), rather than
| obvious and catastrophic failure (as in XML)."
 -- http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'