You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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! :)
The text was updated successfully, but these errors were encountered:
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.
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 accepttag.classname
(ortag.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
andbodyTag
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 ofheaderTag: "h1.title"
andbodyTag: "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 theirh1
's anddiv
's). Although, now that I think about it, you could make it such that if the user only enters atag
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! :)
The text was updated successfully, but these errors were encountered: