[whatwg] [WF2] Comments on sections 2.3 -- 2.5

[Boris Zbarsky]

Ian Hickson wrote:
>> The section on implicit submission does not talk about firing click events,
>> if any, on the submit button.  IE does this in some cases (though not
>> others), and web sites depend on them being fired when IE does fire
>> them....
> 
> Can you elaborate?

The submission behavior of various browsers I've tested is the following:

Netscape 4:  Hitting enter in a text input submits only if there only one text
input in the form.  The click event on the submit button is not fired, and the
submit button is not successful (in HTML 4 form submission terms).

IE/Win 5/6:  Hitting enter in a text input always submits.  If there is only one
text input in the form, the behavior is as Netscape 4.  If there are multiple
text inputs, the click event on the submit button is fired and the submit button
is successful (effectively, the click triggers the "normal" form submission code
path).

Mozilla:  Hitting enter on a text input always submit.  Behavior is the same as
IE's behavior for the multiple-text-input case -- a click event is dispatched on
the submit button, which triggers submission and causes the submit button to be
successful.

The point is, a number of sites that have forms that have more than one text
input do validation in the submit button's onclick handler instead of doing it
in onsubmit handlers... since said handler is always fired in NS4/IE/Mozilla,
they get away with it.

> What is it withdrawn in favour of? Do you know?

No idea.  I just followed the link you had to the ISO website and noticed the
status...

>> Description of 1970-W01 should probably talk about 1970-01-04, not
>> 1970-01-01.
> 
> The key point is that it contains 1970-01-01. If it had been 1969-W53 that 
> contained it, then that would have been the zero point instead. It's just 
> lucky that the 1970-W01 week contains both 01-01 and 01-04.

Ah, I see.  So the key is that 1970-W01 contains 1970-01-01, not that 1970-W01
is the first week of 1970.  Might be good to make the 1969-W53 example in the
spec to clarify that.

>> If the UA rounds to the nearest allowed value, does that mean "allowed by
>> step and within the min/max constraints"?  In other words, given <input
>> type="number" min="0" max="99" step="15">, what should 98 be rounded to?
>> 105, 90, or something else?
>
> Clarified.

I think this would be clearer if the specification explicitly stated that said
rounding may cause the value to be out of range, thus triggering a rangeOverflow
or rangeUnderflow validation error.


>> I'm not sure what to make of the recommendation for doing comparisons in 
>> string form when dealing with number types or with step.  It sounds pretty
>> complicated to get right for those cases...
> 
> It's not a requirement, merely a suggestion (albeit a "recommended" one).

I guess my point is that for number types or step this would be a very difficult
to follow suggestion and that attempts to follow it are likely to be pretty buggy...

>> I'm not sure what the clause "the interface concept of 'readonly' values 
>> does not apply to button-like interfaces." means.
> 
> It means that having a read-only button makes no sense. I don't understand 
> what you don't understand. :-)

It wasn't clear whether "interface" was a "user interface" or a "programming 
interface" (like a DOM interface, say).  The latter interpretation makes it 
sound like the readonly DOM attribute should disappear if the type of the 
control is changed, which I think is not the intent here.

> Good question. I've commented it out for now. Does "foo.readonly" really just
> reflect the content attribute in implementations or does it only return true
> for controls that can be disabled?

It just reflects the content attribute in Mozilla, and the language the DOM spec 
uses implies that that's what should be happening (the "See the XXX attribute 
definition" phrasing is what the DOM working group uses for "just reflect the 
attribute value into the DOM").

-Boris