-
Notifications
You must be signed in to change notification settings - Fork 0
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
[Section] Better content clipping #157
Comments
This makes sense, but we need to think this through, because in the current implementation this will also clip off the axes, which are currently implemented using |
Yes the axes would be clipped once we attach the section-data clipPath to each rendered element in |
What about a prop to control clipping? We can switch it off by default for all marks except the |
Also, for the |
I don't think we have to think about how it works more generally, precisely because they are special cases. I also would not call this 'hacking around': it is just specifying sensible default behavior. The current default behavior is not sensible, therefore we change it.
Do you mean that they should be cropped as they are dragged outside of the padded area? Because to that I would agree, but that could be solved with the solution suggested above. Or do you mean that you should not be able to move them beyond the borders of padded area? Because I think there are cases where you do want to be able to do that, and that if you don't, then that should be solved in user-land. |
Yeah that works for me! Code looks good 👍
If we implement the
To question 1 I say yes, and to question 2 I say: the lower bound of the domain in their respective dimension. This is a sensible default in my opinion. We could, of course, also have another default value, like we have now. However, I think that is a weird default value, that's why I argue for the other one. This is, however, a different discussion from whether we should implement clipping- we should, and the code you just posted looks perfect for that! But, in my opinion, we should also change the default value for the |
That's a good point, didn't think of that. In that case we can do something like function getY2Default (domain) {
if (isQuantitative(domain) {
if (domain.every(v => v > 0) || domain.every(v => v < 0)) {
return domain[0]
} else {
return 0
}
}
if (isCategorical(domain) {
return domain[0]
}
if (isTemporal(domain) {
return domain[0]
}
} Or am I missing cases where this would not work? |
The
Area
mark has been set up such that when the second dependent variable (y2
orx2
) is not specified, it defaults to 0.However in some cases it may be undesirable for the dependent axis to start at 0. For instance when plotting speed against time, with area representing distance travelled, we may want a truncated y-axis beginning at 1000
Yet when
y2
is not specified, we end up with a graph like thisreproduction: https://svelte.dev/repl/1e6fa75636d44e00a9ada00dc7c39dec?version=3.19.1
Rather than mandating that the user specify
y2={[1000, 1000, 1000]}
or replacing its default 0 with domainMin in the back end, I suggest we clip whatever is rendered byMark
to the bounds of the datainstead of the bounds of the section, as is currently the case
For example in the case of polygons,
The text was updated successfully, but these errors were encountered: