So, I was considering a new feature that I'll add to WeCSS, and need to get some thoughts on it first...
Let's consider this new keyword, 'virtual' (always in line with the C++/Delphi naming scheme.)
.inline-block virtual
display: inline-block
blablabla...
Now, the idea is that if a selector is found that has the virtual keyword, at the end of the pre-processing stage, Wedge will run a check for the selector, and delete it from all selector combinations (i.e. .inline-block, .windowbg, .windowbg2 will just become .windowbg, .windowbg2).
Additionally, if it's found to be alone (i.e. no other selectors extend it), it will simply delete it. Thus allowing me to create a 'virtual.css' or 'common.css' file with all of the nice little helpers like this one, and add it silently at the beginning of all files, which in turns allows us to use "extends .inline-block" everywhere, including external CSS files not related to the main file.
I think it's a pretty good idea, but this is where it gets tricky: there are a few rare situations where "inline-block" is used as a proper class in the HTML -- notably in the admin homepage, where it's also associated with admin_menu (making it easy to remove it... Just extend it!), the profile template (can add a custom class to that one), and the plugin manager (same here, will need an extra class.)
So, I'm wondering what's best?
1/ just forget about that keyword, and keep allowing the HTML to use virtual selectors.
2/ use it, but don't delete the selector afterwards... (which makes it pretty much useless, ah ah :))
3/ use it, and always delete the selector, and force the HTML to inherit from the selectors instead of using them.
Let's consider this new keyword, 'virtual' (always in line with the C++/Delphi naming scheme.)
.inline-block virtual
display: inline-block
blablabla...
Now, the idea is that if a selector is found that has the virtual keyword, at the end of the pre-processing stage, Wedge will run a check for the selector, and delete it from all selector combinations (i.e. .inline-block, .windowbg, .windowbg2 will just become .windowbg, .windowbg2).
Additionally, if it's found to be alone (i.e. no other selectors extend it), it will simply delete it. Thus allowing me to create a 'virtual.css' or 'common.css' file with all of the nice little helpers like this one, and add it silently at the beginning of all files, which in turns allows us to use "extends .inline-block" everywhere, including external CSS files not related to the main file.
I think it's a pretty good idea, but this is where it gets tricky: there are a few rare situations where "inline-block" is used as a proper class in the HTML -- notably in the admin homepage, where it's also associated with admin_menu (making it easy to remove it... Just extend it!), the profile template (can add a custom class to that one), and the plugin manager (same here, will need an extra class.)
So, I'm wondering what's best?
1/ just forget about that keyword, and keep allowing the HTML to use virtual selectors.
2/ use it, but don't delete the selector afterwards... (which makes it pretty much useless, ah ah :))
3/ use it, and always delete the selector, and force the HTML to inherit from the selectors instead of using them.