[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. :-(
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list