W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2004

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

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 9 Jul 2004 15:20:08 +0000 (UTC)
Message-ID: <Pine.LNX.4.58.0407091405590.11240@dhalsim.dreamhost.com>
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,
      (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 "&#1234;".) 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.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 9 July 2004 08:20:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:35 UTC