- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Sun, 10 Jul 2005 23:31:24 -0500
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
Received on Sunday, 10 July 2005 21:31:24 UTC