feat: Create modifier class to 'no-full-stop' be applied to 'p-stepped-list' and it's variants

[petesfrench]

Done

• Create modifier class to 'no-full-stop' be applied to 'p-stepped-list' and it's variants. This removes the full stop and aligns the counter to the left

Fixes https://github.com/canonical/ubuntu.com/pull/14702/files/214ab12ae0503642d147ea6e9f1cfda172c84352#r1940227885

QA

• Open demo
• [Add QA steps]
• Review updated documentation:
  • [List any updated documentation for review]

Check if PR is ready for release

If this PR contains Vanilla SCSS or macro 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 existing APIs (CSS classes & macro APIs) are not changed it can be a bugfix release (x.x.X)
  • if existing APIs (CSS classes & macro APIs) are changed/added/removed it should be a minor version (x.X.0)
  • see the wiki for more details
• Any changes to component class names (new patterns, variants, removed or added features) or macros should be listed on the what's new page.

Screenshots

[if relevant, include a screenshot or screen capture]

[webteam-app]

Demo

Jenkins

demos.haus

[petesfrench]

Hey Vanilla folk, I had to apply this to one of my PRs, so I made a quick PR to demo it. LMK if it is something we would like in Vanilla and I can continue work on it.

[jmuzina]

@lyubomir-popov what do you think of the example?

Default variant:

no-full-stop variant:

More than 9 items:

[lyubomir-popov]

This is a rather opinionated change that hasn't gone through the contribution process on the design side. Can we please ensure we have a discussion via the official contribution process, before we review this pr.

A few open questions:

• Left alinging works well when lists are less than 9 items long. Once we have double digit counters, number alignment rules come into place. Hence the current right alignment. Do we want to support different alignments based on item count?
• A dot is needed when a list has nested list items. If we support variants with and without dots, we'd have to clearly disambiguate when to use which, and what happens if both need to be placed in close proximity

[jmuzina]

Added to DSWG agenda for Monday 10 February.