Support a page_type front matter key...

[wbamberg]

...and expose it to KumaScript.

There are places where we want to do things depending on the type of thing a page documents.

One example is a sidebar that wants to group together pages that document particular types of thing. For example, the JSRef sidebar wants to group properties and methods in separate sections:

yari/kumascript/macros/JSRef.ejs

Lines 133 to 138 in 9ab3679

	if (containsTag(pageList[aPage], 'Property') && includeme) {
	result[object].properties.push(pageList[aPage]);
	}
	if (containsTag(pageList[aPage], 'Method') && includeme) {
	result[object].methods.push(pageList[aPage]);
	}

...and the CSSRef sidebar wants to group CSS properties, at-rules, and so on in separate sections:

yari/kumascript/macros/CSSRef.ejs

Lines 332 to 338 in 9ab3679

	const groups = standardPages.filter(page => hasTag(page, "Overview"));
	const properties = standardPages.filter(page => hasTag(page, "CSS Property"));
	const selectors = standardPages.filter(page => (hasTag(page, "Selector") && !hasTag(page, "Pseudo-element") && !hasTag(page, "Pseudo-class")));
	const pseudoClasses = standardPages.filter(page => hasTag(page, "Pseudo-class"));
	const pseudoElements = standardPages.filter(page => hasTag(page, "Pseudo-element"));
	const atRules = standardPages.filter(page => hasTag(page, "At-rule"));
	const types = standardPages.filter(page => hasTag(page, "CSS Data Type"));

Currently we use tags for this, but tags don't have clear semantics. For example, suppose we look for "CSS At-rules" tag to find pages that document at-rules. But someone might think the "CSS At-rules" should appear on a guide page about CSS at-rules, and why shouldn't they?

Similarly, for a tag identifying a page that documents a data type, is it "CSS Type" or "Type" or "CSS Data Type" or "Data Type"? To make this work reliably we have to define a particular "subtype" of tags, that have a particular semantics ("page type") and that are allowed to have a particular set of values. But at that point we're just hacking page_type into the generic tag system.

Another example where page type is useful is sidebars. We've talked about having a sidebar front matter item (instead of a KS macro call in content). This is good, but for most pages I think it would be better for the page to say what sort of page it is, and then for Yari to be able to map that onto a sidebar (there are some places where this doesn't work, like guide and landing pages).

We could also use this to make other rules about the content - such as that every js_method page should have a BCD section.

If we do this we need to define valid values for this key: we could use https://github.com/mdn/stumptown-content/tree/master/recipes as a starting point.

[peterbe]

Drive-by-comment; Whatever we do with this, let's make it so on the en-us page needs to set this. The translations should be able to piggy-back off of that. That would also alleviate having to update 60% of the total number of existing index.html files.

[peterbe]

In a sense, the functionality is now already in place.
If you add page-type: foo bar to the front-matter, you will be able to use env['page-type'] now.
It might require some heavy mass-edits of index.html files so it becomes all available.

But what we could do is implement it something like this, in the Kumascript macro code:

let CSS_font_page = false;
if (env['page-type']) {
  // one of them fancy pages that have been updated
  CSS_font_page = env['page-type'] === 'font';
} else {
  console.warn(`${page.mdn_url} lacks the 'page-type' front-matter. Falling back on comparing tags.`);
  ...
}

[wbamberg]

You are right, this is a content issue for now. I started https://github.com/mdn/content/discussions/5162 for it.