- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 7 Jul 2004 01:30:29 +0000 (UTC)
Comments I agreed with were addressed without further comment.
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.)
Substantive comments that I disagreed with are discussed below.
Thanks for your input!
On Mon, 5 Jul 2004, Matthew Thomas wrote:
> >
> > ...
> > * 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.
> > * Basic data typing, providing new controls for commonly
> > used types so that authors do not need to repeatedly
> > design complicated widgets such as calendars.
>
> 6. Suggestion: Use more standard terminology.
> * "widgets" --> "controls" throughout the spec
> * "widget" --> "control" throughout the spec
Disagree. The words are used so often that I need some variety.
> > This specification aims to simplify the task of transforming XForms
> > 1.0 systems into documents that can be rendered on every day Web
> > browsers.
>
> 12. Error: "This specification" unavoidably refers to the
> specification mentioned two sentences previously, which
> is XForms 1.0, which is not what you mean.
> * "This specification" --> "Web Forms 2.0"
If you can find a way of phrasing that that doesn't require using the name
of the spec, that would be great. I'm trying to reduce the churn that I
will have to do if the spec changes name (again).
> > 1.5 Missing features
> > ...
> > * Elements or properties to create a "tabbed" or
> > "wizard" interface. This need will be addressed in a
> > separate specification.
>
> 15. Error: Tabbed interfaces and "wizard" interfaces are
> not, and have never been, the same or even related.
> * 'a "tabbed" or "wizard" interface. This need' -->
> 'tabbed interfaces or "wizard" interfaces. These
> needs'
Actually they very much are related from a structural point of view. Both
represents sets of sections only one of which can be visible at any one
time. But fair enough.
> > 1.6. Conformance requirements
> > ...
> > Implementations that do not support scripting (or which have their
> > scripting features disabled) are exempt from supporting the events and
> > DOM interfaces mentioned in this specification.
>
> 19. Suggestion: Use RFC 2119 terminology.
> * "are exempt from supporting" --> "may decline to
> support"
This isn't an appropriate point for RFC2119. They don't have a choice
about declining to support -- if they don't support scripting then there
is no way they _can_ support the DOM interfaces.
> > While user agents should support all possible values, there may be
> > implementation-specific limits.
>
> 21. Suggestion: Make the allowance more explicit.
> * "there may be implementation-specific limits." -->
> "they may impose limits if necessary."
Disagreed because this phraseology is pretty standard in specs.
> > The form element is therefore allowed in the head element of XHTML
> > documents, although only when the form element is empty.
>
> 23. Error: "Although" can only introduce a complete clause, ...
Disagreed.
> 24. Suggestion:
> http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/000875.html
Reply:
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/001003.html
> > A date and time (year, month, day, hour, minute,
> > second, fractions of a second) encoded according to
> > [ISO8601] with the time zone set to UTC
>
> 25. Suggestion: The [ISO8601] citation key is used as text
> here, but other citation keys are not, even to the
> extent of writing "the HTML4, XHTML1.1, DOM2 HTML, DOM3
> Core, and DOM3 Events specifications ([HTML4], [XHTML1],
> [DOM2HTML], [DOM3CORE], [DOM3EVENTS])". Pick a policy
> and stick with it.
Fixed to use the second where I saw it using the first.
> > All the numbers must be in base ten and zero-padded if necessary.
> > e.g.: 1995-12-31T23:59:59.99Z
>
> 27. Error: Capitalization. Either:
> * "necessary. e.g." --> "necessary. E.g." throughout
> the spec
> * "necessary. e.g." --> "necessary, e.g." throughout
> the spec
Oops. e.g. should never start a sentence. That error was introduced during
other editorial changes.
>> range
>> Same as number, but indicates that the exact value is
>> not important,
>
> 31. Suggestion: Either make this a separate <scale> element,
> or make its suggested presentation an *addition* to a
> text field rather than a replacement for it.
I don't understand what you mean by that.
> I see three general use cases for this control.
>
> A. An author provides just a slider, and doesn't mind
> if it degrades to a text field. (Most uses.)
>
> B. An author provides a text field and a slider next to
> each other, for ease of input both with a keyboard
> and with a pointing device. (For example,
> colorpickers, size selectors, and image manipulation
> tools.)
>
> C. A game developer provides a slider, and does not
> want it to degrade to a text field because that
> would ruin the fun. (For example, she uses scripting
> to create a slider and then to oscillate its
> value, with a button for the player to click when
> the slider is as close to the value he wants as his
> hand-eye coordination will allow.)
>
> The current syntax only satisfies case A. Case B doesn't
> work because in a non-WF2-supporting browser it will
> degrade to two text fields next to each other, which
> will be incomprehensible. And case C doesn't work
> because cheats can easily make it degrade, by using a UA
> (such as a current release of Opera) that doesn't
> support WF2 but does allow easy UA spoofing.
Case C can always be defeated; legacy UAs are just one of many ways to do
this. Whatever solution we pick. So case C isn't worth considering.
Case B is the case where the author wants a slider and is assuming
JavaScript will be available. If JS is available, then he can handle the
legacy case in JS (either by only creating the range control in WF2+JS
UAs, or removing it in non-WF2 UAs).
Case A is the current case and the one that I believe we should optimise
the design for.
> If, instead, it was a <scale> container element:
> A. would work by including an <input type="text">
> inside the <scale> element.
This makes the common case harder. Bad design.
> | Log me out if I'm idle for:
> | <scale id="expire" valuewithunits="30m" value="30"
> | min="10" max="180">
> | <subscale min="10" max="50" step="10" suffix="m"
> | value="minutes" />
> | <subscale min="1" max="3" suffix="hrs"
> | suffixsingular="hr" value="hours" />
> | <extreme label="Never" value="n" />
> | <!-- degrade for WF1: -->
> | <input id="expire-wf1" value="30" /> minutes
> | </scale>
> |
> which might appear in a Web-Forms-4-compliant UA as:
> |
> | Log me out if I'm idle for:
> | ========V===========================
> | ' ' ' ' ' ' ' ' '
> | 10m 20m 30m 40m 50m 1hr 2hrs 3hrs Never
Actually Web Forms 2.0 supports this today, with no changes, if the
server is willing to handle the scale itself:
Log me out if I'm idle for:
<input name="expire" type="range" list="e" min="0" max="2" value="0.4">
<datalist id="e">
<option value="0" label="10m">
<option value="0.2" label="20m">
<option value="0.4" label="30m">
<option value="0.6" label="40m">
<option value="0.8" label="50m">
<option value="1" label="1hr">
<option value="1.33" label="2hrs">
<option value="1.66" label="3hrs">
<option value="2" label="Never">
</datalist>
The server then just handles anything from 0.0 to 1.0 by multiplying it by
60 to get minutes, handles anything from 1.0 to 2.0 (exclusive) by
subtracting 1, dividing by 1/3, and adding 1 to get hours, and handles 2.0
as meaning "Never".
Admittedly, that doesn't fallback very well when it comes to legacy UAs,
but then this autocompletion feature wasn't designed with this particular
sadistic use case in mind. :-)
> I know the famous Safari RSS slider doesn't have or want a text field;
> but that's *part of a browser's own interface*, so I don't see any need
> for it to be a Web Forms control to begin with.)
The "famous Safari RSS slider" is a very good example of a slider in a Web
App, and is an important use case that WHAT has to address.
Anyway. Disagreed; no change made to "range". The arguments you put
forward are not enough to require that the existing implemenation(s) be
changed, and the current solution is good enough for the common use case.
>> 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.
> > By default, all of these new types, just like the types from HTML4,
> > must have no value selected, unless a default value is provided using
> > the value attribute.
>
> 36. Suggestion: *Please* remove this requirement, at least
> for the date-/time-related controls. I have never seen,
> in any graphical toolkit, a timepicker or datepicker
> control (or even a calendar control) that did not have a
> default value. I would be surprised if it was even
> possible without changing the toolkits' APIs. Even if it
> was possible, their inconsistency with other uses of
> such controls on the user's computer would make them
> look broken. And they would be unreasonably difficult to
> use without the keyboard, as there would be no starting
> values to increment or decrement.
Ok, so what default should they use?
> > 2.1.1. Ranges
> > ...
> > A field with a max less than its min can never be satisfied and thus
> > would block a form from being submitted.
Changed, but really this was just describing a logical consequence of
earlier statements and is thus redundant as a conformance requirement.
> > 2.4. Extensions to the textarea element
> >
> > The rows and cols attributes of the textarea element are no longer
> > required attributes. When unspecified, CSS-compliant browsers should
> > lay the element out as specified by CSS, and non-CSS UAs may use
> > UA-specific defaults, such as, for visual UAs, using the width of the
> > display device and a height suitable for the device.
>
> 41. Error: Since the viewport is almost always smaller than
> the device, this appears to suggest that visual UAs
> default to making a textarea larger than the viewport!
> * "width of the display device and" --> "width of the
> parent element, and"
> * "height suitable for the device" --> "height less
> than those of the parent element and the viewport"
The concepts of of "width of the parent element", "viewport", etc, are
rather specific to the CSS rendering model. I don't feel comfortable using
those terms for the non-CSS case.
> > CSS UAs should render textarea elements as specified by the
> > 'white-space' property, although UAs may have rules in their UA
> > stylesheet that key the default 'white-space' property values based
> > on the wrap element for textarea elements.
>
> 42. Question: What is meant by "key the ... values"? How
> does a style sheet "key a value"?
s/key/set/.
> 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?
Also, I really like the consistency of saying invalid attributes are
always ignored.
> > 2.8. Extensions to existing attributes
> > ...
> > disabled
> > ...
> > When applied to a fieldset element it overrides the
> > disabled attributes of any descendent form controls
> > (regardless of whether they are associated with the
> > same form). In other words, a form control is disabled
> > if it has its disabled attribute set, or if any of its
> > ancestor fieldset elements have their disabled
> > attribute set.
>
> 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?
> > This attribute must not affect the initial value (the DOM defaultValue
> > attribute). It must only affect what the user may enter and whether a
> > validity error is flagged during validation.
>
> 49. Question: How should a UA behave if the initial value is
> longer than the maxlength?
This attribute must not affect the initial value (the DOM defaultValue
attribute). It must only affect what the user may enter and whether a
validity error is flagged during validation.
> 51. Suggestion: Add best behavior for UAs in minimizing
> errors.
> * "In addition to preventing submission of a form
> containing a field that does not match its pattern,
> a UA should:
> - ignore entry of a character that is not allowed
> anywhere in the field's value
> - instantly convert Latin characters to upper case
> or lower case if only one case is permitted
> throughout the field's value."
> (If necessary, use "may" instead of "should".)
I don't want to go near that at this point. I've heard UI and i18n people
tell me that both of the things you just described are actually bad, and
in any case this spec is trying to keep away from the UI specifics.
> >> For example, the following snippet:
> >> <label> Part number:
> >> <input pattern="[0-9][A-Z]{3}" name="part"
> >> title="The expected format is: a digit
> >> followed by three uppercase letters."/>
> >> </label>
> >>
> >> ...could cause the UA to display an alert such as:
> >>
> >> The text you have entered does not match the required
> >> pattern.
> >>
> >> The expected format is: a digit followed by three
> >> uppercase letters.
>
> 52. Suggestion: Give authors (and UA implementors) an
> example that provides a much more pleasant experience.
> (My footnotes below are not part of the suggested
> replacement text.)
Disagreed, because your proposed text had too many issues:
> * 'If focus is moved away from a control in which the
> user has entered an invalid value[1],
> [1] Why not "that contains an invalid value"? Because if
> the default value (such as "") is invalid, we don't
> want the form to turn into a sea of pink borders
> just from being tabbed through.
As described elsewhere, that wouldn't be invalid.
> 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.
> And if, for example, a text field has the code
>
> <label>Part number:
> <input pattern="[0-9][A-Z]{3}" name="part"
> title="A part number must be one digit
> followed by three uppercase letters."/>
> </label>
>
> and form submission is attempted[2] when this field
> is the first invalid field in the form[3], a visual
> [3] Why just for the first invalid field? To prevent a
> festival of simultaneous or consecutive balloons
> from multiple invalid fields.
Yes, I go on about this in the section that talks about this.
> UA may focus the field, and display a help balloon
> pointing at it[4] containing the text:
> [4] Why a balloon instead of an alert? Firstly, people
> don't read alerts. Secondly, it makes the identity
> of the field more obvious. And thirdly, it removes
> the need to dismiss anything -- you can edit the
> field with the balloon still present, and the
> balloon fades away as soon as you do something else.
This was also already mentioned in the appropriate section.
> <strong>A part number must be one digit followed
> by three uppercase letters.</strong>[5]
> You cannot complete this form until the field is
> correct.[6]'
> [5] Why put the author's message first? Because it's
> almost certainly more useful than the generic
> message.
> [6] Why not mention "pattern" in the generic message?
> Firstly because Grandma thinks a "pattern" is about
> knitting, not regexps. And secondly because the
> author might have stuffed up and omitted their
> message, and referring to a "pattern" without saying
> what it was would be needlessly aggravating.
Those two make sense, addressed.
> > 2.10. The required attribute
> > ...
> > For check boxes, the required attribute shall only be satisfied when
> > the checkbox is checked.
> >
> > For radio buttons, the required attribute shall only be satisfied when
> > exactly one of the radio buttons in that radio group is checked.
>
> 53. Suggestion: Use the present tense.
> * "shall only be satisfied" --> "is satisfied only"
"shall" is an RFC 2119 term. And it _is_ present tense.
> > 2.11. The form attribute
> > ...
> >> In this example, each row contains one form, even though without this
> >> attribute it would not be possible to have more than one form per
> >> table if any of them span cells.
>
> 54. Suggestion: Split the sentence for readability.
> * "one form, even though without this attribute" -->
> "a form. Without the _form_ attribute"
Disagreed; the whole point of the sentence is the link between the two
parts.
> > 2.12. The autocomplete attribute
> > ...
> > A UA may allow the user to disable support for this attribute. Support
> > for the attribute must be enabled by default, and the ability to
> > disable support should not be trivially accessible, as there are
> > significant security implications for the user if support for this
> > attribute is disabled.
>
> 56. Suggestion: Clarify the connections between the
> sentences.
> * "attribute. Support" --> "attribute. But support"
Disagreed because starting with a "But" sounds silly. I would link the two
into one sentence but that would be too long.
> > 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"
That would be a meaningless conformance requirement since how the user is
supposed to indicate this, or what forms an indication, is not defined.
> > Authors should only mark one (non-disabled) control per document with
> > the autofocus attribute.
>
> 59. Suggestion: Start this sentence with "However," and move
> it to the end of the paragraph describing what happens
> if multiple controls have the attribute set.
That would break the "This implies" text.
> > 2.16. Handling unexpected elements and values
> > ...
> > Upon encountering such an invalid construct, UAs must proceed as
> > follows:
>
> 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"
The word "construct" has been a noun for as far back as I can remember.
> 66. Error: This specification does not appear to include by
> reference any CSS specification as a whole (though it
> does mention CSS3 Generated Content and UI properties).
> Either that should be done, or these statements should
> be generalized in case the document is styled using a
> language other than CSS.
CSS is not required by WF2, but if it is used, then the relevant sections
define how it must be used. In the real world, CSS is the only stylesheet
language applied to HTML so it really doesn't matter.
> > 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.
> > 3.1. Introduction for authors
> > ...
> > To explain this, we will step through an example. Here is a sample
> > form with three rows:
>
> 72. Question: Why does the example contain no <form></form>
> tags?
When I wrote the example, the spec said <form> elements were optional (if
you omitted them, they were implied). That has changed since then. Fixed.
> >> <p><button type="add" template="order">Add Row</button></p>
>
> 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.
> >> <button type="remove">Remove This Row</button>
>
> 74. Suggestion: Encourage more standard text for such
> buttons.
> * "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.
> > 3.1.2 Suggestions for authors
> > ...
> > In order to be considered a part of the repetition model, however, the
> > row must have a repeat attribute with a numeric value. That value
> > can be any integer. (For example, you could use "-1" as the value of
> > all prefilled rows.)
>
> 75. Error: Bad markup.
> * "repeat<code>" --> "repeat</code>"
Oops.
> * "</code></code>" --> ""
Fixed (actually the source document didn't have that, the post-processor
script added that automatically to try to get around my earlier typo!).
> > 5. Form submission
> > ...
> > 1. Step one: Dispatch the submit event.
> > ...
> > 2. Step two: Check the validity of the form
...
>
> 86. Suggestion: Remove the redundant "Step xxx"s. We already
> know they're steps, and we already know what number each
> of them is.
Left for similarity with HTML4.
> > 2. Step two: Check the validity of the form
> >
> > If the form submission was initiated as a result of a
> > submit event's default action, then the form is
> > checked for validity. If, after the form has had any
> > relevant invalid events fired, any controls remain
> > invalid, then the submission shall be aborted.
> >
> > Otherwise, if the form submission was initiated via
> > the submit() method, then instead of firing invalid
> > events, a SYNTAX_ERR exception shall be raised (and
> > submission is aborted) if any of the controls are
> > invalid. [DOM3CORE]
>
> 87. Error: Mismatched tense.
> * "shall be aborted" --> "is aborted"
> * "shall be raised" --> "is raised"
Shall is present, and is there to be a conformance requirement.
> > Script authors who wish to validate the form then
> > perform submission can use script such as:
>
> 89. Error: Missing word.
> * "use script" --> "use a script"
I disagree; "script" in this usage is a collective noun like "glue".
> > 5.2. Handling characters outside the submission character set
> > ...
> > 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.
I added a paragraph to the end of the section, but it is a bit vague.
> 103.Suggestion: Match the tense of the rest of the spec. As
> appropriate:
> * "shall" --> "must"
> * "shall make" --> "makes"
> * "shall return" --> "returns"
RFC 2119 wording for conformance criteria. The spec is slowly getting more
"shalls" as I use them where it is more convenient than "must", so that
overall it will get more balanced over time.
Thank you very much for your input!
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 6 July 2004 18:30:29 UTC