Skip to content

content: Make **bold** bolder even in spoiler headers and h1/h2/etc. #706

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Jun 5, 2024

Conversation

chrisbobbe
Copy link
Collaborator

@chrisbobbe chrisbobbe commented May 24, 2024

This fixes #705 by making boldness context-dependent, much like we did for some font sizes in #544.

That user-facing change is nice but fairly subtle. I'm also hoping this will be helpful by adding content tests for boldness in the first place; we didn't have any before. And I've set a pattern in the UserMention tests that should help reduce confusion when we write boldness tests for #647. (Confusion mainly related to the fact that UserMention is in a WidgetSpan.)

The need for more helpers in lib/widgets/text.dart is another reminder that it'll be great to have flutter/flutter#148026 fixed upstream. But (as with the existing helpers there) I'm hoping this handles things in a way that makes it straightforward to migrate once that's done.

Fixes: #705

Before After
75927CB2-41BB-415B-9530-CE418DBB9368 445F7D01-3E38-4A19-B5CD-7746474655D5

@chrisbobbe chrisbobbe added the integration review Added by maintainers when PR may be ready for integration label May 24, 2024
@chrisbobbe chrisbobbe requested a review from gnprice May 24, 2024 21:27
@chrisbobbe
Copy link
Collaborator Author

chrisbobbe commented May 24, 2024

Screenshots for the last commit. ("h1: regular" has weight 900, and "bold" has weight 1000…I don't see much of a difference there , but that's fine. This might be a reason to drop the last commit; distinguishing a bold span from surrounding text seems important and worth preserving as completely as possible.)

Before After
B2CBF31C-9538-4C4F-B3EF-E0FCA1B0215D AAE42E6F-D39D-4CEF-A671-D8AC4D8A5DCA

@chrisbobbe
Copy link
Collaborator Author

Oh, and here are versions of all the above screenshots with the system "bold text" setting on:

Before After
349819CE-5D35-41E6-8C26-4F5C79401034 5A4FD1BB-8AC8-4824-B8ED-D8F59AA7A699
87C61FD1-EE31-4393-8D22-9EDB0C5D0D3F FA2E9B62-0E17-41C4-AD0E-52FCBADF22DF

Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Various nits below.

Screenshots for the last commit. ("h1: regular" has weight 900, and "bold" has weight 1000…I don't see much of a difference there , but that's fine. This might be a reason to drop the last commit; distinguishing a bold span from surrounding text seems important and worth preserving as completely as possible.)

Hmm, yeah. What does a screenshot look like without that last commit? (That last commit being:
a4604c7 content: Make h1 font weight combine with spoiler-header font weight
)

/// setting, so if the [TextStyle] was built using [weightVariableTextStyle],
/// this value might be larger than the `wght` that was passed to that function.
double? wghtFromTextStyle(TextStyle style) {
double? result = style.fontVariations?.singleWhereOrNull((v) => v.axis == 'wght')?.value;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
double? result = style.fontVariations?.singleWhereOrNull((v) => v.axis == 'wght')?.value;
double? result = style.fontVariations?.firstWhereOrNull((v) => v.axis == 'wght')?.value;

The "single" behavior means that if for some reason there are multiple wght variations, this would ignore them all and fall back to fontWeight. That doesn't seem intended.

I don't feel a strong need to have this code check that there aren't multiple of them. (In fact it looks like its one caller already has an assert to that effect.) If we're not going to check, then it should just do the simplest thing, which is to break the loop and return as soon as it finds one. That's what the "first" version does.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense; I agree.

@@ -154,6 +155,43 @@ void main() {
});
}

/// To check font weight, set up tests with and without bold-text setting.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "To check" here reads like it's an instruction: "If you want to check font weight, set up tests thus-and-so."

A direct fix for that would be:

Set up tests with and without bold-text setting, to check font weight.

But I feel like what I want in the summary line is more of a description of what the said tests will test. Here's a version:

Suggested change
/// To check font weight, set up tests with and without bold-text setting.
/// Test the font weight found by [styleFinder] in the rendering of [content].
///
/// The weight will be expected to be [expectedWght] when the system
/// bold-text setting is not set, and to vary appropriately when it is set.

/// [styleFinder] must return the [TextStyle] containing the "wght"
/// (in [TextStyle.fontVariations]) and the [TextStyle.fontWeight]
/// to be checked.
testFontWeight(String description, {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: explicit return type (so it doesn't look like a function call)

group('strong (bold)', () {
testContentSmoke(ContentExample.strong);

TextStyle findWordBold (tester) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: space

Comment on lines 726 to 729
assert(
style.fontSize != null
&& (
style.debugLabel!.contains('weightVariableTextStyle')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: just use two asserts; formatting gets simpler/shorter, and the two conditions aren't closely related anyway

Comment on lines 800 to 810
return _buildStrong(node);
return _buildStrong(ambientTextStyle: widget.style, node);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to pass this to one of this class's own methods — it can look at widget.style directly, just like this _buildNode method can.

Comment on lines 549 to 529
// **bold**
content: plainContent('<$name><strong>bold</strong></$name>'),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is inaccurate because there's the heading element.

Fine to have this automatic generation of six test cases, just need to adjust the comment. E.g.:

Suggested change
// **bold**
content: plainContent('<$name><strong>bold</strong></$name>'),
// # **bold**, ## **bold**, ### **bold**, etc.
content: plainContent('<$name><strong>bold</strong></$name>'),

@chrisbobbe
Copy link
Collaborator Author

Hmm, yeah. What does a screenshot look like without that last commit? (That last commit being:
a4604c7 content: Make h1 font weight combine with spoiler-header font weight
)

Sure, here it is:

Without that commit With
8AB20836-0A67-4291-B76C-625C323A72E7 C45AAB03-31B3-46CA-85EB-EBCFA64B769B
Bold text setting on: 3C1902DA-BF77-443B-A0E1-A9D209ECB775 Bold text setting on: A6E8AD32-E2AF-4AC1-B261-644F12442BD4

@chrisbobbe chrisbobbe force-pushed the pr-make-boldness-additive branch from a4604c7 to 24a0036 Compare May 31, 2024 06:37
@chrisbobbe
Copy link
Collaborator Author

Thanks for the review! Revision pushed, and see the screenshots I posted just before this. I'd be happy to remove that last commit, this keeping clearer emphasis on bold spans when they appear in h1/h2/etc. in spoiler headers.

@chrisbobbe chrisbobbe force-pushed the pr-make-boldness-additive branch from 24a0036 to 0e911fe Compare May 31, 2024 06:41
Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Looks like the last commit doesn't affect the bold-text-setting-on case (the screenshots look identical to me except for the signal bars at top right), and for the default case I think it's probably better without. So let's drop that commit.

Other than that, one nit below, and then please go ahead and merge!

Comment on lines 834 to 844
InlineSpan _buildStrong(StrongNode node) => _buildNodes(node.nodes,
style: weightVariableTextStyle(_context!, wght: 600));
InlineSpan _buildStrong(StrongNode node) =>
_buildNodes(style: bolderWghtTextStyle(widget.style, by: 200),
node.nodes);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: unnecessary churn here, and makes it look different from the similar neighboring methods; can keep node.nodes first and the existing formatting

Not because we want to make changes that apply here, but just
because this fits conceptually, and this function's dartdoc may be
useful for the reader.
It's reasonable to expect callers to avoid passing around
out-of-bounds "wght" values. If we're at the point of passing an
out-of-bounds value to this function, chances are we're also
rendering some text with that same value, and we shouldn't do that.
@chrisbobbe chrisbobbe force-pushed the pr-make-boldness-additive branch 2 times, most recently from ac5d18b to a659ef8 Compare June 5, 2024 16:46
@chrisbobbe chrisbobbe force-pushed the pr-make-boldness-additive branch from a659ef8 to 1531b9e Compare June 5, 2024 16:47
@chrisbobbe chrisbobbe merged commit 1531b9e into zulip:main Jun 5, 2024
1 check passed
@chrisbobbe chrisbobbe deleted the pr-make-boldness-additive branch June 5, 2024 16:47
@chrisbobbe
Copy link
Collaborator Author

Thanks! Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integration review Added by maintainers when PR may be ready for integration
Projects
None yet
Development

Successfully merging this pull request may close these issues.

content: Bold spans aren't bolder than surrounding text in spoiler headers or h1/h2/etc.
2 participants