This only impacts the plotting. Here is an example with values fluctuating between 200-300, and with baseline set to 1000.

Notice that:

• The basline has no impact on the max value of the y-axis
• The yèaxis always start at 0 because it's the assumed baseline

Potential solution

1. When computing the extremum values, you replace when needed the base (d[0]) by the user defined baseline

2. Instead of providing a number, user can provide 'top' | 'bottom'. Then you just need to ignore the d[0] by doing

- isArea && axis.scaleType !== 'log' ? ...
+ isArea && axis.scaleType !== 'log' && series[seriesId].baseline === undefined ? ...

and in the commented line return

- return yScale(baseline)!;
- return baseline==='top' ? yScale.range[0] : yScale.range[1];

It behaves a bit weirdly when baseline changes the extremums.

This happens because the extremum getter value is then passed into the nice() function, it can have unintended consequences, which means I would also have to check the baseline where that is calculated.

But we already have the axis min/max values for that. So I believe we should use the min/max values when the axis extremums need to be changed.

It behaves a bit weirdly when baseline changes the extremums.

TLTR: I don't think it's an issue

Technically speaking, we have two behavior to define:

• where does the area set the baseline
• should the basline impact the extremums.

Should the baseline impact the extremums

For stacked data, I can not think of a usecase where the answer would be no. Otherwise you would compare some area wherase the base one would have missing part.

For a single series, where the area is more aesthetic, seems it can be ignored. Here foe example the NASDAQ evolution during the day. Nobody care of the space between 0 and 16.500. Only the relative evolution matter. Otherwise you would see nothing.

Where does the area set the baseline

I only see two reasons to modify the default 0:

• aesthetic reasons. But in that case, only min/max makes sense
• There is a specific value to compare to. For example the average over time. But in that case, I don't see a reason to pick a value that is always on top or below the line

So basically the weird case you define should not exist

Ah, but those are just working as expected. The issue that appears when we have the baseline affect the extremums is that the extremums will get niced after. So if we have a non-round number like below, it will not work properly. Then this starts to get more complex and would clash with a feature that already exists yAxis.min/max

Not exactly if the baseline means we will ignore 0 for extremum computation

I don't get what you mean here 🤔

Sorry, I forgot a part of the sentence

If the baseline is defined with min/max, the 0 will be ignored for axis extremums

Ah, this is an effect of your change, I didn't intend it at first. We can keep to the other discussion and I will update it with the outcomes

You could add a warning to say that the baseline should not be used with stacked lines