Dark Mode

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix(label): fix label rich style does not inherit the plain label style#20977

Merged
plainheart merged 2 commits intomasterfrom
fix/rich-inherit-plain-label
May 16, 2025
Merged

fix(label): fix label rich style does not inherit the plain label style#20977
plainheart merged 2 commits intomasterfrom
fix/rich-inherit-plain-label

Conversation

Copy link
Member

plainheart commented May 16, 2025 *
edited by Ovilia
Loading

Brief Information

This pull request is in the type of:

  • bug fixing
  • new feature
  • others

What does this PR do?

  1. Fixed the rich style does not inherit the plain label style.
  2. Added new option richInheritPlainLabel to control this behavior.

Fixed issues

Comparison

Option Behavior
richInheritPlainLabel: undefined
richInheritPlainLabel: true
richInheritPlainLabel: false

Document Info

One of the following should be checked.

  • This PR doesn't relate to document changes
  • The document should be updated later
  • The document changes have been made in apache/echarts-doc@2ead7c7

Misc

ZRender Changes

  • This PR depends on ZRender changes (ecomfe/zrender#xxx).

Related test cases or examples to use the new APIs

See test/rich-inherit-plain-label.html

Others

Merging options

  • Please squash the commits into a single one when merging.

Other information

...le & add new option `richInheritPlainLabel` to control this behavior.
plainheart added this to the 6.0.0 milestone May 16, 2025
plainheart requested a review from 100pah May 16, 2025 09:37
echarts-bot bot added PR: author is committer PR: awaiting doc Document changes is required for this PR. PR: awaiting review labels May 16, 2025
pull-request-size bot added the size/XS label May 16, 2025
Copy link

echarts-bot bot commented May 16, 2025

Thanks for your contribution!
The community will review it ASAP. In the meanwhile, please checkout the coding standard and Wiki about How to make a pull request.

The pull request is marked to be PR: author is committer because you are a committer of this project.

Document changes are required in this PR. Please also make a PR to apache/echarts-doc for document changes and update the issue id in the PR description. When the doc PR is merged, the maintainers will remove the PR: awaiting doc label.

Copy link
Contributor

github-actions bot commented May 16, 2025 *
edited
Loading

The changes brought by this PR can be previewed at: https://echarts.apache.org/examples/editor?version=PR-20977@2204b1a

100pah requested changes May 16, 2025
// Cascade is supported in rich.
const richTextStyle = textStyleModel.getModel(['rich', name]);
const richTextStyle = textStyleModel.getModel(['rich', name], richInheritPlainLabel && textStyleModel);
// In rich, never `disableBox`.
Copy link
Member

100pah May 16, 2025 *
edited
Loading

Choose a reason for hiding this comment

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

Just some thoughts:

Do we need to simplify it to only support richInheritPlainLabel on the global model?
(I'm not sure)

  • pros:
    • I guess the most common usage of richInheritPlainLabel is when users upgrade to echarts v6, and find that some text style is broken. They can simply set richInheritPlainLabel: false on the global option to revert it, without being bothered by debugging. But if they have decided to not to use richInheritPlainLabel: false and fix the broken style one by one, they can also just modify the text styles directly, but not necessarily set richInheritPlainLabel: false on some specific style option (such as, axisLable, series[i].label, ...).
      • If define richInheritPlainLabel on the global model, that can be declared in types.ts #ECUnitOption. On the contrary, if supporting richInheritPlainLabel every text style, it seems not easy to make a uniform TS declaration. The textStyleModel in this function has been declared as Model, that makes textStyleModel.get('richInheritPlainLabel') return an any type, and pass TS check by chance, but not quite correct.
  • cons:
    • ecModel is not necessarily exist in this function, tho in most cases it exists. Is it appropriate to just ignore the cases that ecModel does not exist? I mean if (ecModel) { ecModel.get('richInheritPlainLabel') } else { /* just treat it as richInheritPlainLabel: true */ }.
    • Is it possible that it is hard to fix the style and have to rely on richInheritPlainLabel: false?

But since no ideal approach, it's also fine to use the current implementation.

Copy link
Member Author

plainheart May 16, 2025

Choose a reason for hiding this comment

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

For the sake of migration, I think supporting the global richInheritPlainLabel option makes sense, and the type is easy to define. But I hope to also support the richInheritPlainLabel option in label style, but keep it undocumented until it is required by developers.

Copy link
Member

100pah Jun 5, 2025 *
edited
Loading

Choose a reason for hiding this comment

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

I found that after this changing, test/pie-label-alignTo-adjust.html throws JS Error in zrender.

The root cause of that Error is related to zr incorrect impl (I'm fixing it.), but not caused by this PR.
However, this PR changes the inheritance behavior, causing the rich style to inherit width from the outermost label style, which trigger the bug code in zr.

Through this case, I realized that:

  • those props, width, height, padding, margin, tag, backgroundColor, borderColor, borderWidth, borderRadius, shadowColor, shadowBlur, shadowOffsetX, shadowOffsetY (in TextStylePropsPart), are inappropriate to inherit.
  • If the default label style (static defaultOption = ...) has props (such as, align verticalAlign, and in GauseSeries), we change the inheritance behavior, that may cause a breaking change. Also need to consider that some default style is set in emphasis state. And users have to reset them in each rich style to correct the style - that might cause the config more complicated than no inheritance.

Thus should we only conservatively only allow inheritance in TEXT_PROPS_WITH_GLOBAL, i.e., 'fontStyle', 'fontWeight', 'fontSize', 'fontFamily', 'textShadowColor', 'textShadowBlur', 'textShadowOffsetX', 'textShadowOffsetY' - they are meant to be inheritable (has been inheritable from global option).

Moreover, I found that it's not a correct way to implements the inheritance by

const richTextStyle = textStyleModel.getModel(
['rich', name],
richInheritPlainLabel !== false ? textStyleModel : void 0
);

See test/pie-dataView.html, that breaks the rich text in pie, because in that case the textStyleModel is the model of each item and the rich should be fetched from the original textStyleModel.parent.

Regarding impl, because in another branch I encountered this issue, I just try to fix that in this way:

#21016

echarts-bot bot added PR: revision needed and removed PR: awaiting review labels May 16, 2025
100pah previously approved these changes May 16, 2025
echarts-bot bot removed the PR: revision needed label May 16, 2025
plainheart dismissed 100pah's stale review via 2204b1a May 16, 2025 17:57
echarts-bot bot added the PR: awaiting review label May 16, 2025
pull-request-size bot added size/S and removed size/XS labels May 16, 2025
100pah approved these changes May 16, 2025
echarts-bot bot removed the PR: awaiting review label May 16, 2025
plainheart merged commit b7d4893 into master May 16, 2025
2 checks passed
Copy link

echarts-bot bot commented May 16, 2025

Congratulations! Your PR has been merged. Thanks for your contribution!

plainheart deleted the fix/rich-inherit-plain-label branch May 16, 2025 18:10
Ovilia added a commit to apache/echarts-doc that referenced this pull request Jul 2, 2025
echarts-bot bot added PR: doc ready and removed PR: awaiting doc Document changes is required for this PR. labels Jul 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

100pah 100pah approved these changes

Assignees

No one assigned

Projects

None yet

Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

[Bug] Font style does not apply to year label

2 participants