[whatwg] Comments on Web Forms 2.0

Ian Hickson ian at hixie.ch
Tue Aug 17 06:37:46 PDT 2004

On Tue, 13 Jul 2004, Henri Sivonen wrote:
> > a dash (U+002D),
> I suggest calling it a "hyphen" as the official name is HYPHEN-MINUS and the

Fixed (throughout).

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

I am told modern systems do, now.

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

I don't know, should they?

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

Norway does too.

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

Arguably, it _is_ a BOM here.

I'm not overly fond of this either, but it's the only solution I could 
find that was relatively harmless (the BOM can always be dropped at the 
start of strings) and yet did the job. Better suggestions are welcome 

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

Pretty much:


The results aren't perfectly interoperable, but they are close, and more 
importantly, seem sane.

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

We can hope.

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


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

The reason it is micromanaged is to make it possible to use either a pure 
XML 1.0 parser _or_ an XML 1.0 with namespaces parser on the server side 
without getting into any complications.

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

I can't really think of a good argument for keeping this restriction, so 
I've removed it.

> > but must include a BOM.
> I think that is not a legitimate requirement when UTF-8 is used.

Why not?

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

This spec _could_ restrict the ways characters are escaped. It needs to 
not be a note so that the "may" has normative value. No?

>> The resulting XML must be a well-formed XML instance.
> If it is not well-formed, it, by definition, is not "resulting XML". :-)

That is a meaningless distinction IMHO. For sanity's sake, one has to 
consider anything labelled as XML to be XML, otherwise we can't then say 
that it is "ill-formed XML" when it is wrong. To put it another way -- if 
it isn't XML, then the XML processing rules don't apply, and UAs can 
suddenly do whatever they like since there is no longer a spec defining 
what they should do.

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

See above. :-)

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list