On Thu, 17 Sep 2009, Aryeh Gregor wrote:
>
> The wording "Unless otherwise specified" makes it sound like it's not
> otherwise specified, though, or at least it's noncommittal about whether
> it's otherwise specified. It would be clearer (and marginally shorter)
> if it said "The user agent should not allow the user to modify the
> element's value or checkedness except as specified", thus making it
> clear that it *is* specified.
I've gone through the spec changing "unless" to "except where" in a lot of
cases. Let me know if you think it should be better still.
> >> >> 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.
>
> Then the only significant part of the sentence is "representing the
> user's selection", and "a valid global date and time string expressed in
> UTC" is in fact redundant to the second sentence? You could replace it
> with "a date and time string" or such, to make it clear that the
> sentence adds no additional requirement of validity beyond what the
> second sentence imposes.
If I did that, then the UA would be the one setting the string, and the
requirement in the previous sentence wouldn't apply, since that one is
about the UA not letting the _user_ set the string to an invalid value.
> I really think it's self-evident that the user agent has to set the date
> and time to one corresponding to what the user actually selected,
> though. I know you like to be explicit, but . . .
Through many years of finding that people argue the most inane things
("no, this isn't a bug, because the spec doesn't _require_ that we not
crash", etc), I really would rather be overly specific than hope that
other people agree with me on what is obvious.
> > There are any number of possible ways of doing autocomplete that
> > aren't necessarily worse than <datalist>, depending on what you want
> > to do.
>
> Like what?
Providing selection-based autocompletion, or having some sort of funky
graphical representation of the available options, or... who knows.
> >> 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?
>
> Probably near the top of "The button element", since that's later in the
> spec than input elements.
I don't know that that would help -- readers wouldn't look at buttons to
work out why text fields have a readonly attribute, for instance, and it
seems odd to put a note near <button> elements but not near other things
that can be disabled but not made readonly (like <fieldset>).
I don't really see what the note would say, either.
At the end of the day, readonly vs disabled is a UI toolkit feature that
is present in all UI toolkits I know of; I'd rather not have HTML5 turn
into a treatise in designing UIs and using UI widgets.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'