On Fri, Sep 4, 2009 at 7:42 PM, Ian Hickson <i...@hixie.ch> wrote: > (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.)
Ah, okay. I'll use section names in the future. >> 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'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. >> 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. > 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. 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). >> 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. >> 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? >> 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? 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. > "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. >> 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? 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. >> 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? :-) Yes, it does. :) >> 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.
