- From: Alex Komoroske <komoroske@google.com>
- Date: Mon, 25 Feb 2013 10:14:45 -0800
- To: PhistucK <phistuck@gmail.com>
- Cc: "public-webplatform@w3.org" <public-webplatform@w3.org>
- Message-ID: <CAPwaZpU2uF+cEatS=zEg7evvOy12Lz+VxkyosUJZek+GdXLsZg@mail.gmail.com>
On Sat, Feb 23, 2013 at 11:18 AM, PhistucK <phistuck@gmail.com> wrote: > From IRC (typos and redundancies were fixed) - > [21:09] <PhistucK> There is a general problem - some properties return > complex types, like HTMLCollection (document.anchors, element.children, > more). We should show the members of these returned objects within the > property. Right? > [21:11] <PhistucK> Like dom/properties/anchors should include all of the > methods that HTMLCollection has, like "namedItem". > [21:11] <PhistucK> getElement(s)ByX should include all of the members that > NodeList has and so on. > [21:11] <fr0zenice> mhm dunno, if it's a complex type, maybe with it's own > methods and stuff, could be worth a separate article/subarticles > [21:12] <PhistucK> Of course, but we should draw the members from it in > every property that returns it > [21:14] <PhistucK> Just writing, "returns an HTMLCollection" is not very > informative. We do it for objects. Everything should be as self contained > as possible. We want to avoid unnecessary navigations, I guess. > Extraneous navigations are not helpful. > > Any thoughts? other solutions? > Could we do something like we do for API_Object where we have a section for the parents' methods/properties/events? I agree that just saying "HTMLCollection" isn't hugely useful when you want to know how to *use *that collection, but we should be clear about how the concepts relate. > > ☆*PhistucK* >
Received on Monday, 25 February 2013 18:15:34 UTC