Labels |
Added:
?
|
Not sure why those are radio buttons, should be switchers.
I don't know what a "switcher" is. Probably because there are no switchers in HTML and Bootstrap2.3
Radios are the proper HTML element for such a selection and we (or Bootstrap 2.3) styled them as buttons.
those are radios as well, right? Just styled differently. That style will work fine for yes/no type answers, but imho not for a backup/delete one. And I'm not so sure if we should try to mimic OS settings (those look like Apple, right?) in a web app. But I don't care much as long as it doesn't look broken like the current stuff
No, they're switchers.....different to radio buttons :)
They're only used for fields with 2 options. Anything above that, I've moved to a list dropdown or in some cases stuck with the radio toggle.
They did look more like iOS before, but having debated with Brian for a good coupe of weeks, we went with a more square approach :)
No, they're switchers.....different to radio buttons
I just checked in component options. They're just different styled radios
Anything that isn't the backend is going to have dodgy styling at this point. Installation has a rudimentary bs4 conversion but there's a full redesign in the works
Installation has a rudimentary bs4 conversion but there's a full redesign in the works
That's fine. I just saw that it already uses the BS4 stuff and has some changes and most of it actually works fine.
ah you mean the actual form field
Yep
those are radios as well
This is a good example where custom elements could be used and transform the radios (if there are only 2 and have the appropriate labels) to the switcher style. By the way using custom elements we could transform all the radios to something more interesting (e.g. if less than 5, make then grouped buttons, which is a recommended pattern, or lay them out as multiple columns or anything else)
I get your enthusiasm about custom elements as they sound promising, but honestly when I look at http://caniuse.com/#search=Custom%20Elements, it is basically only working on Chrome and Opera. The rest would need some polyfill or fallback scenario. Imho as long as the other major browsers (Edge, IE, Firefox) don't support it yet, there is no point using it if the same can be done with CSS.
If you constantly only write for the lowest supported engine without even looking at polyfills, you constantly are missing out on ways to adapt newer technologies. Joomla already polyfills a good chunk of functionality both server side and client side (how many PHP 5.5+ functions are used in core even though there's a 5.3.10 minimum?). You have to play a balancing act between the new technology thing and how much added maintenance comes from it.
Next version of safari and ff is supporting them and edge is coming later this year, so (with a possible release date for J4 next year) we should be ok...
You have to play a balancing act between the new technology thing and how much added maintenance comes from it.
That's why I wrote "if the same can be done with CSS.", which is the case here.
I'm going to close the installation issues for now until the new installation template comes along.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-02-23 01:38:52 |
Closed_By | ⇒ | wilsonge |
Not sure why those are radio buttons, should be switchers. Either way, they'll be fixed when we do the redesign and revamp of the installation