[whatwg] Spec comments, sections 4.9-4.10

[Ian Hickson]

On Thu, 3 Sep 2009, Aryeh Gregor wrote:
>
> 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?

Nothing, nothing at all. Fixed!

(BTW, section names are more useful than section numbers because the 
sections move about a lot, and because the section numbers aren't in my 
source document, so I have to go and look up which section it is first.)


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

Do you mean in the table?


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

I'm not really sure what you mean here.

 - There's the element's "value" content attribute.
 - There's the element's "value" DOM attribute.
 - There's the "value" mode that the "value" DOM attribute can be in.
 - There's the element's "defaultValue" DOM attribute (which reflects the 
   element's "value" content attribute).
 - There's the element's actual value.
 - There's the value exposed to the user.

Are you asking that the fifth of these (the value concept) should be 
renamed to something else?


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

The "value sanitization algorithm" is invoked in these cases:

 - when the element is first created
 - when type="" changes state
 - when the control is reset
 - when the .value DOM attribute is set, if the .value DOM attribute has 
   the "value" mode


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

What's the element's default value or default checkedness?

It means that the internal states named "value" and "checkedness" can't be 
changed by the user unless otherwise stated. These aren't default 
anythings, and can have little to no bearing on what is exposed through 
the DOM or markup.


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

The difference is stylistic. Compare the two in Safari.


> In 4.10.4.1.5:
> 
> "not an valid e-mail address list" -> "not a valid e-mail address list"

Fixed.


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

This paragraph is setting out precisely what the requirements are for user 
agents. The four sentences each cover a slightly different aspect of the 
requirements.

They don't seem to overlap at all -- the first says that the UI needs to 
allow changes, the second that if the user can set the value directly, the 
UA needs to prevent invalid values from being set, the third says that if 
the UA allows the user to set the value using some sort of UI, that the UI 
should convert the value to one of those valid things, and the fourth one 
says that in addition, the UA can allow the user to reset the value to 
nothing.


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

Yeah, probably, but then it would make the processing for step="" way more 
complicated than it already is.


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

Oh, good point. Fixed.


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

Fixed.


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

I haven't mentioned datalist here.


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

"readonly" means that the value should be selectable for copy-and-paste 
(thus it makes no sense for buttons and other non-text controls to be 
readonly), while "disabled" means that the control should not be 
responsive to user interaction.

These conventions are common to most GUI systems.


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

Yikes. Fixed. Thanks.


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

Fixed.


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

Not especially. You set their labels differently, and there are a few 
minor differences like that, but nothing major.


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

It's just reminding the reader.


> Also, isn't this statement incorrect if the fourth argument is present 
> and set to true?

Fixed.


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

Does it make more sense with a "for" in front? :-)


> In 4.10.14.6:
> 
> "Attributes for form submission can be specified both on form elements
> and on submit button"
> 
> "button" -> "buttons"

Fixed.


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

checkValidity() on the <form> element tells you if the form is valid.

oninvalid="" can be used to override the constraints in particular cases. 
For example, ignoring a pattern="" attribute in certain edge cases, like 
if a checkbox saying "don't validate" is checked or something.


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

Ok, done.


On Thu, 3 Sep 2009, Kevin Benson wrote:
> 
> [...] There's also an accidental phrase duplication in the sentence 
> prior to the above:
> 
> "so that each line so that each line has no more than character width 
> characters."

Thanks, fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'