[whatwg] Comments on Web Forms 2.0
hsivonen at iki.fi
Tue Jul 13 10:42:10 PDT 2004
(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.
> 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
> 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
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
> 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
> 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.
hsivonen at iki.fi
More information about the whatwg