- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 14 Sep 2009 11:21:47 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 14 September 2009 04:21:47 UTC