- From: Scott Rowe <scottrowe@google.com>
- Date: Wed, 5 Dec 2012 17:56:33 -0800
- To: Alex Komoroske <komoroske@google.com>
- Cc: "public-webplatform@w3.org" <public-webplatform@w3.org>
- Message-ID: <CAHZLcPrr0vdV_WDz0psEHwgSdh7jKSL25W4aKh6tqaWKtdfGTA@mail.gmail.com>
Thanks Alex, To the exception, lemme 'splain, below... On Wed, Dec 5, 2012 at 4:39 PM, Alex Komoroske <komoroske@google.com> wrote: > > >> >> Following the Main Content, the page would display a listing table of >> Objects using the same mechanism that the API_Object page uses to pull >> together tables of Properties, Methods, and Events - with the "Applies to" >> field of those pages. This Object/Summary table could replace the >> query-based or sub page-based table, or we could allow for that table to >> appear at the end of the page (which would require moving it down in the >> form). >> > > I don't think this is a good idea. The Applies_to machinery is very > specifically suited to members of an interface, where each member is part > of one interface. The API_Listing pages allow more rich queries that permit > you to have a single leaf page easily show up in multiple category listings > without the leaf page having to know anything about where else it's being > included. > >> The tables generated in the listing pages currently are category based, which means that even if I leave "print all subpages" unchecked, I still get the members of the objects in the table, when I only want the objects. You can see that in the apis/webrtc<http://docs.webplatform.org/wiki/apis/webrtc>page. What I'm trying to do here is generate a list of just the objects in the API, not all the subpages. I was suggesting the technique used with the "Applies to" field, but if there is a better way, that's fine. The idea is to summarize each API object in an API listing, with links to the objects, so that users don't have to wade through a long table of members.
Received on Thursday, 6 December 2012 01:57:01 UTC