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

More Control Over Classnames #138

Open
EnigmaSolved opened this issue May 7, 2015 · 1 comment
Open

More Control Over Classnames #138

EnigmaSolved opened this issue May 7, 2015 · 1 comment

Comments

@EnigmaSolved
Copy link

I'm a big fan of having more control over classnames, perhaps like PR #131. I have some thoughts though on coming at the problem a little differently. What if we used the existing settings (currently related to tags) and made it so those settings could also accept tag.classname (or tag.classname1.classname2)?

The settings contentContainerTag, actionContainerTag, stepsContainerTag all are used to define the tag which will wrap the corresponding element. So if we changed the default for each of those to be their tag & classname (eg, contentContainerTag: "div.content") and enabled each setting to thus accept classnames I think that might be a bit more intuitive way to go about things, and we don't have to add additional settings. It will also be partly-backwards compatible (for users that did not define anything for these settings).

headerTag and bodyTag are a bit different in that these two settings are used to find elements. However, I suggest adopting a similar pattern as above, ie, defaults of headerTag: "h1.title" and bodyTag: "div.body". Now, this requires a bit more both on the backend (as at least .body is used to target elements in the js code, so that will need to be made into a variable so that the custom classname is used), and on the frontend (as the user will now need to add the default classnames to their h1's and div's). Although, now that I think about it, you could make it such that if the user only enters a tag for either of these settings, then jQuery-Steps will automatically assign the default classnames to those elements (ie, it will search based on just the defined tag, and then add the classname, same as it does now). Thus, for those using the default classnames they can still just define tags for these two settings, but for those who want to use different classnames those can be easily defined (and in that case the user needs to be sure to actually add the defined classname to their elements, because otherwise jQuery-Steps won't be able to find them since it would be search for a tag.classname combo).

With both sets of settings, there would obviously need to be a function that can parse out the tag and classname(s) from a string in the format of tag.classname1.classname2, but that shouldn't be a problem.

It is also worth noting that we can already add our own classes to the "header" and "body" elements, which will persist after jQuery-Steps initiates. All of the above, however, would give greater control over the classnames used for those elements (eg, in the case of classname collission), as well as obviously giving control over the classnames used for the other elements (which currently we have no control over).

There are a handful of additional classnames which aren't addressed above, so it would be helpful to have settings for each. I spot the following (though I might have missed a few): .current, .diabled, .last.

I believe that implementing all of the above would address #131, #93, #21 (partially).

Thanks for considering my ideas! :)

@EnigmaSolved EnigmaSolved changed the title More More Control Over Classnames May 7, 2015
@EnigmaSolved
Copy link
Author

Forgot to mention that I'd be glad to do a Pull Request if you're agreeable to these changes. :) But don't want to do that work unless I know you'll merge them in.

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

No branches or pull requests

1 participant