- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 11 Jul 2005 15:45:55 +0000 (UTC)
As always, the updated spec is on the site at the usual URI. http://whatwg.org/specs/web-forms/current-work/ On Sun, 10 Jul 2005, Boris Zbarsky wrote: > > The submission behavior of various browsers I've tested is the > following: [...] > > 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. Okie dokie. Updated the spec to fire a click event. > > 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... Ok, thanks for the heads-up. > > > 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. Well, it's only a design decision for the spec, I don't think it's that important. Do you? I clarified the definition of weeks yesterday; this is a separate part of the spec. > > > 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. Added a parenthetical may. > > > 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 guess we could remove the suggestion. Would you prefer that? > > > 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. Changed to "user interfaces". > > 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"). Ok, just left it out then. Thanks, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 11 July 2005 08:45:55 UTC