I have tested this item ✅ successfully on b67068f

Maybe I do something wrong but all this does for me is that I get the buttons instead of the plain radios. But they're still below eachother and I no longer see the current selected value.

@Bakual - Can you show me the XML code you have? Can you let me know which browser you're using? Have you tried hard refreshing?

Chrome 63 on Windows 10
I did the same test again on com_contact and changed the first switcher field to btn-group just to rule out an issue with my component. Result:

Chrome is set up to disable cache when dev tools are open (which they are). So cache shouldn't be an issue.

@C-Lodder I've added a commit to your PR which adds a div and puts the id and class there, because in my tests the btn-group didn't work with the fieldset tag.
I also adjusted the $optionClass and added an active class for the active option.

Now it works fine for me except for the coloring we had previously. But that isn't show stopper.

Can you look over it?

Thanks. Will review tonight or tomorrow

@C-Lodder You need the class for the colors above the line $optionClass .= $checked ? ' active' : '';. Otherwise we loose the active states.
Also we should either use outlined buttons or filled ones, not both mixed ?

On a sidenote I had a thought yesterday if we really need the btn-yes-no class. I think back when that ws introduced we couldn't set a class for the option. As of today, we already support this and we could just add class="btn btn-success" to the option in the XML. After all there is also the case where red/green is inverted and it makes the code just more complex if we want to take care of all possibilities.

@Bakual then all j3 extensions would need to have their XML updated

@brianteeman That's a valid point, yes.

class="btn btn-success"

I hate to tell you that this is creating a really really hard dependency on Bootstrap. We should find a way so whatever is put on the XML can be rendered at least properly by any CSS framework! We are using Bootstrap but we shouldn't dictate and allow only that framework!

@dgt41 It is applied/rendered in a JLayout, so could be changed there anyway.

It is applied/rendered in a JLayout, so could be changed there anyway.

Just do this freaking FIELD a custom element and deal with any CSS framework once and for all! Make php devs happy make front end devs happy! Make joomla CSS framework agnostic! So much to ask?

@Bakual the active states are still there

@dgt41 - Any class can be added. The layout supports a class on the label and the container. This will eventually be moved to a CE as I just remember the data-toggle attribute. We already did a party CE for the grouped buttons (haven't tested a11y) so once that more along the lines of "production ready", we can migrate it across.

@C-Lodder No, as it is now, the "active" optionClass is overwritten in case of btngroup-yes-no.

@dgt41 Why do you want to move stuff to custom elements that need no custom JS. This is plain PHP code in a JLayout which can be overriden easily already. Making it a CE just makes it more complex.

Ah do you mean when you refresh the page there is no default active state?

This will have to move to a CE, as we're using the data-toggle attrubite which belongs to BS.

Why do you want to move stuff to custom elements that need no custom JS

@Bakual disable bootstrap.js and jQuery.js and check again

@dgt41 Um, without Bootstrap and JQuery that field will just produce a regular radio select. It should still work but obviously will not show as buttons. The field doesn't load any JS anymore by itself so technically doesn't have a dependency on Bootstrap or JQuery.
If you don't like the produced HTML markup, override the JLayout.

Ah do you mean when you refresh the page there is no default active state?

@C-Lodder Yep exactly. It works if you move your new code above the line #114 ($optionClass .= $checked ? ' active' : '';).

This will have to move to a CE, as we're using the data-toggle attrubite which belongs to BS.

As said in the comment before, it doesn't matter. If the template doesn't support the btn-group class (eg Bootstrap isn't loaded), then that data-toggle will just be ignored as well and a regular radio field is shown. No harm done.

The field doesn't load any JS anymore by itself so technically doesn't have a dependency on Bootstrap or JQuery.

That's the misconception here! The data- is bound to bootstrap.js which also requires jquery.js. Test this by nulling the jquery::framework and bootstrap::framework JHTML classes (don't actually load the js files)

Also check the SRC: https://github.com/twbs/bootstrap/blob/34cd2038d2b16f305919e1fc36ff45913e3d1dfd/js/src/button.js#L154

@dgt41 I understand that the data-toggle is triggering the Bootstrap code. But when Bootstrap isn't there, nothing happens (except if some other JS code looks for that attribute). The data attribute is just a regular HTML attribute which gets ignored by browsers. A regular radio select is rendered.
It's actually similar to a Bootstrap CSS class: "col-md-6" is Bootstrap specific, but if Bootstrap isn't loaded nothing bad happens.

@Bakual Moving to a custom element will mean that something will happen even if Bootstrap isn't there ;)

So the idea is to remove the data-toggle and replace the layout with:

<joomla-grouped-buttons>
    <label>
       <input name="foo" type="radio" checked> No
    </label>
    <label>
       <input name="foo" type="radio"> Yes
    </label>
</joomla-grouped-buttons>

We'll basically be replicating what Bootstrap do with the data-toggle attribute but won't reply on Bootstrap

Moving to a custom element will mean that something will happen even if Bootstrap isn't there ;)

@C-Lodder Yeah, I get that as well. But my point is for what? btn-group is a Bootstrap "design" class. If the template doesn't use Bootstrap, why should the radio still mimic Bootstrap design? There is no reason for that as technically it works with or without the design. By creating a CE for that, you just copy-paste Bootstrap code (and rewrite to vanilla) which imho is stupid.
The switcher is different as that is a "Joomla Design" feature and it requires custom JS anyway. So that imho makes sense as CE.

Other frameworks offer button groups. See https://semantic-ui.com/elements/button.html or https://foundation.zurb.com/sites/docs/v/5.5.3/components/button_groups.html as examples.

The thing that is custom Bootstrap logic is a JavaScript component that lets you turn radio inputs into a button group.

I don't see the issue with taking that and making it a CE option. Other frameworks natively support displaying this type of button group, just not as a replacement for radio inputs in the same way Bootstrap's JavaScript component does.

@Bakual - The btn-group class will be removed too. A button group is simple a group of buttons. The custom element will use it's own JS and it's own styling so that it will work with any framework.

A prime example being, if someone builds a Joomla site based on UIKit and removes Bootstrap completely...normally the btn-group would be completely unstyled. With a custom element, the styling will remain the same and the JS will continue do all the fancy stuff.

The sample applies for alerts, modals, tooltips....if you remove Bootstrap and/or jQuery, half of Joomla won;t work at all. Migrating everything to custom elements simply means superior performance and framework agnostic.

Another part of migrating to custom elements (not in the case of the btn-group but just overall) is having these JS components fully accessible, which Bootstrap isn't. We've promised AA compliance with J4 which can not be achieved with Bootstrap's JS components

If you're that fancy to copy all of Bootstrap over to CEs, go for it and waste your time. I still think it's pointless.
Anywy we've gotten offtopic for this particular PR. And this PR is badly needed as currently radios with the class "btn-group" just don't work t ll, which means I can't set any parameter in my extensions if I don't remove that class from the XMLs.
If you move the part with btn-group-yesno a few lines further to the top as I wrote earlier, then it would be fine and could be merged. If you want to convert it to a CE, you need the same logic anyway as well. So this PR isn't wasted.

I'll move that line up when I'm home later tonight unless you don't mind making it (assuming you have edit permissions)

Stop build the rocket!
All this as simple as drink a five liters of beer ?

It even do not require javascript! nor bootstrap nor anything else.

<label>
       <input name="foo" type="radio" checked> No
</label>
<label>
       <input name="foo" type="radio"> Yes
</label>

this will be hell for custom styling.

I suggest:

Leave an old markup:

<fieldset class="radio blabla-group">
<input name="foo" type="radio" checked>
<label>No</label>
<input name="foo" type="radio">
<label>Yes</label>
</fieldset>

and then CSS:

.blabla-group input[type="radio"] {
  display: none;
}
.blabla-group input[type="radio"]:checked + label {
   background: green;
}

then all can be perfectly styled just with CSS, without useless layout override and JavaScript,

OR
at least add <span> wrapper to a label text:

<fieldset class="radio blabla-group">
  <label>
       <input name="foo" type="radio" checked> <span class="label-text">No</span>
  </label>
  <label>
       <input name="foo" type="radio"> <span class="label-text">Yes</span>
   </label>
</fieldset>

and then CSS:

.blabla-group input[type="radio"] {
  display: none;
}
.blabla-group input[type="radio"]:checked + .label-text {
   background: green;
}

some first found example http://jsfiddle.net/496c9/ ?

@Fedik - as long as the a11y team are happy with that then I'm all for it

@C-Lodder so someone needs to ask them ?

it just a good/old regular radio buttons, what can be problem with accessibility? ?

to keep input[type="radio"] "focusable" and still hidden:

.blabla-group input[type="radio"] {
position:absolute;
opacity:0;
z-index:-1;
}

@C-Lodder @Fedik i've tried adding tabindex="0" if it's on the label the enter or space do nothing, if it's on the input tab key is not iterating the inputs. This needs some thoughts...

Ignore me! The radios are not controlled with the tab key but instead are using the arrow keys, so keyboard is ok. I guess the aria described etc are already in place so this should be ok. Still needs some auditing by the a11y team

I'll move that line up when I'm home later tonight unless you don't mind making it (assuming you have edit permissions)

@C-Lodder Done. I also did some other changes which I noticed when testing again: The grey buttons now also use the "outline" variant so they're consistent.
The colors are now based on the option value instead of the position.

@Fedik If we can get it working without JS at all, even better ?

Sharing again

https://inclusive-components.design/toggle-button/

Sharing again

Thanks @brianteeman

There a link to http://wtfforms.com/ with similar approach to the radio buttons styling, as I have suggested

And the quote from http://wtfforms.com/ FAQ:

Is this screen reader friendly?
Initial testing done by patrick_h_lauke (on version 2.2.0) with various standard combinations (Internet Explorer/Firefox with JAWS15/NVDA on Windows, Safari with VoiceOver on OS X and iOS, Chrome with TalkBack on Android) does not show any adverse effects.

so I think we should be fine with it ?

Why closing? Imho this PR was at least better than nothing and was getting the radios back to a working state. Currently they are just broken for all 3rd parties who didn't remove the "btn-group" class yet from their XMLs.

@Bakual - reopen and get merged if you want. I don't want to keep waiting as I constantly run into conflicts

Did a new one: #19326. Easier to maintain for me.

#19326 works fine here.