- From: James Graham <jgraham@opera.com>
- Date: Tue, 27 Dec 2011 12:47:30 +0100 (CET)
- To: Ojan Vafai <ojan@chromium.org>
- cc: "Marat Tanalin | tanalin.com" <mtanalin@yandex.ru>, www-dom@w3.org
On Mon, 26 Dec 2011, Ojan Vafai wrote: > I don't like the jQuery APIs as they are. :) "parent" doesn't add enough benefit to be worth the API surface and "parents" is O(n) where the vast majority common case is that you want the first > ancestor that matches the selector. > As far as use-cases, it's an incredibly common operation to walk up the tree and try to find an ancestor of a given type (e.g. find the link containing this node). Every JS library I've seen has > some helper function to simplify doing this. Making this part of the platform makes the platform easier to work with, allows for better code-sharing (e.g. I don't have to include jQuery just to get > a few nice helper functions) and should perform faster since all the parentNode/matchesSelector calls don't need to be marshaled/unmarshaled between JS and C++. > > I'm not opposed to calling this method "ancestor", but I prefer "parent". I think people are more likely to look for a method named parent and it's just easier to type. :) FWIW (I suspect very little), I find the idea of a method called "parent" that doesn't actually return a parent node very confusing indeed, and would certainly never think to look for a method with that name for the functionality you describe.
Received on Tuesday, 27 December 2011 11:48:05 UTC