W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2006

[whatwg] [wf2] Late comments and questions on Web Forms 2.0

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 15 Aug 2006 06:15:46 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0608150507060.5340@dhalsim.dreamhost.com>
On Wed, 8 Mar 2006, Henri Sivonen wrote:
> 
> Source level
> The language is en-GB-hixie not en-GB-x-Hixie (as defined in Hixie English
> 1.0-pre38 :-).

Fixed.


> 1.9. (and elsewhere)
> It appears that "conformant" is not generally accepted in dictionaries.
> ("Conforming" is.)

It's commonly used these days.


> 1.9. & 2.5.
> The spec does not have a spec-wide clarification on what is meant by a
> character. Also, maxlength is defined in terms of code points and not
> DOMString (UTF-16) code units. Is this intentional?

Yes and yes.


> 1.10. & 2.3.
> Cursory testing indicates that IE6 does not do Unicode case folding when eg.
> checking the value of the type attribute on the input element. This suggests
> an interop problem. As far as document conformance goes, can the values that
> browsers are required to compare case-insensitively be required to be lower
> case or at least confined to the Basic Latin block (i.e. no Turkish i)? Any
> difference between HTML and XHTML?

I'd like to avoid specifying this in detail for WF2 since it is not really 
specific to forms. I'm going to address this more low-level stuff in HTML5 
in detail.


> 1.12.
> In my opinion (considering RFC 2616), servers should not require a Referer
> header in a "trusted host" check but should only reject requests with a
> Referer header that has an undesirable value.

That would enable attacks from hosts that use SSL.


> 2.3.
> "User agents may establish a button in each form as being the form's default
> button. (This should be the first submit button in the form, but UAs may pick
> another button if another would be more appropriate for the platform.)"
>
> That is problematic, because then the author cannot know which button will be
> treated as the default button.

Why is this a problem? It's the user that needs to know the default 
button, not the author.


> 2.4.
> How is stepping over leap seconds expected to handled? Suppose the value of a
> datetime field is 2006-01-01T00:00:00Z and the step has been set to one day
> (86400). The user takes a step down. Is the correct value then
> 2005-12-31T00:00:01Z or 2005-12-31T00:00:00Z? I have no idea how this issue is
> usually dealt with in software. How can libraries released at different times
> have the same notion of the discretionary decisions of some bureau? To me it
> seems that leap seconds are a can of worms and more trouble than they are
> worth, but sadly they seem to be an official part of UTC.

Generally speaking computers ignore leap seconds at the user layer. I've 
made the spec explicitly ignore leap seconds.


> 2.4.
> Does ISO 8601 define how its flavor of the Gregorian calendar rolls backwards
> all the way to, say, 1900 or 1 AD?

No idea, I haven't got a copy of it.


> 2.4.
> If the specified value of the value attribute does not conform to the datatype
> and is not "", is it proper to consider the document non-conforming? (I'd say
> this would be useful for quality assurance of the initial state of forms but
> would be violated when round-tripping data to a non-WF2 UA.)

Yes.


> 2.4.
> Is it conforming to have leading zeros in a year that fills four digit slots?
> E.g. 00002006-03-08T00:00:00Z

Yes. Actually the spec is quite vague about exactly how the "date" types 
can allow. This is another one of those things that I'd like to define at 
a lower level in HTML5 rather than covering it in WF2.


> 2.4.1
> "A field with a max less than its min can never fulfill both conditions when
> it has a value (since that value will always either underflow or overflow the
> allowed range) and thus must block its forms from being submitted. This does
> not make the document non-conformant."
> 
> Why doesn't it make the document non-conforming?

I don't like making things non-conforming without good reason. Too often 
I've wanted to do something that turns out to be illegal because the spec 
author didn't think of my use case.


> 2.6.
> "Authors should include a description of the pattern in the title attribute."
> 
> How does that requirement on authors relate to checking document conformance?
> It seems to be of the same ilk as requiring alt.

I don't think automated conformance checkers could check this.


> 2.7.
> The prose does not say that 'required' is a boolean attribute.

What does that mean? Again, this is the kind of thing I'm going to address 
more generally in HTML5.


> 2.8.
> The prose says "space-separated". Since the usual SGML and XML convention is
> to use tokens separated by one or more white-space characters and preceded and
> trailed by zero or more white-space characters, I'd like to see more precise
> prose that makes it clear whether the convention is followed or if "separated
> by a single U+0020 character with no space before or after" is meant.

You're not going to like this but... would you mind if I defined this kind 
of stuff in the HTML5 spec rather than shoehorning it into WF2?


> 2.8.
> "In other words, form controls and fieldsets must be associated with the forms
> given in their form attribute, or, if they don't have one, must be associated
> with the nearest ancestor form element or the forms given in the form
> attribute of the nearest fieldset element with a form attribute, whichever is
> the nearest. If none of those apply, the element is not associated with any
> form."
> 
> That paragraph presumable makes statements about UA behavior but the
> formulation look like statements about document conformance.

Fixed.


> 2.8.
> "If a form is specified multiple times in the form  attribute, all occurrences
> but the first must be ignored. (An element can only be associated with a form
> once.)"
> 
> Are multiple occurrences non-conforming from the document conformance point of
> view?

Fixed.


> 2.11.
> "This attribute is defined to be exactly equivalent to the inputmode attribute
> defined in the XForms 1.0 specification (sections E1 through E3.2) [XForms]."
> 
> "inputmode" linked to WF 2.0 inputmode. Should be linked to inputmode in the
> XForms spec.

Fixed.


> 2.12. & elsewhere
> 
> Are dangling id references non-conforming? (I hope they are.)

General thing, ->HTML5.


> 2.13.
> "(If the value of defaultValue is queried before the entire element's contents
> have been parsed, or if the element was created dynamically (as opposed to
> being inserted into the DOM by the UA's parser), then defaultValue must return
> the empty string.)"
> 
> Does textContent guarantee such behavior in mid-parse?

No.


> 2.14.
> "Authors should always specify a cols attribute when the wrap attribute is set
> to hard."
> 
> Should violating a 'should' like that be considered a conformance error in
> terms of document conformance?

A warning, probably.


> 2.14.
> "Authors may include an accept  attribute on textarea elements to indicate the
> type of content expected. User agents may use this attribute to provide more
> appropriate editors, syntax highlighting, spelling checkers, etc. The value of
> the attribute must be a single text-based MIME type (for example, text/plain,
> message/news, image/svg+xml)."
> 
> Are MIME type parameters allowed?

Sure. It's just a MIME type.


> If image/svg+xml is on the example list, shouldn't application/xml be as 
> well to emphasize that it is not about text/*?

Two of the three MIME types are not in text/*. Isn't that clear enough?


> 2.15.
> 
> 'range   := "*/*" | type "/*" | subtype "/" type'
> 
> Looks like it should read
> range   := "*/*" | type "/*" | type "/" subtype

Oops.


> 2.16.
> "These names, and their exact semantics, differ from those of the equivalent
> attribute in XForms 1.0 (the replace attribute on the submission element)."
> 
> "replace" links to WF 2.0. Should link to XForms.

Made it not link to WF2.



> 3.2.2. & elsewhere
> 
> It would be nice to state that "decimal digits" are those in the Basic Latin
> block and nothing else.

Yeah. I'll be much more explicit about this stuff in HTML5. For now, I'll 
just assume implementors aren't stupid enough to try using Hebrew numbers 
or something.


> 3.2.2.
> Are orphan repetition blocks conforming?

Yes.


> 3.3.
> "When the value attribute is absent, the buttons should be given
> locale-dependent default labels, in the same way as submit and reset buttons."
> 
> Matching the page locale (if strings available) or always from browser UI
> locale?

Undefined. I don't want to limit the implementor's options here.



> 3.4.
> Are repeat-max and repeat-min non-conforming without repeat? Would make sense.

Not at the moment, for the reason given above... but I can't see a use 
case, indeed.


> 3.6.1.
> Is is non-conforming to mark the root element as a repetition template?

Not unless there's a part of the spec that says so. Pretty stupid though.


> 3.6.1.
> Is it non-conforming for the document initial state not to comply with
> repeat-max and repeat-min?

No.

Thanks for the comments. I hope you don't mind my pushing a lot of these 
things over to HTML5. I agree they should be defined, but defining them in 
WF2 would be more work than defining them in HTML5, and defining them in 
HTML5 is something I'll have to do anyway at some point. I'd rather not 
have to do it twice. I hope you understand.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 14 August 2006 23:15:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:28 UTC