[whatwg] Comments on Web Forms 2.0

(Quotes from the spec)

> Documents that use the new features described in this specification 
> using XHTML or other XML languages over HTTP must be served using an 
> XML MIME type such as application/xml or application/xhtml+xml and 
> must not be served as text/html. [RFC3023] Documents served in this 
> way may contain a DOCTYPE if desired, but this is not required.

+1 for not placing cargo cult doctype requirements on XHTML.

> datetime

> a dash (U+002D),

I suggest calling it a "hyphen" as the official name is HYPHEN-MINUS 
and the common implementations in fonts look like hyphens--not like 
dashes.

> 2.5. Extensions to file upload controls

>     * UAs should use the list of acceptable types in constructing a 
> filter for a file picker, if one is provided to the user.

That feature is not likely to be reliably implementable considering 
that real-world systems do not have comprehensive ways of mapping 
between file system type data and MIME types.

>     For text input controls it specifies the maximum length of the 
> input, in terms of numbers of characters. For details on counting 
> string lengths, see [CHARMOD].

Should UAs use NFC for submissions?

> 2.12. The autocomplete attribute

I guess this has to exist for banks with weak authentication, high 
paranoia and low clue. :-(

Over here (Finland) we use OTP authentication for banking.

> To prevent an attribute from being processed in this way, put a 
> non-breaking zero-width space character () at the start of the 
> attribute.

Isn't the use of that char as anything but the BOM deprecated or at 
least considered harmful?

> Since square brackets are not allowed in ID attributes in XML, the 
> above example cannot validate to an XML DTD. It is still well-formed, 
> however, and conformant to this specification.

Can DOM implementations that know about IDness be trusted not to barf 
when creating id attributes with non-ID values?

> Note that a string containing the codepoint's value itself (for 
> example, the six-character string "U+263A" or the seven-character 
> string "☺") is not considered to be human readable and must not 
> be used as a transliteration.

Do you expect UAs that already do this change their behavior with the 
legacy submission types?

>       How a UA establishes the page's character encoding is determined 
> by the language specification.

s/language/markup language/ to avoid confusion with natural language 
metadata.

> 5.4. application/x-www-form+xml: XML submission
>
> The message entity is an XML 1.0 document, encoded as either UTF-8 or 
> UTF-16 (at the choice of the UA),

+1 for not allowing encodings that XML processors are not required to 
support.

> which has a root element named "submission", with no prefix, defining 
> a default namespace uuid:d10e4fd6-2c01-49e8-8f9d-0ab964387e32.

I think that is an inappropriate attempt to micromanage the syntactic 
details that are in the realm of a lower-level spec. I think the 
submission format should either allow all the syntactic sugar that 
comes with Namespaces in XML or be layered directly on top XML 1.0 
without namespace support.

> UAs must not include an XML declaration

Again, a higher-level spec should not attempt to restrict the syntactic 
variance allowed by a lower-level spec. The XML declaration is allowed 
by the XML spec.

> but must include a BOM.

I think that is not a legitimate requirement when UTF-8 is used.

> UAs may use either CDATA blocks, entities, or both in escaping the 
> contents of attributes and elements, as appropriate.

In order not to imply that this spec could restrict the ways characters 
are escaped, that sentence should be a note rather than part of the 
normative prose. (Of course, only the pre-defined entities are 
available. Then there are NCRs.)

> The resulting XML must be a well-formed XML instance.

If it is not well-formed, it, by definition, is not "resulting XML". :-)

> The only mention of namespaces in the submission document must be the 
> declaration of the default namespace on the root element.

See above.

-- 
Henri Sivonen
hsivonen at iki.fi
http://www.iki.fi/hsivonen/

Received on Tuesday, 13 July 2004 10:42:10 UTC