Feature: rtl as initializer option

[koenpunt]

fixes #1485

[kenearley]

Looks good to me. Should we consider deprecating the classname?

[koenpunt]

I vote for deprecating, as setting an option with a class is irregular. But that could create problems for current users of the chosen-rtl class.. Probably should have thought of that when we'd moved away from the chzn-.. classes.

[kenearley]

We may have to leave both for a while and then remove the classname when we hit 2.0. We just need to update the docs to communicate this.

We should probably update date the RTL portion of the docs in this PR to show the option use instead.

[tjschuck]

Per SemVer:

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards-compatible manner, and
• PATCH version when you make backwards-compatible bug fixes.

If we introduce the constructor option but leave the class, we'd be bumping to 1.1 on release. If we remove the class, we'd be bumping to 2.0. Mostly a note for @pfiller and @kenearley for package-and-release purposes.

[kenearley]

@koenpunt I can take a stab at updating the docs, unless you're already on it.

[koenpunt]

Be my guest :)

[kenearley]

I just noticed that the classname has precedence over the option. I think this should be reversed. Thoughts?

[koenpunt]

This is because of backwards compatibility (if I remember it correctly).

[kenearley]

I don't see how that's backward compatible. If someone is using the classname then it will be rtl. It should fall through to checking the classname if the js option is not set. I'll check to make sure that is the case.

[kenearley]

Ah. Now I see. If you, for some reason, added the option rtl: false and then added the class, the class will take precedence. I don't see this as a problem at all as I doubt anyone would need to do this.

[kenearley]

Closing this now that we have a branch in the main repo. #1510