Re: [whatwg] onchange events for input type=radio

[Ian Hickson]

On Thu, 18 Jan 2007, Boris Zbarsky wrote:

 There has recently been an interesting Mozilla bug report about onchange 
 for radio inputs.  It seems that UAs interoperably implement something 
 non-obvious; it may be a good idea to specify it:
 
 https://bugzilla.mozilla.org/show_bug.cgi?id=363693

Done.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] onchange events for input type=radio

[Boris Zbarsky]

Ian Hickson wrote:

On Thu, 18 Jan 2007, Boris Zbarsky wrote:
There has recently been an interesting Mozilla bug report about onchange 
for radio inputs.  It seems that UAs interoperably implement something 
non-obvious; it may be a good idea to specify it:


https://bugzilla.mozilla.org/show_bug.cgi?id=363693


Done.


Is http://www.w3.org/html/wg/html5/#event-input-change the relevant spec 
text?


-Boris

Re: [whatwg] onchange events for input type=radio

[Ian Hickson]

On Tue, 28 Oct 2008, Boris Zbarsky wrote:
 Ian Hickson wrote:
  On Thu, 18 Jan 2007, Boris Zbarsky wrote:
   There has recently been an interesting Mozilla bug report about onchange
   for radio inputs.  It seems that UAs interoperably implement something
   non-obvious; it may be a good idea to specify it:
   
   https://bugzilla.mozilla.org/show_bug.cgi?id=363693
  
  Done.
 
 Is http://www.w3.org/html/wg/html5/#event-input-change the relevant spec 
 text?

The relevant spec text is in several places.

For radio buttons in particular:

   http://www.whatwg.org/specs/web-apps/current-work/#radio-button-state

# If the element is mutable, then: The pre-click activation steps consist 
# of setting the element's checkedness to true. The canceled activation 
# steps consist of setting the element's checkedness to false. The 
# activation behavior is to fire a simple event called change at the 
# element.

Most of the terms in that paragraph are to do with (and are hyperlinked 
to) the algorithms defined in:

   http://www.whatwg.org/specs/web-apps/current-work/#interactive-content

Please let me know if that doesn't make sense, and I'll try to clarify it.

HTH,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] onchange events for input type=radio

[Boris Zbarsky]

Ian Hickson wrote:

The relevant spec text is in several places.

For radio buttons in particular:

   http://www.whatwg.org/specs/web-apps/current-work/#radio-button-state


Most of the terms in that paragraph are to do with (and are hyperlinked 
to) the algorithms defined in:


   http://www.whatwg.org/specs/web-apps/current-work/#interactive-content

Please let me know if that doesn't make sense, and I'll try to clarify it.


Ah, ok.

It makes sense; the phrasing and general formatting could probably be 
clearer, but I'm not going to worry about that at this stage, I think...


-Boris

[whatwg] onchange events for input type=radio

[Boris Zbarsky]

There has recently been an interesting Mozilla bug report about onchange for 
radio inputs.  It seems that UAs interoperably implement something non-obvious; 
it may be a good idea to specify it:


https://bugzilla.mozilla.org/show_bug.cgi?id=363693

-Boris