Skip to content
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

labelfont, tickfont and rangefont string property #1983

Closed
dy opened this issue Sep 3, 2017 · 4 comments
Closed

labelfont, tickfont and rangefont string property #1983

dy opened this issue Sep 3, 2017 · 4 comments

Comments

@dy
Copy link
Contributor

dy commented Sep 3, 2017

Now to set custom font for an axis we have to pass an object to labelfont property:

Plotly.plot(document.body, {
  data: {
    ...
    labelfont: {family: 'Roboto, sans-serif'}
    ...
  }
})

What if instead we could just use string:

Plotly.plot(document.body, {
  data: {
    ...
    labelfont: 'Roboto'
    ...
  }
})

Plain css font string would be so intuitive!

Also I would suggest introducing an alias for labelFont - that is easy to miss a letter.

@dy dy changed the title labelfont string property labelfont, tickfont and rangefont string property Sep 3, 2017
@dy
Copy link
Contributor Author

dy commented Sep 3, 2017

Ok, seems to be problematic with existing coerceFont implementation, since we can't check which type of value passed.

@etpinard
Copy link
Contributor

etpinard commented Sep 5, 2017

Also I would suggest introducing an alias for labelFont - that is easy to miss a letter.

That's not going to happen, all plotly.js "data" and "layout" attributes are written in smashedtogether case with a few exceptions like error_y and error_x.

@etpinard
Copy link
Contributor

etpinard commented Sep 5, 2017

@dfcreative that's an interesting idea and I don't think it would be that hard to implement.

We could just add check for isPlainObject(attr) here in coerceFont and split family, size and color using a regex.

Now, down the road, we're planning on adding optional outline colors for fonts (see #1597) which wouldn't fit within the css font realm. So, I'm having doubts adding another attribute-value pathway.

@etpinard
Copy link
Contributor

This one most likely won't happen. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants