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

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'