Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Buttons in admin area - bring some kind of logic to them
I’ve been working on a UI document to go with my 4.5 admin theme, I’m also going to attempt to clean up the original themes too (classic and remora) using the same UI document (though that one will need some considerable work).
The current admin-side has a multitude of different naming conventions for buttons, so I want to propose that we get them into some kind of logical and semantic order.
We currently have…
class="publish" which is used for buttons of primary importance, I propose we change this to class="btn-primary" which is the naming convention used on Twitter Bootstrap and makes more logical sense semantically (since most primary buttons in the admin area have nothing to do with the action of ‘publish’).
class="smallbox", class="smallerbox" and class="smallerboxsp" all do the same thing – target buttons that aren’t primary. Either simplify those down to class="btn" or (better) remove classes entirely from these and have them as the default using CSS rules such as:
button,
input[type="reset"],
input[type="submit"],
input[type="button"] {
buttons rules here
}The delete boxes (ones with the little ‘x’ in them) would benefit of a class of their own so they can be targeted easier by theme authors, I propose class="btn-delete" for that purpose.
On a separate note, the following rules in the core theme CSS file serve no purpose as far as I can tell (searching for those name strings within the PHP code reveals no matches):
input.cancelinput.interboxinput.interbox2input.navbox
If someone knows differently and can point out where these are used then I’m keen to know.
Next, the ‘I did it” button on setup page 3 should be a primary button (so class="publish" or the above if we are going for new naming convention).
Finally, pages/forms/styles pages have the class="smallerbox" applied to the p tag so that the subsequent a tag can be styled as a fake button, just remove that class – we can target the a tag for styling without using that class anyway so it’s superfluous (and illogical).
Last edited by philwareham (2012-04-13 22:44:05)
Offline
Re: Buttons in admin area - bring some kind of logic to them
If the classes where be removed, it would break all existing plugins, themes and such. Which is far from ideal. But if there were to be a change, the button styles should be done based on the button type. I.e. button/input[type="reset"] looks like reset button, or button[disabled] looks disabled.
These defaults set by could the type could be of course overridden by classes, but the buttons should look what they are even when they do not have classes. Some things to consider:
- All buttons should align. Including
.publish. As they do in the mentioned Twitter bootstrap. - Button should also have :active, :focus, [disabled] (etc pseudo/state) styles. For example in your Hive theme you don’t have those.
As the classes go. Why btn- prefix? I suppose in this case it’s for shorter style sheets, and having precise selectors may effect browser’s rendering performance minimally.
These styles are could also work without prefixes, by just targeting certain elements (i.e. button.publish, .button.publish). This makes using the classes require less space and typing, and is consistent across the board. In Textpattern application and presentation are not separated, so having as short lines as possible is very important to provide somewhat clean code.
As .publish class goes, I’ve always liked it. It has good ring to it. It is the definition of what button in Textpattern should do. It certainly dominates that bitch called .primary. I would choose .publish over .primary any day.
Offline
Re: Buttons in admin area - bring some kind of logic to them
What Gocom says about plugin and themes…
A work around (which has been used previously when Bloke added classes and/or ID’s to the structural elements) is to add new classes – with the understanding that the old classes are (possibly) on the chopping block in a future release. I’m not married at all to the btn- prefix though.
I also like the .publish class, it really covers what it does (as opposed to, say, .smallerbox – hmm ‘box’, really ?). .btn-primary does not cover that well.
Agreed on the need for those ‘delete’ buttons: .button-delete or better .delete-button ?
(as an aside and personal peeve: no more underscores in class names; it hurts my eyes)
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Buttons in admin area - bring some kind of logic to them
The btn- prefix is just what Twitter Bootstrap uses but I guess you’re right, we don’t really need to change the publish button (and it would break backwards compat). However I do feel strongly the the various smallbox, smallerbox, smallerboxsp should go – I mean WTF is that supposed to mean anyway, these are buttons not boxes and they are not small.
By removing those classes and having CSS rules targeting the various states of input/button tag (without using classes) we will not break older themes and plugins, and the legacy classes will be ignored.
Button should also have :active, :focus, [disabled] (etc pseudo/state) styles. For example in your Hive theme you don’t have those.
The theme will have those in eventually – it’s just not finished yet.
Last edited by philwareham (2012-04-14 09:02:18)
Offline