[whatwg] Spec comments, sections 4.9-4.10

[Ian Hickson]

On Sun, 6 Sep 2009, Aryeh Gregor wrote:
> >> 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?
> 
> Yes.

I removed the row for "checked", since it was redundant, and added 
annotations for the other IDL attributes.


> > 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?
> 
> I'm not really sure, I just know I got confused by which "value" was
> being referred to in various cases.  I'm not sure I can suggest any
> better wording, because I think I still don't understand what "value"
> is being referred to in a lot of cases.

Which of the above is unclear?


> >> 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?
> 
> I guess it's the same as the value content attribute, actually.  Or the 
> presence/absence of the checked content attribute.

Ah. I think I'd rather stick to the explicit terms instead of adding more!


> > 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.
> 
> So this is overridden for a lot of things by saying "the user agent 
> should allow the user to change X", then, and you really mean the actual 
> current value that will be submitted with the form.

Right.


> I didn't get that at all from reading it; I thought it referred to the 
> value/checked content attributes or something, because saying that the 
> current/submittable value couldn't be changed unless otherwise stated 
> seemed very unlikely to me. The general rule is it *can* be changed, in 
> practice, with some exceptions, so this way of stating it seems 
> backwards (and thus confusing given all the meanings of "value" flying 
> around).

Nothing is to be read between the lines -- unless it says that something 
can be changed, the default assumption is that it can't be changed. (There 
are a finite number of things that can be changed, and an infinite number 
that cannot, so it doesn't make sense to do it the other way around.)


> >> 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.
> 
> I think more informative notes about the purpose of things like this 
> would make the spec a lot easier to comprehend.

Added a note about this.


> >> 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.
> 
> As I'm reading it, the first two sentences imply the third.  The user 
> must be allowed to change it, but not to invalid values; so obviously 
> any input mechanism that's provided must only allow valid values to be 
> input.  What incorrect behavior does the third sentence rule out, which 
> the rest of the spec would permit?

The third sentence isn't ruling out anything, it's requiring specifically 
that if the user agent offers a UI, say a clock, that the user agent set 
the value to a value that matches what the user selected, so that, for 
instance, setting the value to 4 o'clock when the user picked 2 o'clock 
would be non-conforming.


> >> 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.)
> >
> > . . .
> >
> >> 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.
> 
> Any reason why not?

There are any number of possible ways of doing autocomplete that aren't 
necessarily worse than <datalist>, depending on what you want to do. Alos, 
I'm not sure it would really do any good to mention it here.


> Point (1) can actually make this use of autocomplete very annoying.  In 
> the case of Google and Wikipedia it doesn't really matter, because they 
> provide a new, identical search box on the search results page, so you 
> have no reason to go back.  But in other cases it can be pretty 
> irritating.  For instance, on this page:
> 
> http://www.vbulletin.com/forum/search.php
> 
> There are a bunch of options, so you fill in a lot of them (including 
> username, which is auto-completed by JS).  Then you do the search, and 
> realize you got one option wrong.  So you hit back, change the option, 
> resubmit . . . and find that now the search is still wrong, because the 
> username field was blanked when you went back.

That does indeed suck.


> > "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.
> 
> Is this behavior specified anywhere?  If not, it seems like it should 
> be, even if some subset of readers would be expected to guess it from 
> familiarity with the conventions of GUI systems.

The spec does say that disabled controls aren't focusable. I'm not sure 
what else it can say.


> >> 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.
> 
> Then why do both exist, rather than removing one or the other as with
> abbr/acronym and so on?  Too many sites using <button> that you don't
> want to gratuitously invalidate?

Right.


> Assuming both are kept, this is another case where a brief informative 
> note would be helpful -- it's logical to expect that new features add 
> something new, and if you can't spot the difference you're left 
> uncertain as to whether there is any.

Where would you put the note?


> >> 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.
> 
> I see.  Again, it would be helpful for the spec to give some idea of how 
> authors are intended to use these features.  In this case an example 
> would serve as well as a note.

I've added some examples. I'll add more over time. If there's something 
specifically you'd like an example for, let me know.

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