[whatwg] Spec comments, sections 4.9-4.10

[Aryeh Gregor]

In 4.9.11:

"The rowSpan DOM attribute must reflect the content attribute of the
same name. Its default value, which must be used if parsing the
attribute as a non-negative integer returns an error, is also 1."

What does "also" refer to?

In 4.10.4:

It's a little confusing that no visual distinction is made between
content attributes and DOM attributes here.  I thought it was an error
that checked occurred twice, for instance.  (Or is it an error?
Things like max and min only occur once even though they have both
content and DOM attributes.)

The use of "value" to mean both "current value" and "default value" is
confusing.  It would be clearer if all uses were replaced by "current
value", "default value", or something like "value content attribute"
or "value DOM attribute".  For instance, the "value sanitization
algorithm" really seems to be executed only for default values, not on
every value change.  I expected it to be applied to all values based
on the name.  (Or actually, is it also applied to scripted value
changes, but not changes due to user input?  Now I'm doubly confused.)
 Likewise, sentences like "Unless otherwise specified, the user agent
should not allow the user to modify the element's value or
checkedness." are very perplexing.  It would make more sense at first
sight if it said ". . . the element's default value or default
checkedness."

In 4.10.4.1.2:

What's the purpose of type=search?  Is it envisioned that this be used
as an inline substitute for OpenSearch, for instance?  Or is it mainly
intended to allow separate styling (e.g., to match platform
conventions)?  I can't find any practical normative difference, so it
would be useful if there were an informative note making it clear what
some differences might be in practice.

In 4.10.4.1.5:

"not an valid e-mail address list" -> "not a valid e-mail address list"

In 4.10.4.1.7:

"If the element is mutable, the user agent should allow the user to
change the global date and time represented by its value, as obtained
by parsing a global date and time from it. User agents must not allow
the user to set the value to a string that is not a valid global date
and time string expressed in UTC, though user agents may allow the
user to set and view the time in another time zone and silently
translate the time to and from the UTC time zone in the value. If the
user agent provides a user interface for selecting a global date and
time, then the value must be set to a valid global date and time
string expressed in UTC representing the user's selection. User agents
should allow the user to set the value to the empty string."

This paragraph looks repetitive to me.  I think the third sentence can
just be dropped, unless I'm missing something -- does it add anything?

Would it be useful to allow the step for datetime to be expressed in
some more human-readable format in addition to seconds?

In 4.10.4.2.1:

"The autocompletion mechanism must be implemented by the user agent
acting as if the user had modified the element's value, and must be
done at a time where the element is mutable (e.g. just after the
element has been inserted into the document, or when the user agent
stops parsing)."

I don't think this is a very complete specification of the behavior of
autocomplete=off in practice.  There are two major points that it
doesn't explicitly address:

1) If the user goes to another page (e.g., submits the form) and then
goes back, the form will be emptied of whatever he entered into it.
(At least in the versions of Firefox and Chrome I've tried it in -- I
didn't test systematically.)

2) The user agent not only won't remember what the user enters now, it
also won't pop up a list of suggestions from the past.

(2) is the sole reason that pages like http://www.google.com/ and
http://en.wikipedia.org/ use autocomplete=off: they generate their own
list of suggestions dynamically, and they don't want the UA's default
suggestions to interfere.  I think this use case is actually more
common in practice than the security-oriented use case.  This use
violates the following normative statement:

"The off state indicates that the control's input data is either
particularly sensitive (for example the activation code for a nuclear
weapon) or is a value that will never be reused (for example a
one-time-key for a bank login)"

I guess that in HTML 5, the correct way to implement this behavior
would be to dynamically populate a datalist element.  Perhaps some
(possibly informative) wording should be added to this effect, saying
that authors shouldn't use autocomplete just to replace the default
suggestions list?  (Although of course they will until UAs support
datalist, regardless of what the spec says.)

In 4.10.4.2.3:

I don't understand what the difference is supposed to be between
readonly and disabled.  disabled also doesn't submit the input?  Why
does readonly not apply to range, color, checkbox, radio button, or
file input?

In 4.10.4.2.9:

"If the element has a min attribute, and the result of applying the
algorithm to convert a string to a number to the value of the min
attribute is a number, then that number is the element's minimum;
otherwise, if the type attribute's current state defines a default
minimum, then that is the minimum; otherwise, the element has no
minimum.)"

"If the element has a max attribute, and the result of applying the
algorithm to convert a string to a number to the value of the max
attribute is a number, then that number is the element's maximum;
otherwise, if the type attribute's current state defines a default
maximum, then that is the maximum; otherwise, the element has no
maximum.)"

There's a stray parenthesis at the end of each of these paragraphs.

In 4.10.4.4:

"The task source for these task is the user interaction task source."

I'm not sure what this means, but I assume it should be "these tasks".

In 4.10.5:

It's not clear from reading the spec what the difference is between
buttons and inputs of the same type.  Is there any?

In 4.10.9:

"The Option() constructor with two or more arguments overrides the
initial state of the selectedness state to always be false even if the
third argument is true (implying that a selected attribute is to be
set)."

I'm confused why this is here, and not with the docs for the Option
constructor.  Also, isn't this statement incorrect if the fourth
argument is present and set to true?

In 4.10.10:

"The purposes of this requirement, lines are delimited by the start of
the string, the end of the string, and U+000D CARRIAGE RETURN - U+000A
LINE FEED (CRLF) character pairs."

I can't parse this sentence.

In 4.10.14.6:

"Attributes for form submission can be specified both on form elements
and on submit button"

"button" -> "buttons"

In 4.10.15:

I can find two uses of the invalid event (are there more?), but I'm
not sure what it's meant to do.  You can cancel it to make sure an
element is treated as valid for form submission -- although then
you'll confuse the entire rest of the constraint validation API -- but
why is it called on checkValidity()?  I'm not sure what it's meant to
be used for.  Or, consequently, what checkValidity() is meant to be
used for, as opposed to validity.valid (since the only difference
seems to be firing an invalid event).

In 4.10.16.1:

Perhaps replace ".../find.cgi?t=cats&q=fur" by just
"/find.cgi?t=cats&q=fur".  I briefly mistook the ... for .. and got
confused.