- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Thu, 8 Jul 2004 19:31:58 +1200
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/
Received on Thursday, 8 July 2004 00:31:58 UTC