- From: Ben Maurer <bmaurer@andrew.cmu.edu>
- Date: Fri, 13 Jul 2007 11:22:05 -0700 (PDT)
- To: Colin McMillen <mcmillen@cs.cmu.edu>
- cc: Chris Blouch <cblouch@aol.com>, David Poehlman <david.poehlman@handsontechnologeyes.com>, "Gregory J. Rosmaita" <oedipus@hicom.net>, wai-xtech@w3.org
Since Colin isn't on the list I'm just going to pass this on
On Fri, 13 Jul 2007, Colin McMillen wrote:
> Hi Chris (and others),
>
>
> Colin
>
>>> function focus() {
>>> try {
>>> Recaptcha.focus_response_field();
>>> }
>>> catch (e) {
>>> window.setTimeout(focus, 100); // IE hack
>>> }
>>> }
>>> focus();
>>>
>>> Any particular reason for this? If it's a race state issue because you
>>> might be moving focus before the form field exists, you could just add the
>>> focus move to the onload event of the page body. Then the move wouldn't
>>> fire until the page is fully loaded. I believe that because your scripts
>>> are inline the onload event wouldn't fire until your script, which
>>> document.writes another script tag, is fully executed. Doing it this way
>>> also means you could have your included script do this task rather than
>>> having the integrator start another script block and come up with their
>>> own focus move code. You could simply move focus as the last line of your
>>> injection of the content into the page.
>>
>> Colin -- why the hack for IE? (Colin McMillen is one of our hackers)
>
> As Chris suggested, I think it would be more correct to remove the
> window.setTimeout() and move focus() into the onload. As Ben
> mentioned, the usual reCAPTCHA use case isn't to have the input field
> focused on load, because for most pages using reCAPTCHA (registration
> forms, blog comments, etc), the site designer probably wouldn't want
> such behavior. So that hack is just a hack for the sake of the demo
> (but we will probably remove it next time we update our production
> servers.)
>
> Colin
>
>
>
>
Received on Friday, 13 July 2007 18:22:17 UTC