Editorial comments on Proposed XHTML Module: Web Forms 2.0

# 1. Introduction
# "This is an update to the forms features found in HTML 4.01's forms 
chapter, ..."
This is an update, though it is not a comprehensive replacement for the 
original. Perhaps add a second sentence at the end of the first 
paragraph, e.g.: "This specification does not describe the complete 
behaviour of an HTML or XHTML user agent, merely the differences from 
the original specification."

# 1.2. Relationship to XForms
Insert a new paragraph before the diagram along the lines of: "This 
diagram shows how a Web Forms 2.0-capable browser could provide the 
presentation layer for an XForms system:", if that's not too confusing a 
way to describe it.

In the diagram, the 'HTML' document icon should indicate that it can 
either be an HTML or XHTML document, and (more importantly) that it 
refers to the modified 'Web Forms 2.0' dialect described in this document.

# 1.3 Conformance requirements
In RFC 2119, and many of the other documents that reference it, the key 
words ('MUST', etc.) are capitalised, while in this document, they are 
not. Append the sentence (from CSS 2.1): "However, for readability, 
these words do not appear in all uppercase letters in this specification."

# 2.1 Extensions to the input element
I think that you should stress in the introductory paragraphs that the 
new input fields must all be able to accept a blank value in addition to 
their strongly-typed value.

You also infer throughout the document that UAs may decide to allow 
arbitrary user input into a strongly-typed field. I assume that it is 
neither a requirement that UAs constrain entry only to valid input, nor 
a requirement that UAs not do this. In other words, a datetime field 
represented as an unconstrained input box in one UA, and as a datepicker 
control in another, are both equally conforming. A note to that effect 
would be useful.

Could you provide guidance as to whether UAs will be expected to provide 
feedback to the user about what makes up the valid contents of an input 
field, or whether page authors should provide that information to the users?

# datetime input type
As you're trying to illustrate that the UA is expected to show an 
'appropriate widget' (rather than force the user to use ISO8601), 
perhaps you could change the example to one that does *not* use the 
ISO8601 input format?

# integer and numeric types
As well as being compatible with scanf's format, is this format also 
compatible with ECMAScript's parseInt and parseFloat? If so, it would 
probably be worth mentioning that.

# integer type
The suggestion that a (visual) UA might display an integer input field 
in one of several presentation forms is well-meaning, but applies 
equally to all input types. Additionally, a UA would be unlikely to use 
a track bar control for an input control that might contain any value.

# min and max
As you specifically state that min and max apply to file upload 
controls, you should also explain what the meaning of min and max for 
these controls is in this section, as you do in section 2.4.

# 2.2. Extensions to the select element
# editable is ugly
I don't know that there's anything that can be done to supress the 
uglyness of editable="editable". In any case, the same problem exists 
for disabled, multiple, readonly, required, ...

# 2.5. Extensions to existing attributes
# "some existing attributes from [HTML4] are clarified below."
Nit: they're also being extended, not merely clarified.

# name attribute, predefined meanings from RFC 3106.
Is it worth noting that the reserved names in RFC 3106 are all prefixed 
'Ecom_'?

# 2.6. The pattern attribute
You might want to note that you need to bind the pattern to the start 
and end of the line if you want to validate the entire field. i.e., that 
a pattern of '[0-9]{10}' will merely ensure that the field *contains* 
ten consecutive numbers, not that that is all it contains. This is a 
clear result of using regular expressions, but is different to many 
other environments, which do not allow patterns of this type, and so 
many people may not expect this behaviour.

# 2.8. The form attribute
What is the expected behaviour for a form control with a form attribute 
that does not refer to a valid form? I assume it should be ignored, per 
2.15.

# 2.12. The output element
This section should probably appear with the rest of the elements, 
before section 2.5.

# 2.14. Guidelines for using radio, checkbox, and select controls
# "Using stylesheets it is possible to make select elements look like radio
# buttons or check boxes."
This may be possible with CSS3's 'appearance' property, but it is not 
possible in any current user agents, AFAIK. You should at least mention 
that this is a feature of CSS3, or risk confusing authors who might 
expect it to be possible in current user agents.

# 4.1. Bubbling semantics
I found this section easier to read if I mentally substituted 'document 
root node' for 'document node' in the last two paragraphs, and likewise, 
'document root' for 'document' in the second-to-last paragraph.

# 4.4.1. Declarative dependency tracking
This section seems completely out of place. You specify the grammar of a 
declarative subset of ECMAScript, then go on to say that it doesn't 
matter. Better might be to mention that it is possible, give the 
example, then provide the grammar in an appendix.

# 4.5. Form validation
I take it that the formerror event is a new event. That's not clear from 
the introduction.

Change: "The formerror event bubbles, as described in an earlier section."
To: "The formerror event bubbles as described in an earlier section."
(it's the manner of bubbling that was described earlier, and not the 
fact that it bubbles).

# 5. Form submission
# "When the user agent submits a form (e.g., in response to the user ..."
Remove the parenthetical clause? It's fairly obvious.

# Steps
Zero-based lists aren't cool, as list item two is now step numbered one.

# 2. Step one: Identify all form controls
This step is surely a pre-requisite for control validation (step zero)?

# 3. Step two: Build a form data set
The index used here is not related to the repetition index used in 
templates. It might be worth including a note to that effect to allay 
confusion.

# 5.2. application/x-www-form-urlencoded
# Step 4.
Should the hexadecimal encoding be in upper- or lower-case? (probably 
upper case, per http://www.textuality.com/tag/uri-comp-4#good).

Should *all* non [a-zA-Z0-9] characters be encoded in hex, save space?

# 5.3. application/x-www-form+xml: XML submission
The first paragraph should also be in 5.2 and 5.4, and not just in 5.3.

# 5.4. text/plain
Again, presumable the chosen encoding should be a superset of US-ASCII, 
similar to 5.2.

# 5.5. Semantics of method and enctype attributes
In the action tables, remove the 'Handle as if enctype was 
application/x-www-form-urlencoded.' and span the above text down, as is 
done for the 'delete' case, unless there is a difference.

As it happens, you could also simplify the tables into two rows: 
'enctype not specified, one file upload control' and 'otherwise'.

In tables, I found it easier to read the cells if I did s/Drop the form 
data/Ignore the form data/, and s/Drop action/Ignore action/.

# 5.5.2. For ftp:  actions
Span the 'post' and 'put' columns, removing the redundant text in the 
'post' column.

# 5.5.4. For file: actions
Remove '(DELE)' from the delete column, copied from the ftp section above.

# 5.5.6. For smsto: and sms: actions
Remove this section for the moment - it is useless without a 
specification for the sms: and smsto: schemes.

# 6. Fetching data from external resources
As sections 6.1 and 6.2 are expected to occur in the opposite order (6.2 
first), it would make sense to reverse them in the document.

Could you provide a complete example form data file for one of the 
previously provided form examples?

# 6.1. Seeding a form with initial values
s/UAs must process this file if/UAs may only process this file if/

# 7.2.1. The DOMMutableStringList interface
FWIW, I read 'DOMMutableStringList' as 'a list of mutable strings'. How 
about 'DOMStringListMutable' (as in, 'DOM string-list, mutable')?

# 7.2.2. The HTMLCollection interface
s/ECMASCript/ECMAScript/

# 7.9. Loading remote documents
# "These method is asynchronous, and are guarenteed to not finish 
loading the document
# or signal an error before the running script either completes or 
yields to the user..."
s/method is/methods are/
s/guarenteed/guaranteed/

Received on Saturday, 27 December 2003 05:22:58 UTC