Tiered List HOC/Pattern

[pastelcyborg]

Done

• Added new Tiered List macro which supports all variants from Figma
• Added example pages for each Tiered List variant, as well as a combined page
• Added new docs page for Tiered List, showcasing new Macro documentation
• (Drive-by) Add doc updates to separators clarifying usage
• (Drive-by) Add new variants_all scss file for combined usage

Fixes WD-13041

QA

• Open docs page and each new Tiered List example on the examples page
• Review Tiered List pattern, Macro, and documentation

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

[bartaz]

In the CSS version currently we still seem to rely too much on HTML structure and having a lot of structural elements. All those custom rows/cols nested are something I'd like to avoid, because if we need to do that, there is almost no benefit of just using standard grid.

First of all we should get rid of <hr>s. If we are writing CSS we should use borders, not depend on <hr> existence.
Then we should try to create somewhat semantic HTML structure rather than recreate a grid "rows" and "cols".

Somewhat like that (although I guess it may not cover all cases we need):

.p-split-list // extends row (50/50 or full width)
     .p-split-list__heading // extends column (size depends on layout)
         h2
     .p-split-list__list // extends column (size depends on layout)
         .p-split-list__list-item // extends a row (nested)
              .p-split-list__list-title // extends column in nested row
                   h3.p-heading--5 / h3.p-split-list__list-heading
              .p-split-list__list-content // extends column in nested row
                   p // not sure if we need paragraph there? can there be more than 1 paragraph of text there?
         .p-split-list__list-item
              .p-split-list__list-title
              .p-split-list__list-content
     .p-split-list__cta

[bartaz]

Nice to see macros giving some value.

Some questions inline in the code.

[pastelcyborg]

Did some experimentation with ways to provide HTML to macros. Generally uninspiring results:

• Multi-line strings are supported and seem to work okay
• Couldn't get include working in any sort of combination with macro params
• Couldn't get JS template strings working with macro params
• Can kind of do multiple caller() blocks, but its utility is quite limited: https://stackoverflow.com/questions/23964579/does-jinja-support-multiple-blocks-in-a-macro
• Could possibly use kwargs/varargs to supply an indeterminate number of params to macro, then use include calls within the macro itself to pull in separate template content, but again, kind of limited utility
• Could possibly use include with instead of macros in some instances

Overall I'd probably just stick with strings/multi-line strings to begin with. If we wanted fancier support for include with macro params, we'd probably need to write some new functionality in Python to create an abstraction of macro that can perform such functionality, since Jinja does have Python helper functions to store include contents as strings, which we could then pass as macro params, etc. It doesn't seem like these sorts of helpers are exposed to Jinja templates, unfortunately.

[bartaz]

I believe we talked about not calling it "Split list" (because of split list component). In Figma it's currently called "Key value", but I'm not a huge fan of that name either. I asked there (in Figma) in a comment.

[bartaz]

Ship it 🚢