[whatwg] Comments on Web Forms 2.0

[Ian Hickson]

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

Yeah.


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


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

   http://www.hixie.ch/tests/adhoc/css/selectors/id/001-demo.html
   http://www.hixie.ch/tests/adhoc/css/selectors/id/001-demo.xml
   http://www.hixie.ch/tests/adhoc/dom/core/015-demo.html
   http://www.hixie.ch/tests/adhoc/dom/core/015-demo.xml

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.

Fixed.


> > 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.   `._.-(,_..'--(,_..'`-.;.'