User tests: Successful: Unsuccessful:
The group btn class for "yes/no" buttons should be:
btn-group btn-group-yesno
Right now we have
Backend Module Editing:
Show Title field class: btn-group btn-group-yesno
All other "yes/no" fields class: btn-group btn-group-yesno
Frontend Module Editing:
Show Title field class: btn-group
All other "yes/no" fields class: btn-group btn-group-yesno
Apply PR then all grouped buttons should be displayed consistently.
Status | New | ⇒ | Pending |
Labels |
Added:
?
|
Category | ⇒ | Front End UI/UX |
No, it doesn't work now.
It happens because frontend site template (e.x Protostar) doesn't have such css rules when it probably should. By adding this class name we can assign the same button design as in backend.
E.g. standard backend template Isis has such css rules:
.controls .btn-group.btn-group-yesno > .btn {
min-width: 84px;
padding: 2px 12px;
}
In backend we were able to use this class easy, because there aren't that many templates around.
In frontend everything we do, needs to be supported by template developers.
We can add this class to the forms, but it would only have an effect on Protostar and the few templates which will implement it in a future version.
That's probably the reason why we don't use this classes in frontend.
In backend we are able to use this class not because of little quantity of templates, but because this class exists for this field.
Agree, on frontend the usage of this class fully depends on template or extension developers.
But to be able to use this class on frontend this field must have this class name on frontend.
Again, want to drag your attention to this inconsistency.
When you edit module settings on frontend all "yes/no" buttons that are present in module options have
btn-group-yesno
class name. Only "Show title" field doesn't have this class name. When I try to assign some design for such buttons in my template, all of them look the same but for "show title" buttons. Without this class name I cannot assign the same design for these buttons. This PR fixes this problem.
I don't see an argument against merging this. If the frontend editor is using the same forms as the backend editor (I assume that's the case, at least I hope so!), the class is already defined on other fields regardless of whether the template has styling rules for it. To me it's a no-brainer, just merge this.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-08-17 19:48:42 |
Closed_By | ⇒ | Bakual |
Milestone |
Added: |
It dawned to me why we didn't use this class so far in frontend: We usually don't have radios to begin with in the forms (article, contact, ... use list in frontend where we have radios in backend).
@shur hmm looks like it don't work?