Re: Editorial comments on Proposed XHTML Module: Web Forms 2.0

I've not mentioned editorial comments that I simply fixed or that became
irrelevant due to larger changes.

On Fri, 26 Dec 2003, Malcolm Rowe wrote:
>
> # 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.

"What diagram?" It's only a diagram in graphical UAs. Actually, the
diagram is redundant with the following paragraphs, so it's alt text is
"", which would thus cause confusion if it was captioned.


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

I guess. I've noted this down, but I am unlikely to update the diagram in
the near future.


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

I'll be marking up the RFC2119 terms at some point, styling them with
small caps in an alternate stylesheet or some such.


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

I've added notes like this in various places.


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

I am awaiting implementation experience before commenting on this in the
spec.


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

Yeah, I'd like other widget examples. Again, noted, I'll see what I can do
at some point.


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

I think it is, note added.


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

This is for parity with the numbering in HTML4. I've changed the list
numbering to match the step numbering so they match.


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

Again, parity with HTML4 is what is keeping this strange order. Actually
it's not really a pre-req because of the (strange) way I've defined
everything, but I see your point. :-)


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

It's what HTML4 says.


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

Actually no, there's nothing wrong with UTF-16 or EBCDIC in this case as
far as I know.


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

The difference is the semantics -- the "Handle as" cases are "errors", the
others are the actual cases.


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

I want to keep the tables the same throughout that section.


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

Again, the point here is that "post" is "wrong" and is being treated as
"put". I don't know if maybe I should mention that (I don't know how to
mention that).


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

Political reasons. It'll be removed eventually unless a spec appears.


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

Added to TODO list.


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

No. RFC2119 terminology.


Again, thank you very much for your input. It has been incredibly useful.
I look forward to further comments at a later date, if you have the time!

Cheers,
-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 7 January 2004 15:42:43 UTC