Skip to content

Allow (more?) properties, such as textAnchor, dx, dy, to be specified as functions of data (but not bound to scales)? #107

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

Closed
Fil opened this issue Jan 23, 2021 · 5 comments
Labels
question Further information is needed

Comments

@Fil
Copy link
Contributor

Fil commented Jan 23, 2021

For text marks I'd like to be able to specify fontWeight (as a constant) ((maybe accept also font-weight?)).

@Fil

This comment has been minimized.

@Fil
Copy link
Contributor Author

Fil commented Feb 15, 2021

Another use case in the Marimekko chart.

@mbostock
Copy link
Member

I feel this issue should be broken down:

  • The Text mark should support more constant properties such as fontWeight. (Easy.)
  • Should some of the existing constant properties (e.g., textAnchor) support being data-driven? (Medium.)
  • Should any constant property be expressible, somehow, as a data-driven channel if desired? (Hard.)

My working assumption is that Marks currently get to decide whether a property is a constant or a channel (or either, e.g., with maybeColor), so if a given Mark doesn’t expose what you want, we either need to change the Mark definition to make it more flexible, or extend the Mark to create a new one. I do think it ends up being simpler if a Mark implementation can declare something as a constant property, rather than needing to support every property as possibly being data-driven. Also, even for constant properties, you can make things somewhat data-driven by declaring multiple marks (as in the Marimekko example) and possibly filtering the data.

@mbostock mbostock added enhancement New feature or request question Further information is needed and removed enhancement New feature or request labels Feb 24, 2021
@mbostock
Copy link
Member

This issue should be broken down as suggested.

@Fil
Copy link
Contributor Author

Fil commented Feb 25, 2021

broken into #173 #174 #175

@Fil Fil closed this as completed Feb 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is needed
Projects
None yet
Development

No branches or pull requests

2 participants