A better approach for content authoring in Merch cards.

[Axelcureno]

Last year, we (Milo commerce team) introduced a new way to author content inside Merch cards that we thought would enable to be consistent with the Consonant specs. This thread is a follow-up to open for discussion a possible new, better way to create merch cards in Milo using Sharepoint.
That respective approach consisted of a one-to-one mapping of Consonant character style tokens and Sharepoint character styles.
The mapping being the following:
H5 => detail-m H4 => body-xxs H3: => heading-xs H2: => heading-m

By going with this approach, it is guaranteed that the authored content will match the Consonant design specs, which is the direction we were given by the Studio team.
As we have stated repeatedly, Merch cards are not intended to be used with content that is different from what is specified in the design specs. Apart from that, given that these cards are made using Lit Web Components, the option of freely add any content to the cards is technically not feasible since the content is populated inside slots and these slots have the styles from the Consonant specs.
Although this one-to-one solution works as expected, it also introduced other challenges including:

• Making authors memorize or reference the mapping.
• Having heading tags in an incorrect hierarchy order thus affecting accessibility and SEO (there is already a solution for this).

Since the solution for number 2 is to rewrite the tag names of the headings in a cascading order, an idea came to my mind when reading @rgclayton's comment in my PR, which is to replace the one-to-one mapping approach with a variant-specific mapping that contains the exact heading names in the correct order.
That means an author could write any heading in Sharepoint and the variant mapping in Milo would take care of setting the proper slot name in the order they are authored in Sharepoint. For example, when authoring a Special Offers Card:

And the variant mapping would be something like:
const variantContent = { 'special-offers': ['detail-m', 'heading-xs', heading-xs'], rest of variants.... }

With this approach, which would be backward-compatible, authors won't have to worry about which heading they must choose to have their merch cards display content properly.

As always, we would love to hear other's feedback.
Am I missing something here that would not make the proposal work?
If you're an author reading this, how do you feel about this idea? Should we leave things as is?

[npeltier]

hey @Axelcureno i think i like this better, even if the point you mentionned:

Making authors memorize or reference the mapping.

gets even more true in that case, as here there would several orders to memorize. This said though this gives more importance to the variant, and once known i guess there will be no problem.
Another good aspect to me is it sounds less magic, more obvious.

side note:

Apart from that, given that these cards are made using Lit Web Components, the option of freely add any content to the cards is technically not feasible since the content is populated inside slots and these slots have the styles from the Consonant specs.

This sounds like lit or web components or both are preventing us to do something. I would rather say this technical limitation is added by us, to reflect a business limitation if you want to call it like that, that is consonant design.

[Axelcureno]

You've said it well better, Thanks for better explaining the point I tried to make.

[npeltier]

One thing came to my mind though, @Axelcureno :
i've been using the mapping recently to move prices at the right place with the right format.

if i need to put price in heading-m area let say, with the title, this would be handled by your slot sequence?

[Axelcureno]

Yes, correct. Once the price is converted into a heading, the slot would be populated automatically in the correct sequence.

[yesil]

I love this idea.
With this approach, once PR is merged, GWP can go and progressively update H2s to H3s without fearing that this would break anything.
However we should be careful and check ahead whether this would break any existing card.

[Axelcureno]

I agree. I will create a story for this and will have to test extensively.

[auniverseaway]

This sounds like lit or web components or both are preventing us to do something. I would rather say this technical limitation is added by us, to reflect a business limitation if you want to call it like that, that is consonant design.

@npeltier We solved this problem is 2021 where an author could make any heading for SEO reasons, but the styling remained on brand. @Axelcureno is 100% right to call this a limitation of Lit & Web Components (really, the use of slots). If these were built with vanilla JS, this wouldn't be an issue.

[npeltier]

well, usage of lit & web components is our decision (not yours, i know :p)
and usage of slot for that as well, that's the point i was trying to make.
yes we could make card vanilla js, we could make our card web component using vanilla js for this, we could make several things, but we went that route :).

[auniverseaway]

https://github.com/adobecom/consonant/blob/main/blocks/marquee/marquee.js#L32-L34

1. Queryselect any heading.
2. Add the appropriate class.
3. Add styles that target the class, not the element.

[yesil]

We are not targeting elements but slots instead of classes.
You can see it at https://www.stage.adobe.com/products/special-offers.html by inspecting cards.
Axel is proposing an incremental improvement in the way of authoring merch cards.
Initially we mapped h2-h6 elements to named slots but for SEO reasons we need to avoid using h2, this reduces the number of slots we can author with the current approach.
The proposal is to use the order of the heading elements no matter tag name and map it to a set of slots per card variant.
Lit and Web Components are fine and have never been an issue so far.