feat: new theme for ECharts 6.0

[Ovilia]

Brief Information

This pull request is in the type of:

• bug fixing
• new feature
• others

What does this PR do?

This PR proposes a new default theme for Apache ECharts 6.0.

Design Concepts

Key Words: Modern, Confident, Versatile

Challenges

We have observed that many Apache ECharts users use the default theme in their actual products, which presents a significant challenge for us to provide an excellent default theme. When designing the new theme for 6.0, I aimed to address the following issues:

1. Component overlap: Since ECharts components (chart grid area, legend, title, etc.) use absolute positioning and components cannot easily share position information, components often overlap in many scenarios
2. Inconsistent design language: Existing code often uses literal color and distance values, resulting in arbitrary use of colors (especially neutral colors), distances, shadows, and icons across different components, lacking the aesthetic appeal of a cohesive design
3. Aesthetic issues: Some components have too little whitespace, making the layout feel crowded and too close to the edges, lacking a sense of psychological security

Solution

Therefore, I have defined color and distance tokens uniformly in the tokens.ts file. By referencing these variables, we can ensure design consistency and improve code readability. Then, I refined the spacing and positioning of each component and chart to ensure elegant display under different chart types and series quantities.

In terms of theme color design, I chose colors with higher value (brightness), injecting more modern vitality into the charts, conveying a confident and clear visual language that makes data expression more attractive. The new color scheme is bold and innovative while maintaining continuity - the first two theme colors (blue and green) retain their hue, preserving familiar visual anchors while injecting freshness into the overall style.

Before & After

In test/theme-list.html, I have provided examples of typical chart types and components with series quantities ranging from 1 to 9. Here, we will explain some typical charts.

Typical Charts

Let's start by experiencing the new design with common 4-series bar and pie charts.

ECharts 5	ECharts 6

In ECharts 5, the title and legend often overlap. Before we come up with a better layout plan, I moved the legend to the bottom, not only avoiding overlap but also creating a more balanced layout visually with the title. We left more space at the bottom of the grid to prevent overlap even with multiple legend items, and enabled containLabel by default to ensure axis labels don't exceed the canvas when data values are large.

ECharts 5	ECharts 6

Theme Colors

To handle different chart usage scenarios, we need to ensure the theme colors look harmonious with different numbers of series. Below, using bar charts as an example, we show the effects with 1-9 series, and then explain how we balance the design as series number varies.

ECharts 5	ECharts 6

How to Ensure Theme Color Harmony

The biggest challenge in designing theme colors is how to ensure distinction while maintaining overall harmony when there are many series?

Warm-Cool Consistency

This inspiration came from a painting course where I learned this technique: when multiple colors are needed in a composition, overall harmony can be achieved by unifying the warm-cold nature of the colors.

In the image above, we can see that colors with consistent warm-cold tones appear more harmonious when grouped together. In the theme colors I propose, I use colors that lean towards cool tones because cool colors give a sense of professionalism and trustworthiness, which is more suitable for most chart scenarios.

Value and Lightness Variation

If we carefully observe the three-series bar chart, we can see that the color scheme in 6 is more harmonious than 5. Why is that?

ECharts 5	ECharts 6

After converting to grayscale, we can see the reason more clearly.

ECharts 5	ECharts 6

When lightness follows a monotonically linear progression (as seen in ECharts 5's first three series), it introduces visual instability. By implementing dynamic lightness modulation through non-linear curves, we achieve both enhanced accessibility and harmonious aesthetics.

ECharts 5	ECharts 6

Besides lightness, value also needs this kind of variation, so the third theme color uses a lower value to make the overall look more balanced. If the third theme color used a similar value (like the orange we ultimately placed in the fourth position), although it wouldn't feel out of place, I think it would lack some sophistication from an aesthetic perspective, as it would be like a tripod lacking focus, making it an unstable design.

If the third theme color used similar value, although acceptable, lacks sophistication	The third theme color actually chosen in this PR

Common Charts and Components

Due to space limitations, we cannot show the effects of different series quantities for various charts here, only showing the effects with four series as an example. The complete examples can be found in the zip file attached. echarts-themes-v5-vs-v6.zip

Bar Chart

ECharts 5	ECharts 6

Hid axisTick for 'category' axis because in most cases, the distance relationship already indicates grouping information, and axisTick is not needed for precise division. Removing it makes the visual more continuous and reduces unnecessary redundant information. More space is left at the bottom of the grid to prevent overlap when the legend has two rows.

Line Chart

ECharts 5	ECharts 6

Increased lineStyle.width and symbolSize, making the overall look more modern and confident. The original symbolSize was too close to the line width, lacking distinction, thus not aesthetically pleasing.

Pie Chart

ECharts 5	ECharts 6

Reduced radius to add more whitespace for aesthetic appeal and avoid overlap with other components. Increased labelLine width.

Scatter Chart

ECharts 5	ECharts 6

Funnel Chart

ECharts 5	ECharts 6

Treemap Chart

ECharts 5	ECharts 6

The original layout used percentage positioning on the left and right, which was changed to fixed pixel size, and this size is the same as the margin used by other components (such as heatmap controls, Toolbox, etc.). The original breadcrumb dark gray background was visually too heavy, but logically it's not the main information, so it was changed to a light gray background.

Sunburst Chart

ECharts 5	ECharts 6

After Drilling Down, ECharts 5	After Drilling Down, ECharts 6

Originally, the first theme color was used for the drill-down return node, causing the default view to start from the second theme color, making it look different from other charts. Therefore, it was changed to use gray for drill-down nodes.

ThemeRiver Chart

ECharts 5	ECharts 6

Random data so it doesn't look very similar, but this chart actually didn't have significant changes.

Timeline

ECharts 5	ECharts 6

Adjusted colors to avoid using gray which might be mistaken for disabled state. Redrew icon SVGs to maintain width consistency. Removed strokes and shadows because ECharts' overall design is flat, and shadows should be avoided when they don't help prevent misunderstanding.

DataZoom & Toolbox

ECharts 5	ECharts 6

Adjusted colors to avoid using gray which might be mistaken for disabled state.

VisualMap & Calendar

ECharts 5	ECharts 6

ECharts 5 used a red to yellow gradient, but this color only appeared in VisualMap, lacking connection with the overall design. It was adjusted to a gradient related to the first theme color to make it more consistent with other charts and avoid the warning implications of red, since larger values don't always indicate better or worse. The VisualMap control has more whitespace on the sides, with this distance matching the margins of other components. Slightly adjusted Calendar colors.

Map

ECharts 5	ECharts 6

The yellow highlight background in ECharts 5 maps wasn't used anywhere else, making it inconsistent with the overall design. Actually, this highlight is similar to the color lifting after emphasis in bar charts, but making it lighter made it hard to see, so it was changed to a slightly darker background color.

Dark Mode

Examples of some dark mode charts:

To see more cases, toggle system dark mode and check test/theme-list.html. (ecomfe/zrender#1118 is required for zrender).

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#xxx

Misc

ZRender Changes

• This PR depends on ZRender changes (feat(color): support function for modifyHSL ecomfe/zrender#1118).

Related test cases or examples to use the new APIs

N.A.

Others

Merging options

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

Other information

[echarts-bot]

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.

⚠️ MISSING DOCUMENT INFO: Please make sure one of the document options are checked in this PR's description. Search "Document Info" in the description of this PR. This should be done either by the author or the reviewers of the PR.

[github-actions]

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

[diysimon]

Very professional design, looking forward to the official release of 6.0！

[Russiarain]

Great design! Just one question, will there be enough contrast to the surface(maybe #1e1e1e) in dark mode for the third theme color?

[100pah]

@Ovilia

Great design and the very detailed explanation!

And I only list some issues I come up with:

backward compatibility

A theme of echarts v5 is needed if v6 modify the default settings.

The new design changes numerous default position and size settings.
Users typically use a mix of default settings and custom configurations.
Therefore if upgrading to v6 break the layout and appearance and require significant effort to restore, it may discourage users to upgrade.

For example, previously the legend is on the top by default, but after upgrading to v6, the legend move to the bottom and overlap with other components (like dataZoom and timeline - all layout at bottom by default):

            // A simple option
            option = {
                title: {text: 'Price line chart'},
                legend: {},
                dataZoom: {},
                xAxis: {type: 'category', data: xData},
                yAxis: {type: 'value'},
                tooltip: {trigger: 'axis'},
                series: [
                    {name: 'price1', type: 'line', data: data1}, 
                    {name: 'price2', type: 'line', data: data2}
                ],
            };

The result:

The legend overlaps with datazoom:

ECharts 5	ECharts 6

The legend overlaps with timeline:

ECharts 5	ECharts 6

Regarding the colors

I'm just describing my intuitive feelings - others may have opposite feelings.

The 1st color

I feel the new version is great.

The 2nd color

I prefer the v5 slightly, because I feel the new version is a bit too "sharp" or "shiny" (or over saturated?) - especially over large areas. A "shiny" color can feel tiring to look at after a time in front of the screen.

And a light color make its corresponding label less visible. The label color has the same color if outside, be white color in inside - both of them are less visible:

The 3rd color

The 3rd color has a significant change. I'm worried about the new version is too close to greyscale colors. From my understanding, the greyscale colors are preferable to be used in auxiliary components, such as axis and labels/texts, while chromatic colors are typically used in shapes/glyphs that represents data. All of the other colors seem to conform with that idea, except the new version of the 3rd color. And if it is used over a large area, it gives a feeling that combinating grayscale and color-scale colors - a bit disharmonious.
When the line is near zero, it might not be noticeable enough:

Another case listed below "Regarding the hiding of axis tick" show a bad case that the color is too close to label text color - cause misleading between label and its corresponding shapes/glyphs.

Russiarain mentioned that whether the 3rd color applicable for the dark mode. I've noticed that in this PR the default dark mode seem not changed and this 3rd color is not used. (I think is OK to not to change the dark mode)

Regarding the highlight/emphasis color of map

I think this is a significant change from a yellow to grey. I personally strongly prefer the v5 version yellow. That color serves both "hovering-highlight" and "select" - especially in mobile, there is no "hovering" but only "select". If changed to a grey, the selected regions will be less visable. And if only regarding the hovering, the original yellow is noticeable. I think "the yellow is inconsistent with the overall design" is not a concern, since users typically use map individually and do not combinate maps with other types of chart. And actually I can not feel that inconsistency - the original yellow is still harmony.

Regarding the visual map color

My question:

1. In most case "the large value corresponds a weight color" is correct - especially in heatmap and calendar.

For example in github contribution map

But the example above reverse it. I think our default color should still be "the large value corresponds a weight color".

2. Does the default color changed in heatmap from red to blue? A "pure blue" color is probably not applicable as a default color for heatmap. If searching "heatmap" on search engines, most heatmaps use colors: "red-data high, blue-data low". Therefore that is probably a common sense. The word "heat" intuitively imply "red" in most cases. I think "connection with the overall design" should not be a concern in this case, since the default color should be primarily match the most common cases for these chart/coordsys.

In fact, I think the color used in test/matrix_application.html is more widely applicable:

Regarding the hiding of axis tick

I fond that removing axis tick on bar chart is worse than showing them:

This is a simple case. Without the hint of axis tick, the space is not noticeable enough to visually indicate the bar groups. Additionally, the 3rd color is too similar to the axis label color, make me intuitively wrongly recognize the axis label were only the 3rd bar's label, rather than the label of a group of bars on that axis tick.

This is another case, the x axis is a category axis (quite common that use category axis represent time in practice). No tick is worse to indicate the connection between label and accurate tick.

Therefore I prefer the default setting should be conservative to most cases, using a axis tick is more clear and necessary in many cases.

[Ovilia]

In the above commit, I added a new option grid.containDataZoom. Similar to containLabel, it adjust grid position to make room for dataZoom. @100pah Do you feel this is the correct way to fix the problem?

v5

v6

Option is:

{
  show: true,
  realtime: true,
  start: 30,
  end: 70
},
{
  show: true,
  realtime: true,
  yAxisIndex: 0
}

and

{
  show: true,
  realtime: true,
  start: 30,
  end: 70,
  top: 50
},
{
  show: true,
  realtime: true,
  yAxisIndex: 0,
  left: 25
}

[Ovilia]

Updated funnel label style to be compat with pie.

Changed map emphasis color to be yellow.

Tick: use 'auto', when boundaryGap: false, it should still show ticks.

[100pah]

I think the default year should not be that dark since it has been a large text, but the month and day label should be dark because they are more important ticks than year (they are like axis ticks in cartesian).

-- new style ---

-- previous style ---

-- github contribution --

And a light month and day label will bring that bad case in dark background:
-- new style --

-- previous style --

[Ovilia]

Changed the year label to be a lighter gray, but not as light as v5. I don't quite believe we should make it lighter since it's larger. It's larger because it's more prominant, so it gives more reason to make it darker.

Dark background should not be considered in this case. If user wants to use dark background, he, or the one who makes the dark theme should be responsible for changing the label colors to fit the background. And whatever color you choose for the default label, it's still possible that the user set the background to a similar color (a black background for example).

[Ovilia]

Here is the report of visual tests using current remote v6 branch and local code with v5.js theme file. There are only two imcompatible changes:

1. Sunburst series color

In v5, the first theme color was used for the drill-down return node, causing the default view to start from the second theme color, making it look different from other charts. Therefore, it was changed to use gray for drill-down nodes and series use theme colors starting from the first one instead of the second one.

2. Loading spinner and text color

Since these colors are not using a registered theme, it cannot be override. But the change is acceptable.

All other diffs in the test report are due to the false alarm of the visual test tool and should be ignored.

In the last commit, I implemented a way to support "Mark As Expected" Feature for the test tool so that we can see clearly in the report which diffs are expected.

Here is the full report:
Visual Regression Test Report-v6-theme.html.zip