Different heading sizes for Multicolumn

[allylane]

PR Summary:

This introduces different size options for headers in Multicolumn

Testing steps/scenarios

• Open the editor
• Add a Multicolumn Section
• Experiment with sizing

[kjellr]

👋 I tested this out, and the only issue I'm seeing is that the heading size control on the Multicolumn section itself doesn't appear to have any effect:

This definitely introduces a little conflict there... if heading size is set at both the Section and Block level, what's the most intuitive way to determine which one sticks? (My gut is that the one on the block would have prominence over the section-level setting. It would be cool if we could convey that in the UI somehow, but I don't think we'll have that ability technically.)

Update: 😂 I see now that the setting there only applies to the heading for the multicolumn section, not for the column headings. We're all good in that case.

[andrewetchen]

This looks good to me.

I approved this on the notion that the multicolumn section never had a heading size block level setting and that it would also benefit from having the same, Extra large heading size option that was recently added to the rich text section > heading block.

[melissaperreault]

Hey team! I am very excited to see more flexibility added to the theme!

Notes

• We have this wider issue listing all the places we should include a size setting [Parity] Heading size #1488. I would love if we could link and refer to that issue so we can keep track of the progress of any upcoming improvement we are making regarding each subject. (Please note, this is a few months old, might need an update!)
  • There is a note on that issue that we need to investigate what to do for smaller heading block level reference versus section heading as they don't share the same minimum or maximum sizes yet, more details below. We basically need to align on the right pattern to implement across as a system.

Questions

• Who is the owner of keeping track of what we add to the missing pieces? We have a few dependencies, using the PR template would help inform what are the changes are introducing by this PR for release notes and inform help docs of the new addition when we release for instance.
• Where can we see this documented back in Figma?
• Are we following a specific plan/strategy to introduce these new options?
• Have we consider adding the same options to the section Heading too?

Potential new "inconsistencies"

A little more on "we haven't discuss as a group the standardization" of if Small, Medium, etc options are scalable for the different usage we need depending on the text hierarchy on the page. Right now, Small option might mean something in a section, and something else on another. Example below:

• A section heading (Multicolumn)

  • Small = h2
  • Medium = h1
  • Large = h0

• A block heading (Multicolumn)

  • Small = h2
  • Medium = h1
  • Large = h0
  • Extra large = hxl

• A block text (Announcement bar PR)

  • Small = h5
  • Medium = h4
  • Large = h3
  • Extra large = h2

cc. @danielvan @kimberlyoleiro @nicklepine

[danielvan]

This was done as part of the calibration weeks work, but you raise a few good points – linking back to the main PR is definitely important.

I think small meaning different things at different places are fine, as long as the context is clear: if something is called heading, I'd expect it to be bigger than something called text or body copy. For instance, body small to me sounds smaller than heading small. That said, I wouldn't be surprised if in the future we move to numbered sizes "e.g. header 1", or less verbal ways of defining size. The point above is very important to define next! Thanks for flagging, @melissaperreault

To the other points: I think we can push to use the PR Templates moving forward, but in terms of governance on the missing pieces – is there any place where we can start? Or is it better to hold-off for now while the audits are being done and synced by our teams?

I don't think there is documentation back in Figma, and we haven't followed a plan besides introducing values that were available into other areas. Again, if there is a system for governance started that'd be great but it feels like the audits and sync will give us clarity on it and a path to a plan.

My recommendation, moving forward, is that we hold on adding any other parity elements proactively and when the time comes (either calibration weeks or FEDs are allocated to it), we discuss how to manage this based on what we find out in the audit and roadmap for teams moving forward.

We could take some inspiration to build a parity Github Project board when it comes to it.

[andrewetchen]

Hey team,

The probot-CLA was recently deprecated and replaced with the shopify-cla action.

To successfully use the new shopify-cla status check, this PR will be closed and reopened.

Thanks and sorry for the minor inconvenience. Message me if you have any questions 😄

Please refer to the following for more information:

• Migrate off probot-CLA to new GitHub Action #1859
• [Workflows] Add reopened activity type to CLA check #1874

[kjellr]

Hey is this something we plan to pick back up at some point? GitHub keeps pinging me about it, but it sounds like the latest is that we're planning to hold off on piecemeal updates?

[danielvan]

Moving to our backlog so we can prioritize next.

…

On Wed, Nov 30, 2022 at 1:04 PM Kjell Reigstad ***@***.***> wrote: Hey is this something we plan to pick back up at some point? GitHub keeps pinging me about it, but it sounds like the latest is that we're planning to hold off on piecemeal updates? — Reply to this email directly, view it on GitHub <#1841 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABM3F64DKRHWTNMJ4PJ7Y4DWK5GHPANCNFSM52W55KYQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>