[whatwg] Spec comments, sections 4.9-4.10

On Mon, Sep 14, 2009 at 7:21 AM, Ian Hickson <ian at hixie.ch> wrote:
>> > 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?

By this point I've totally forgotten how I was interpreting the text
when I first read it, but I know I was confused.

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

Right, I didn't mean to suggest you should add more.

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

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.

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

Great.

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

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

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

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

I'm not sure either, I guess.

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

Received on Thursday, 17 September 2009 12:38:55 UTC