window.find already exists
There's discussion about introducing find and findAll as an alternative to querySelector[All]. However, window.find exists already in Firefox and WebKit, and is for in-page text search. There's a placeholder for it in the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dom-find Are Firefox and WebKit going to drop the old find()? Is there legacy content that feature detects for find() and would break if it changed semantics? -- Simon Pieters Opera Software
Re: window.find already exists
On Mon, Nov 21, 2011 at 8:28 AM, Simon Pieters sim...@opera.com wrote: There's discussion about introducing find and findAll as an alternative to querySelector[All]. However, window.find exists already in Firefox and WebKit, and is for in-page text search. There's a placeholder for it in the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dom-find Are Firefox and WebKit going to drop the old find()? Is there legacy content that feature detects for find() and would break if it changed semantics? That only interferes if .find() for selectors is defined on window. qSA is only defined on Document and Element, though, and I see no reason that .find wouldn't be the same. (Dropping window.find would be fine with me if we could do so, though, so it's a good question to ask.) ~TJ
Re: window.find already exists
window.find() covers a use case not easily replicated by other APIs: searching within the page for text that crosses node boundaries. There was a thread on the WHATWG mailing list about this: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-July/032588.html Tim On 21 November 2011 16:29, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Nov 21, 2011 at 8:28 AM, Simon Pieters sim...@opera.com wrote: There's discussion about introducing find and findAll as an alternative to querySelector[All]. However, window.find exists already in Firefox and WebKit, and is for in-page text search. There's a placeholder for it in the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dom-find Are Firefox and WebKit going to drop the old find()? Is there legacy content that feature detects for find() and would break if it changed semantics? That only interferes if .find() for selectors is defined on window. qSA is only defined on Document and Element, though, and I see no reason that .find wouldn't be the same. (Dropping window.find would be fine with me if we could do so, though, so it's a good question to ask.) ~TJ
Re: window.find already exists
On Mon, Nov 21, 2011 at 9:03 AM, Tim Down timd...@gmail.com wrote: window.find() covers a use case not easily replicated by other APIs: searching within the page for text that crosses node boundaries. There was a thread on the WHATWG mailing list about this: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-July/032588.html As noted in that thread, it doesn't cover that use-case very well, it's not very interoperable between the UAs that implement it, and IE and Opera don't implement it at all. At minimum, window.find needs a lot of work. If it conflicts with selector-based find, we should drop it and re-spec it as something better with a more targeted name. ~TJ
Re: window.find already exists
On Mon, Nov 21, 2011 at 11:29 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: That only interferes if .find() for selectors is defined on window. qSA is only defined on Document and Element, though, and I see no reason that .find wouldn't be the same. So then we get another built-in method that will do different things if you call it by its bare name in an on* attribute vs. in normal JS? find() in on* would be document.find(), while anywhere else it would be window.find(). I ran into this once with getSelection() on window vs. document, when Gecko had different implementations for the two, and it was really confusing -- there was no way I'd have figured it out if I were a typical web author. Hopefully we can just drop window.find(), though.
