Comments on "Web Forms 2.0"

Hi Ian,

  As promised, I had a quick look at "Web Forms 2.0" as of July 3 2005,
<http://www.whatwg.org/specs/web-forms/current-work/>. Just some rough
notes though, hopefully they are of any use.

The document fails to discuss how web forms are to be implemented in an
environment that supports e.g. XHTML + SMIL, for example, it is unclear
which attributes may be target of which kind of animation, how linear
and paced interpolation of conceptually numerical values is to be
performed, how presentation values affect the processing model (e.g.,
if the input name attribute can be animated, would submission use the
presentation or the underlying value?), and how timing attributes affect
the processing model (e.g., can a form control that is not active be
successful?) SMIL can't discuss this, so this must be defined either by
the markup specification or some third compound document specification.

Note that there have been attempts to define this to some extend for
features in HTML 4,

  http://www.w3.org/TR/1998/NOTE-HTMLplusTIME-19980918
  http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/

and there are implementations for parts of these.

Section 3.6.1 item #16 is

  An added event in the http://www.w3.org/2001/xml-events namespace,
  which bubbles but is not cancelable and has no default action, is
  fired on the repetition template with the repetition block's DOM
  node as the context information.

It is unclear why the event is not a form event as discussed in section
4 of the draft; it is further not clear which interfaces event objects
of this type would implement, or how the context information should be
set. The object might implement the dom::MutationEvent interface and use
the relatedNode attribute for this purpose, but then there are various
other details undefined.

The note in section 4.3. includes a data: URL with illegal syntax, URLs
must not include unescaped "<" or ">" characters.

The note in section 3.6.4. appears to state conformance requirements;
that part of the document should either be normative or rephrased to use
more appropriate terminology.

Section 2.16 notes

  The form element's action attribute is no longer a required attribute.
  Authors may omit it. When the attribute is absent, UAs must act as if
  the action attribute was the empty string, which is a relative URI
  pointing at the current document (or the specified base URI, if any). 

The implications of this are unclear. For http://example.org/x/

  ...
  <form action="" xml:base="http://example.org/y/" ...
  ...

where will the submission go to? Note that the term "relative URI" is
not defined in RFC 3986, the correct term would be "relative reference".
Also note that RFC 3986 made "clarifications" to the relevant algorithm,
RFC 2396 did not really define the target URI in this case, it just
defined the resource as same-document reference which was commonly taken
to mean the document URI, while per RFC 3986 the target would be the
base URI.

Validation requirements for type="url" seem to be undefined. The draft
notes that only strings matching the IRI production are allowed, does
that mean that non-conforming IRIs that match that production are
allowed? (E.g., RFC 3987 also requires that IRIs are in full logical
order).

The XML reference is outdated. The Unicode reference is probably
outdated. The CSS3UI reference is outdated. The reference to charmod is
outdated. (For some, I am referring to the dates in the entries rather
than the URLs).

The document does not conform to http://www.w3.org/TR/charmod/ (e.g.,
content is not required to conform to charmod in order to conform to
the specification).

Section 2.6 notes

  Authors who wish to allow for any input so long as a particular string
  occurs somewhere in the input should put .* at the start and end of
  their pattern. If the input is expected to allow newlines, then
  [\x000000-\x10FFFF]* or [\s\S]* or some equivalent should be used
  instead, since the dot character in JavaScript regular expressions
  does not include newlines.

I do not know about JavaScript regular expressions, but in ECMA-262 the 
[\x000000-\x10FFFF]* is not suitable here, \x can only be followed by
two hex digits, so this should probably be [\u0000-\uDBFF\uDFFF] (as the
\u escape is limited to four digits, so you need to use surrogates).

Section 2.15 notes

  MIME types may have a subtype of *, ...

They may not; HTTP uses the term Media Range for this. The draft is
unclear about whether e.g. "application/xml" matches "image/svg+xml".

The document lacks a section on security considerations. There are a few
security notes in the document, but in general the discussion is very
incomplete. RFC 3552 provides guidelines for writing such text, in
particular, it should be pointed out which security considerations are
not discussed in the document because they are considered out of scope.

Section 2.4 notes

  Only absolute URIs and IRIs match the IRI token mentioned above.
  Relative addresses are not valid values for this input type.

This is incorrect, the IRI production extends beyond absolute IRIs, in
particular, absolute IRIs do not allow fragment identifiers while IRIs
do. It is unclear whether user agents may accept user input with
relative references or suffix references (e.g., "www.w3.org"); if this
is not allowed, or if implementations use incompatible algorithms to
turn such strings into IRIs, the input type is quite useless.

Section 1.11. notes

  If extensions are needed, they should be done using XML, with elements
  or attributes from custom namespaces. The use of extensions must not
  contradict nor cause the non-conformance of functionality defined in
  the specification.

It is unclear what this means. The intent could be that implementations
that ignore the extensions must behave in pretty much the same way as
implementations that process the extensions; this is neither useful nor
will extension writers care much about this requirement.

It is unclear how one would extend e.g. the input type attribute, it
does not make much sense to use new elements or attributes in such a
case.

There does not seem to be information about how display:none affects the
processing model, it is not clear whether user agents must not process
element with display:none in a special way or whether this is considered
out of scope of the draft. Some markup languages suggest that display:
none elements must be processed pretty much as if they were absent, so
if there is no such special processing, this should be pointed out.

The IDL fragments and interface definitions in the document are very
difficult to read, it would be much better if these used the DOM Level 3
markup and style; linking interface member definitions from the IDL will
also make the document much easier to use. Note that this style can
easily be generated using the W3C specgenerator.

The bold/yellow background color style for subheadings in the IDL is
awful.

It's not clear why the RFC1866 reference is normative.

The draft's use of U+FEFF is scary and IMO inappropriate. Its use of %%
in data: submission is scary aswell.

Section 6.1. is non-compliant, select.data must be a URI or IRI but it
isn't (unless there are complex error correction mechanisms involved
when settting data, in which the example would still encourage in-
appropriate use)

It's not clear whether the draft really does not normatively depend on
"Web Applications 1.0", it seems at least to make assumptions that are
not guranteed by the specification or its normative references, but I
did not study this in detail. (Note that "Web Applications 1.0" breaks
in IE6 and FireFox, missing sub-sections, content shifted outside the
viewport, etc. might be due to the use of incorrect HTML...)

regards,
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 5 July 2005 02:51:44 UTC