[whatwg] [WF2] Comments on sections 2.3 -- 2.5

2.3:

It's not clear what happens in XHTML when a non-empty form is placed in the
head.  That is, is emptyness a conformance requirement for authors or UAs, and
what are UAs expected to do about it?

It's not clear what should happen if the constraint in the paragraph starting
with "The children of a form element must be block-level elements" is
violated.  Is this constraint to be enforced by UAs (if so, how), or by authors
(if so, what are UAs expected to do if it's not?).

The specification says: "In any case, events targeted at form controls within a
label must not be handled by the label itself."  What about links within a
label?  What about nested labels?

The section on implicit submission does not talk about firing click events, if
any, on the submit button.  IE does this in some cases (though not others), and
web sites depend on them being fired when IE does fire them....

2.4:

ISO8601 claims to be a "Withdrawn standard".  Is this an issue?

If I understand correctly, Week 1 of a year may contain some days
from the previous year, right?  If the last day of a year is a Monday, will the
week containing it be considered Week 1 of the next year, or Week 53 of the
current year, or both?  None of this is very clear to me from the text...

Controls with no default value specified are supposed to have no value
selected.  At the same time, the widget types recommended for rendering the
control (eg the clock recommended for time) do not lend themselves well to
having no value selected.  They lend themselves even less to having a value
unselected (the equivalent of a user clearing a text control completely), and
it's not clear whether UAs may, should, must, should not, or must not allow
form control values to be cleared by the user.

The terms "no value selected" and "left blank" are used interchangeably here,
it seems.  Perhaps it would be good to settle on one of the terms (and define
it somewhere)?

"Empty fields (those with no value) do not need to match their type." -- it's
not clear what this means.  Does "no value" mean the same as "no value
selected" or "left blank"?  What does it mean for a field to "match its type"?

What happens to selected values when the type of a form control is changed?
Should the UA attempt to perform some sort of conversion to the new type?

What happens to selected values when the min/max/step attributes of a form
control are changed?  Should they be coerced to the closest valid value?  Note
that there may be cases when the selected value can no longer be shown using
the widget that shows the control's value (eg a range control's max may be
changed to be less than the current slider position).

What happens if the 'value' DOM attribute is set to a string that's not in a
valid format for the control type?

What happens if the 'value' DOM attribute is set to a string that's out of
range given the min/max attributes on the control or isn't an integral number
of steps from the min or max?  Note that there may be cases when the widget
being used for the control can't show the out-of-bounds value (eg it's a range
slider).

2.4.1:

"A field with a max less than its min can never be satisfied when it has a
value" -- there is no definition of "satisfied" in this specification.

What happens to the default min/max values if the form control type is changed?
I assume they are reset to the default values for the new type, but that's not
obvious from this specification.

2.4.2:

Description of 1970-W01 should probably talk about 1970-01-04, not 1970-01-01.

What happens if the step of a number or range control is set to a nonpositive
number?  Is this treated as if step were not set?  If so, that's not obvious
from the text here.

If the UA rounds to the nearest allowed value, does that mean "allowed by step
and within the min/max constraints"?  In other words, given <input
type="number" min="0" max="99" step="15">, what should 98 be rounded to?  105,
90, or something else?

I'm not sure what to make of the recommendation for doing comparisons in string
form when dealing with number types or with step.  It sounds pretty complicated
to get right for those cases...

2.5:

If a fieldset is disabled, does that affect the value of the DOM attribute
disabled on descendant form controls?  Or just their visual appearance and
behavior?

Implementing maxlength efficiently on textarea as described (esp. for the
wrap=hard case) is likely to be somewhat difficult.  I don't really have a
decent suggestion on how this can be improved, but I fully expect uses to start
complaining that typing in textareas with maxlength set is slow (with the
display lagging behind the user), especially if the maxlength and the total
text are both large.

There have been repeated bugs filed on Mozilla to support readonly on radio and
checkbox inputs (authors want the inputs to be successful but not allow the
user to modify the value).  This is not to say that Web Forms should allow
this, necessarily, but it's worth considering....

I'm not sure what the clause "the interface concept of 'readonly' values does
not apply to button-like interfaces." means.

I'm not sure what the sentence "The DOM readonly attribute ([DOM2HTML])
obviously applies to the same set of types as the HTML attribute." means -- the
DOM attribute simply reflects the current HTML attribute value, no?  Or is this
sentence trying to say something stronger?

-Boris

Received on Sunday, 10 July 2005 18:57:55 UTC