v5.0+ Tooltip injected css won't respect

urgrund commented 2 years ago

Version

5.2.0

Reproduction link

Steps to reproduce

Example 1 Create a class that has a background color

.test{
  background-color: 'blue';
}

set

backgroundColor  : 'rgba(255,0,0,1)'  ,
className: 'test',

in the tooltip: {} object inside an option

Note that the red value comes through even with a custom class wanting a different color You need to go into F12 devtools and turn off the injected 'background-color' style to observe the custom CSS This holds true for any CSS that eCharts injects into the tooltip.

Making it hard to have custom style.

A workaround is styling the content itself in the formatter: function(){}

BUT, this has next issue...
eCharts >5.0 injects 'will-change:transform' which is breaking custom backdrop-filters (they are fantastic way to really personalize tooltips and have been using for 2yrs with eCharts4) :)

eCharts 4.0 did not inject this property.

What is expected?

Custom provided CSS class should display as expected in a Tooltip
CSS features such as backdropfilter should work as expected in a Tooltip

What is actually happening?

Custom class properties are being overwritten by eCharts CSS
backdrop filters are broken with 'will-transform' injected CSS by eCharts

I have some images I can show for examples but unfortunately this issue reported doesn't have upload?

Below is the injected CSS

element.style {
    position: absolute;
    display: block;
    border-style: solid;
    white-space: nowrap;
    z-index: 9999999;
    will-change: unset;
    box-shadow: rgb(0 0 0 / 20%) 1px 2px 10px;
    background-color: rgba(0, 0, 0, 0);
    border-width: 1px;
    border-radius: 4px;
    color: rgb(102, 102, 102);
    font: 150 12px / 18px Poppins;
    padding: 10px;
    top: 0px;
    left: 0px;
    transform: translate3d(30px, -120px, 0px);
    border-color: rgb(255, 255, 0);
    pointer-events: none;
}

echarts-bot[bot] commented 2 years ago

Hi! We've received your issue and please be patient to get responded. 🎉 The average response time is expected to be within one day for weekdays.

In the meanwhile, please make sure that it contains a minimum reproducible demo and necessary images to illustrate. Otherwise, our committers will ask you to do so.

A minimum reproducible demo should contain as little data and components as possible but can still illustrate your problem. This is the best way for us to reproduce it and solve the problem faster.

You may also check out the API and chart option to get the answer.

If you don't get helped for a long time (over a week) or have an urgent question to ask, you may also send an email to dev@echarts.apache.org. Please attach the issue link if it's a technical question.

If you are interested in the project, you may also subscribe to our mailing list.

Have a nice day! 🍵

Ovilia commented 2 years ago

The ECharts style uses inline CSS so it may have higher CSS priority than class selector. A simple way to override is by using background-color: red !important. And it is not suggested injecting CSS.

urgrund commented 2 years ago

Hi Ovilia, thanks for the response and suggestions! :)

Though I think I might have used wrong terminology. I am talking about the inline CSS that eCharts uses that takes priority over custom class.

The !important solution I feel is just a workaround - custom classes may be used elsewhere in the application, so having to decorate properties with !important just to get around v5 introduced behavior is not ideal.

When providing a class with the className property in a series/option , I would expect that class to take priority. Upon some more testing, the !important workaround does not appear resolve the will-change issue that breaks backdrop filters in eCharts5.

Could eCharts not omit it's own inline css properties conditionally if a custom class is passed in? Or just allow users to have total control through_ custom classes?

Thanks for taking the time to read and if there are any more tests that I could assist with let me know! :)

Ovilia commented 2 years ago

ECharts default styles are inline CSS and inline CSS have higher priority. Techinically, it's not easy (if possible) to always listen to CSS changes and check if ECharts should change the inline CSS.

gtzinos commented 2 years ago

Hi, any update on this?

urgrund commented 1 year ago

Hi, any update on this?

Nope - we dropped the style we were going for with the tooltips due to v5.0 inline CSS overriding ours.

As suggested, just being able to pass a classname/s would be great and then all responsibility and control of tooltip stylings go to the developer allowing maximum flexibility (and just don't pass a classname/s if you want eCharts to manage it)

apache / echarts