Add support for adding status label component within documentation page headings

[pastelcyborg]

Done

• Add support for adding a status label component within a documentation page heading
• Add new vf-u-align--middle utility for vertically aligning inline elements
• Update table of contents JS script to support new status label addition

Fixes WD-14923
Fixes #5349

QA

• Open equal height row docs (and any other docs pages with recent changes)
• Witness new status label within relevant headings

Check if PR is ready for release

If this PR contains Vanilla SCSS code changes, it should contain the following changes to make sure it's ready for the release:

• PR should have one of the following labels to automatically categorise it in release notes:
  • Feature 🎁, Breaking Change 💣, Bug 🐛, Documentation 📝, Maintenance 🔨.
• Vanilla version in package.json should be updated relative to the most recent release, following semver convention:
  • if CSS class names are not changed it can be bugfix release (x.x.X)
  • if CSS class names are changed/added/removed it should be minor version (x.X.0)
  • see the wiki for more details
• Any changes to component class names (new patterns, variants, removed or added features) should be listed on the what's new page.

[webteam-app]

Demo

Jenkins

demos.haus

[petesfrench]

Thank you for jumping on this so quickly! This is a huge QOL improvement.

[bartaz]

We used to do it in the past (label was put below heading) but it was kind of pain to maintain, because you would have to remember to remove those in next non-patch releases.
So without being able to do it automatically it's just gonna be the same mundane process again (or we will likely just forget to take them off).

Another reason that we used to put label below heading is to avoid these issues of having label as part of heading text. Both it adds itself to the id (which you workaround here, but still it seems bit hacky and fiddly), but also I have some accessibility doubts if it makes sense for this label text to actually be in the header (accessibility tree, screen readers, etc).

So while I agree it would be a significant improvement, we should maybe take a look how to do it properly, to avoid the mistakes of the past.

[petesfrench]

I would argue that the status label in the side-navigation is essentially useless without some kind of indication within the documentation. As currently the only way to know exactly what changed is the check the change-log.

If you are to automate it, you can add it after the heading IDs are generated avoiding any nefarious coding practices. And as for accessibility concerns, this is nothing here that can't be addressed with the use of ARIA.

[pastelcyborg]

After speaking in a meeting earlier today, we've decided to submit this as-is, as it's still a significant QoL improvement even without automation and such. I'll add a new process step to our docs to remind contributors to remove any outdated status labels before a new release.

We'll be exploring ways to better automate this with our new architecture projects.

[jmuzina]

4.16.0 has already been released (and no PR that bumps the version has been merged), so this should bump the version to 4.17.0.

[bartaz]

It may be a bit confusing that we have u-align--bottom (that handles aligning with flexbox using margin) and u-align--middle that works in completely different context using completely different props (vertical-align).

I'd argue that the new u-align--middle is actually less confusing than the existing u-align--bottom (that doesn't seem to suggest by its name what context it's meant for).

But not sure how best to address this inconsistency.