Summary
jsxref lets authors address class-style namespace members without the namespace prefix (e.g. {{jsxref("Collator")}} → Intl/Collator). Today the eligible namespaces are a hard-coded list:
const NAMESPACE_PREFIXES: &[&str] = &["Global_Objects/Intl/", "Global_Objects/Temporal/"];
This is pragmatic — only Intl and Temporal have class-style children today — but it has to be updated by hand whenever a new such namespace appears.
Proposal
Derive the aliases from page types instead. When building the index, strip the namespace prefix for a page only when:
- the parent page is a
JavascriptNamespace, and
- the child page is a
JavascriptClass.
This naturally includes Intl/Temporal (class children) and excludes Math/JSON/Reflect (whose children are JavascriptStaticMethod/JavascriptStaticDataProperty/etc.), which is exactly the distinction the hard-coded list draws by hand. It also future-proofs against new namespaces without a code change.
The PageType variants already exist (JavascriptNamespace, JavascriptClass, …), and the index is built from en-US only, where page types are reliably set. The main work is threading the parent and child page types into index_one.
Notes
- Low priority / future-proofing: only two namespaces qualify today.
- The hard-coded list has a self-explanatory doc comment, so behavior is unchanged until this lands.
Follow-up from the review of #715.
Summary
jsxreflets authors address class-style namespace members without the namespace prefix (e.g.{{jsxref("Collator")}}→Intl/Collator). Today the eligible namespaces are a hard-coded list:This is pragmatic — only
IntlandTemporalhave class-style children today — but it has to be updated by hand whenever a new such namespace appears.Proposal
Derive the aliases from page types instead. When building the index, strip the namespace prefix for a page only when:
JavascriptNamespace, andJavascriptClass.This naturally includes
Intl/Temporal(class children) and excludesMath/JSON/Reflect(whose children areJavascriptStaticMethod/JavascriptStaticDataProperty/etc.), which is exactly the distinction the hard-coded list draws by hand. It also future-proofs against new namespaces without a code change.The
PageTypevariants already exist (JavascriptNamespace,JavascriptClass, …), and the index is built from en-US only, where page types are reliably set. The main work is threading the parent and child page types intoindex_one.Notes
Follow-up from the review of #715.