Size Change: +663 B (0%)

Total Size: 1.07 MB

_{compressed-size-action}

Quick check-in with @nosolosw (before I start working on migrations): Are we okay with introducing a new top-level fontFamily attribute here (rather than keeping the nested style.typography.fontFamily)? (See block markup examples in the PR desc.)

It seemed to me that style.typography.fontFamily wouldn't make much sense with font family slugs (such as geneva-verdana). If we would like to keep the information in that nested attribute, we should probably spell out the font family (e.g. Geneva, Tahoma, Verdana, sans-serif)?

Furthermore, is it our responsibility to translate the class to a style on the frontend, or is it the theme's to style it accordingly? (I guess it's ours?)

Curious to hear your thoughts.

Worked a bit on this today and this is working. Tasks left are: block deprecations + update tests.

I've picked up this today and updated the tests. The remaining step is to add block deprecations.

I've pushed the last bits necessary to land this, and it's ready.

Don't we need to update all button block deprecations younger than a given cutoff date (rather than older), in order to catch the ones that were introduced during the time that the font family related attributes have been around?

That's correct! It was also what I meant but my English skills are failing me, apparently 👼

Also, I'm not sure about the cutoff date? I see migrateFontFamily in deprecations that seem to have been added in
September 2019 or one that seems to have been added in April 2020, but not another thinking (judging by the commit dates of the surrounding lines according to Git Lens).

Great catch. I was misguided because I checked the lines of those migrations that were actually modified later (to add newer migrations).