-
Notifications
You must be signed in to change notification settings - Fork 309
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
Conversation
There was a problem hiding this 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
)
lib/widgets/text.dart
Outdated
/// 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; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense; I agree.
test/widgets/content_test.dart
Outdated
@@ -154,6 +155,43 @@ void main() { | |||
}); | |||
} | |||
|
|||
/// To check font weight, set up tests with and without bold-text setting. |
There was a problem hiding this comment.
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:
/// 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. |
test/widgets/content_test.dart
Outdated
/// [styleFinder] must return the [TextStyle] containing the "wght" | ||
/// (in [TextStyle.fontVariations]) and the [TextStyle.fontWeight] | ||
/// to be checked. | ||
testFontWeight(String description, { |
There was a problem hiding this comment.
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)
test/widgets/content_test.dart
Outdated
group('strong (bold)', () { | ||
testContentSmoke(ContentExample.strong); | ||
|
||
TextStyle findWordBold (tester) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: space
lib/widgets/content.dart
Outdated
assert( | ||
style.fontSize != null | ||
&& ( | ||
style.debugLabel!.contains('weightVariableTextStyle') |
There was a problem hiding this comment.
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
lib/widgets/content.dart
Outdated
return _buildStrong(node); | ||
return _buildStrong(ambientTextStyle: widget.style, node); |
There was a problem hiding this comment.
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.
test/widgets/content_test.dart
Outdated
// **bold** | ||
content: plainContent('<$name><strong>bold</strong></$name>'), |
There was a problem hiding this comment.
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.:
// **bold** | |
content: plainContent('<$name><strong>bold</strong></$name>'), | |
// # **bold**, ## **bold**, ### **bold**, etc. | |
content: plainContent('<$name><strong>bold</strong></$name>'), |
Sure, here it is:
|
a4604c7
to
24a0036
Compare
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. |
24a0036
to
0e911fe
Compare
There was a problem hiding this 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!
lib/widgets/content.dart
Outdated
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); |
There was a problem hiding this comment.
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.
ac5d18b
to
a659ef8
Compare
a659ef8
to
1531b9e
Compare
Thanks! Done. |
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 thatUserMention
is in aWidgetSpan
.)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