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

Consistent option naming for alignment #10110

Open
LeeLenaleee opened this issue Jan 29, 2022 · 5 comments
Open

Consistent option naming for alignment #10110

LeeLenaleee opened this issue Jan 29, 2022 · 5 comments

Comments

@LeeLenaleee
Copy link
Collaborator

LeeLenaleee commented Jan 29, 2022

Feature Proposal

Comming from #10106 (comment) make all alginment's start, center and end instead of left, center and right.

Will also make it easyer to work with since its more consistent instead of 2 kind of naming scheme's

Possible Implementation

No response

@LeeLenaleee LeeLenaleee added this to the Version 4.0 milestone Jan 29, 2022
@LeeLenaleee LeeLenaleee changed the title Even option naming for alignment Consistent option naming for alignment Jan 30, 2022
@dangreen
Copy link
Collaborator

dangreen commented Aug 31, 2022

@LeeLenaleee Hi. Let's discuss some specific cases:

  1. Text align - left and right are more common values to my mind in this case
  2. Same with four directions 'top' | 'left' | 'bottom' | 'right'
  3. Here
    borderSkipped: 'start' | 'end' | 'left' | 'right' | 'bottom' | 'top' | 'middle' | boolean;
    should be both namings

What do you think about it?

@igorlukanin
Copy link
Member

igorlukanin commented Sep 2, 2022

I don't have a hard opinion about this, I just wonder how this will evolve. Should these "alternative" options be kept indefinitely in the code? Or, should at some point the backward compatibility be broken so that everyone has to go and replace left/right to start/end in their options?

My wild guess is that this will never be a reason to break the compatibility so Chart.js will stay with these pair of alternative options forever. (And end users will have to deal with longer lists of options in the autocompletion.)

@etimberg
Copy link
Member

etimberg commented Sep 2, 2022

I believe the reason we have start and end is because some of the alignment options are for axes and apply for both horizontal and vertical axes. We wanted consistent names so that X and Y scales had the same options, hence choosing the alternate values.

Is there a list of what options still use left/right/top/bottom? Maybe some are in cases where is makes sense to keep those because they don't change orientation

@dangreen
Copy link
Collaborator

dangreen commented Sep 7, 2022

@etimberg @LeeLenaleee I'm started to dig into this task and I see that it needs much time to implement, but I don't see much profit in it. Also, I can say, that if the codebase will be rewritten completely in TypeScript, it will much easier to implement. So my suggestion is to wait until we rewrite the whole project into TypeScript. What do you think?

@etimberg
Copy link
Member

etimberg commented Sep 7, 2022

That's fine by me

@etimberg etimberg removed this from the Version 4.0 milestone Sep 13, 2022
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

4 participants