Simplify CSS targeting of radio and checkbox label fields.

[dcavins]

Currently, our markup for a radio group or checkbox group looks like this:

<div class="editfield field_35 field_best-tusks required-field visibility-adminsonly field_type_radio">
    <div class="radio">
      <label for="field_35">Best Tusks <span class="bp-required-field-label"> (required)</span></label>
      <div id="field_35">
        <label for="option_72"><input type="radio" name="field_35" id="option_72" value="Unicorn">Unicorn</label>
        <label for="option_73" ><input type="radio" name="field_35" id="option_73" value="Bicorn">Bicorn</label>
        <label for="option_74"><input type="radio" name="field_35" id="option_74" value="Triceratops">Triceratops</label>
      </div>
    </div>

    <!-- visibility toggle and settings normally go here, removed for simplicity -->

    <p class="description">Which is the superior number of tusks or horns?</p>
</div>

It would be easier to target the label for the checkbox or radio group separately from each option's label (without resorting to descendant selectors or similar) if there were a little more info, like adding classes like option-group-label or option-label:

<div class="editfield field_35 field_best-tusks required-field visibility-adminsonly field_type_radio">
    <div class="radio">
      <label for="field_35" class="option-group-label">Best Tusks <span class="bp-required-field-label"> (required)</span></label>
      <div id="field_35">
        <label for="option_72" class="option-label"><input type="radio" name="field_35" id="option_72" value="Unicorn">Unicorn</label>
        <label for="option_73" class="option-label"><input type="radio" name="field_35" id="option_73" value="Bicorn">Bicorn</label>
        <label for="option_74" class="option-label"><input type="radio" name="field_35" id="option_74" value="Triceratops">Triceratops</label>
      </div>
    </div>

    <!-- visibility toggle and settings normally go here, removed for simplicity -->

    <p class="description">Which is the superior number of tusks or horns?</p>
</div>

This is easy to do, so I'll attach a patch that accomplishes that, but in thinking about this, I was wondering if this is a good use case for a fieldset and legend.

<div class="editfield field_35 field_best-tusks required-field visibility-adminsonly field_type_radio">
    <fieldset class="radio">
      <legend>Best Tusks <span class="bp-required-field-label"> (required)</span></legend>
        <label for="option_72"><input type="radio" name="field_35" id="option_72" value="Unicorn">Unicorn</label>
        <label for="option_73"><input type="radio" name="field_35" id="option_73" value="Bicorn">Bicorn</label>
        <label for="option_74"><input type="radio" name="field_35" id="option_74" value="Triceratops">Triceratops</label>
    </fieldset>

    <!-- visibility toggle and settings normally go here, removed for simplicity -->

    <p class="description">Which is the superior number of tusks or horns?</p>
</div>

@hnla, @mercime, do you have opinions on any of this?

[hnla]

If we can legitimately use a fieldset we should, it's intention is to separate and group form sections to provide clarity and tends to be underused.

We would want to add a more semantic class token though that described the group of controls.

[DJPaul]

No harm in adding classes here, so if people can figure out what's best in terms of naming convention for these, sounds good.

[mercime]

+1 @dcavins. Might I suggest including the datebox fields as well :)

[dcavins]

It looks like using field sets around radio button and checkbox sets is maybe a good practice:
​http://www.w3.org/TR/WCAG20-TECHS/H71.html

The examples include:

• A set of checkboxes
• Radio buttons submitting to the same named field
• Logically related controls

[dcavins]

I've updated the patch to take the fieldset + legend approach and tested the output in several of the Twenty-* themes and a couple of popular premium themes. With just a tiny touch to buddypress.css, most of them look the same as the old markup; Twenty Thirteen and Twenty Fourteen show the "fieldset lasso," so we may want to specifically address that in those themes. I'll also upload images of these three field types in the themes.

Thanks @hnla and @mercime for your feedback. Please let me know if you have any other thoughts and if you think removing the fieldet lasso is appropriate.

[dcavins]

Use field sets and legends for radio button, checkbox or date box field groups.

[dcavins]

Twenty Twelve output

[dcavins]

Twenty Thirteen fieldsets

[dcavins]

Twenty Fourteen output

[dcavins]

Twenty Fifteen output

[dcavins]

"Boss" paid theme output

[dcavins]

"Kleo" paid theme output

[hnla]

@dcavins That all looks good, we look to be able to slip the new element in under the radar assuming the look of screens before sowe don't go upsetting themes. I think we'll add a generic selector rule to hide the border under the #buddypress #item-body elements in bp css just to ensure we hide if a theme doesn't.

[dcavins]

Thanks @hnla. Let's make this the first commit of the 2.6.0 tag!

[mercime]

@dcavins Love the screenshots :) Checked accessibility end and it's two thumbs up!

[DJPaul]

@dcavins Great job!

6678.02.patch looks good. Let's get it in.

[dcavins]

Fieldset structure introduced in r10656.

Style updates still to come.

[dcavins]

Here are some minimal style changes. @hnla can you look at these rules and see if they're where you want them to be, specificity-wise? Thanks!

[dcavins]

Fields styling in TwentyThirteen and TwentyFourteen

[dcavins]

TwentyThirteen fields styling.

[dcavins]

TwentyFourteen fieldset styling

[hnla]

@dcavins These look fine, I'll have a closer look in the morning.
One thing we could perhaps do is not style on the three fieldset type classes e.g 'radio', instead creating a class 'no-border', reducing three selector sets to one?

[dcavins]

@hnla I'm fine with more attribute-like CSS, which I'm assuming we're headed toward with a new template pack.

In that case, though, I'm assuming we'd add the rule as #buddypress .no-border and drop it in buddypress.css. (Then people who wanted a border on their fieldsets would curse us for using an id in the selector, ha ha.) Is that what you're thinking?

[hnla]

yep sort of - we namespace most of our rules under #buddypress so pointless them moaning :) They'll just have to use #buddypress in their override :)

Or we leave as is, it was just saving some space really.

[hnla]

style.02 patch moves the fieldset border:0 ruleset to buddypress.css

[hnla]

@dcavins Think we may be best off adding the rules for fieldset to the main BP stylesheet so we cover any themes that don't handle null styling like most of the twenty* themes seem to.

Also added a teeny bit of margining to radio/checkbox inputs.

It's not ideal but think this will suit and we'll improve on things when we can tackle styles afresh.

[dcavins]

This is OK with me. Commit at will, and we'll see if we break anything.

[hnla]

In 10713:

BP XProfile user edit screens
Commit updates radio, checkbox, datebox form controls to improve markup Standards & accessibility.

• Adds new classes to simplify targeting labels/inputs.
• Updates main css styles for labels to include fieldsets/legends.
• Updates wrapping 'divs' to fieldsets for better Standards & changes labels used for headings to 'legend' elements.
• Add new ruleset to buddypress.css to remove fieldset border & padding to ensure new elements do not disrupt existing site layouts.

Fixes #6678 Props dcavins, hnla, mercime