Update one.xml - Fixed ambiguity in sample code string

[tomfuertes]

Text on selector is ambigious to it's actual functionality. Changed from sounding like "the click on #foo had to be the first click in the document" to "the first click on #foo in the document"

jsfiddle for playground/proof: http://jsfiddle.net/B3zNn/1/

[tomfuertes]

Totally missed the text before this too (in quote below) - sounds like the original text was intentional, but that the functionality in the jsfiddle differs... Not sure if this is a jQuery bug request and/or a doc change

The second two forms, introduced in jQuery 1.7, are identical to .on() except that the handler is removed after the first time the event occurs at the delegated element, whether the selector matched anything or not.

[scottgonzalez]

I think this is actually a docs bug. @dmethvin Can you confirm the intended behavior?

[dmethvin]

The docs are correct as-is. The text in the body clarify what is going on if the example isn't totally clear. If there is no #foo in the document the handler will still be removed after the first click.

Even if we tried to handle this by waiting for a #foo to exist, there's no guarantee that's the right behavior. Imagine the same situation with .bar where it's less clear whether element(s) should exist or not.

[scottgonzalez]

@dmethvin The fiddle says otherwise; tested with 1.7.2, 1.8.3, 1.9.1, 1.10.1, 1.11.0, and 2.x.

[dmethvin]

Ok then I'll need to puzzle it out later.

[tomfuertes]

Posting a more comprehensive fiddle for ref per Dave's "if #foo doesn't exist" use case: http://jsfiddle.net/B3zNn/10/

[gibson042]

From its introduction to its current implementation, .one has always unregistered the handler immediately before invoking it (and thus has never unregistered the handler when a delegated selector failed to match). I vote for using this PR to update the documentation and example, rather than closing it and rewriting the method. 😉

[kswedberg]

Merged this in because it seems like the minor change to the docs is preferable to a possibly breaking change to the code. @dmethvin, let me know if you think anything else needs to be done here.

[tomfuertes]

Per @gibson042, I think the doc fix is preferred. Made the preceding paragraph to this fix consistent per the second comment here in #519

[kswedberg]

Thanks, Tom. We should be all good now.