Bug relates to a topic in 11/18 site-content conf-call & earlier
discussion in "URL structure sanity check" public email thread, which
referenced these URLs based on the proposed /apis URL structure:
See Paul Irish's comment from thread: "I feel like the larger
issue is one of granularity. There simply isn't a good reason all
the PerformanceTiming events (for example) should get their own
page. performance.timing deserves ONE page that's comprehensive."
Agree there's a benefit to avoid tiny fragmented pages, and to
consolidate wherever possible to provide optimum context for reader.
Question that needs clarity: in cases where child member pages feature
only small snippets of content, can we:
(a) Programatically move the structured content to embed within the
(b) Simply reflect the content on the parent page, while keeping the
longer-form child page?
Inclined to think the latter might be better, but user might need hint
if click-thru to child page features info not reflected on parent page.
In both cases, explore opportunities to express routine info more
tersely if they appear on parent pages. E.g., small icons rather than
tables for whether events bubble, w/rollover text hints if unclear.
Or assume away mundane default info, e.g., only noting when events
Or, can a tool distinguish whether a unit of content:
(a) meets a sufficient threshold weight to justify a separate child
(b) features certain kinds of info inappropriate to cram onto the
parent page, such as code examples? E.g., anything other than a
routine summary & data type?
Might be a significant issue when importing structured content that
would otherwise generate numerous child pages.
This also relates to some prior discusion of the /apis URL structure:
no need to represent constants and exceptions on dedicated pages the
way you often do for methods, properties & events.
any other large issues this didn't capture, please comment away.
I certainly don't think there is a problem with repeating content, and indeed, this worked for different people who want to consume the content in different ways - some people will want to see an overview of all the PerformanceTiming events, for example, while others will want to see single concise pages on individual events. Different people will search for different things as well.
I can't comment on whether we could get an automated tool that would be able to work out whether to list child pages or not. Maybe we cold err on the side of creating the pages, then get someone to look through them in each case like this, and decide whether to keep them all?
New location: http://project.webplatform.org/ia/issues/10