Changing font family should result in 400 for font weight

[miina]

Bug Description

Sometimes when changing the font family, "multiple" is shown as the font weight even if multiple font weights haven't been defined within the text.

It might be that the new font family doesn't have the font weight assigned and that causes it but this needs verifying.

Expected Behaviour

• No input field for a single selected element should ever have a "multiple" value.

Display the closest available font weight?
TBD by UX

Note: whatever is chosen should be displayed in the design panel and also for the text itself, too -- meaning applying it to the element content.

Steps to Reproduce

1. Add text element
2. Assign font family Open Sans Condendsed, font weight Light
3. Now change the font family to Playball
4. See "multiple" as the font weight.

Screenshots

Additional Context

• Plugin Version:
• Operating System:
• Browser:

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance Criteria

Implementation Brief

[miina]

Note: UX Needed to decide if we should assign the closest available value or the default value if the previous font-weight is missing.

[miina]

cc @barklund for visibility since you implemented processing the content of the text for getting the font weight -- perhaps there was already some discussion on what should happen if the new assigned font family doesn't have the previously assigned font weight.

[barklund]

There's a larger underlying issue here about actually changing the inline font weights to available ones when changing font rather than "just" showing another value in dropdown. This was left as an open question in #1323.

[miina]

Updated the description for clarity to specifically mention that it should be applied to the text, too.

[barklund]

This also begs the question: What happens if the user tries to bold a text (using keyboard shortcut or button) with a font, that doesn't support bold? Should we disable the button even or do we use faux-bold?

CC @pbakaus, @samitron7.

[pbakaus]

/cc @o-fernandez

My vote goes to allowing 'faux bold' (system level bolding) as fallback for when there's no bold variant.

[barklund]

Let's say I have a text in Roboto supporting many weights and I have some text in there in all of these weights:

300
400
500
600
700
800
900

I then switch to a font, only supporting 300 and 400. What happens then? Do we add 700 as a "supported" weight even though the font doesn't support it and collapse all to the nearest font weight like so?

300 => 300
400 => 400
500 => 400
600 => 700
700 => 700
800 => 700
900 => 700

Alternatively we round down, so 600 => 400.

Or we don't support bold at all - for many grotesque display fonts faux-bold won't make sense anyway, so showing a button for it but not actually visually changing the font would be senseless.

[o-fernandez]

We discussed this in a recent call and agreed to fixing this. No "multiple" shown, we'll just have to do approximations in some cases. When switching fonts it is ok to approximate to closest supported weight and/or default to "normal".

[samitron7]

@miina "Multiple" is a bug. To be clear, no input field for a single selected element should ever have a "multiple" value. Multiple only appears when you select multiple elements that share a similar attribute like color, opactiy..etc.

And ditto to approximating then default to normal as a fallback

[miina]

@miina "Multiple" is a bug. To be clear, no input field for a single selected element should ever have a "multiple" value. Multiple only appears when you select multiple elements that share a similar attribute like color, opactiy..etc.

@samitron7 Yes, this is a bug issue, reported to address the problem to ensure that "multiple" wouldn't appear unexpectedly. Will update the "Expected behavior" to mention that "no input field for a single selected element should ever have a "multiple" value".

[samitron7]

Thanks Miina. I think I also filed a separate ticket a long time ago to change "multiple" to mixed because "multiple" is too long of a word to fit inside some input field and not sure where that came from >__<.

[o-fernandez]

The original issue, what this ticket is trying to solve, is the scenario in which:

• I start with an element with font family A, and a valid font weight (let's say Bold)
• I switch font family from A to B, and suddenly the font weight drop down shows "multiple"

We want to avoid that scenario. Since there is actually just one font weight being used, not multiple, we shouldn't show multiple because the font wasn't resetting to a valid, available font weight.

In the GIF you added #4734 (comment) I see that the base case is that you do have multiple font weights in the font element. In that case, when you change the font family if you still have multiple font weights it's perfectly fine to have "multiple" in the font weight drop down, both before and after changing the font family. Ideally, we'd want font weights to be one of the valid font weights for that font family, but I don't think that's required for this bug.

So, to clarify acceptance criteria for this bug;

• We just want to ensure that if you only have one font weight in the entire text element, and you switch font families, then you don't end up with font weight shown as "multiple" just because the existing font weight is not a valid font weight for the new font family.
• In that scenario, it's preferable to reset to something else -- we agreed it was simplest to reset to regular / 400 or closest available.

[BrittanyIRL]

thanks for clarifying the acceptance criteria here, @o-fernandez - i think i have a working solution, i'm going to reexamine it first thing Monday and then I'll update the PR and clarify here that it's working as expected.

[BrittanyIRL]

Hey @o-fernandez -

Thanks again for the clarification. It turns out that just updating the "mixed" value for single font weights is impossible because we can have a variety of ways the text element is "selected" or in focus so it's hard to tell if we have 1 font weight or some inline weights set. Given that, I combined your focused directives with feedback from Morten and have the following:

• When there is only 1 font weight in an entire text element and you switch font families, you will not end up with "mixed" - formerly "multiple" (placeholder was updated over the lifespan of this branch).
• When an existing font weight is not available when you make said switch of font families, we will get the closest available weight to that previously existing weight.
• When you have multiple font weights and you switch weights, if you have the entire text element in focus you will still see "mixed", BUT when you enter that text element, if you had "light" selected but now only regular or bold are options, it'll update the selected weight to be regular when you make that portion of text element active again.

I believe this takes care of the bug and could allow future edge cases surrounding the specifics to inline styles and the faux selection process that can sometimes inhibit the above updates occurring to be handled on a granular level with the attention it'll deserve since that will necessitate updates to more functionality.

Thoughts?

[o-fernandez]

That sounds good, @BrittanyIRL, thanks much!

[csossi]

Verified in QA

[csossi]

Verified in QA