Problem/Motivation

There are some situations where we which to group elements together on a page to emphasise the relationship between them. Using a fieldset is not always desirable to use it because it has an effect on screenreader users. We need to create a class that can be added to any element.

13.fieldset.png

Proposed resolution

In the Seventy Eight issue it was suggested that we create an applicable class that can be applied to any elements, including a fieldset. The fieldset element has semantic value to screen reader users and the use of the tag it could be used for accessibility reasons only. There are also other elements across of Core that have similar styling applied that are not actually fieldsets.

The design of an open fieldset has been tweaked to match the principles of the new Seven Style Guide.

This styling was prototyped in the Seventy Eight sandbox.

Test Pages

  • admin/structure/types/manage/article/fields/node.article.body
  • admin/structure/views/view/content
  • admin/structure/taxonomy/manage/tags/add
  • admin/modules
  • #1986418: Update textfield & textarea style
  • #1986434: New visual style for Seven
  • View all styleguide issues

    Support from Acquia helps fund testing for Drupal Acquia logo

    Comments

    LewisNyman’s picture

    Issue tags: +styleguide

    tag

    LewisNyman’s picture

    After some exploration, it seems that there are actually very few fieldsets in core right now. They have have been converted into <details> elements. It's also entirely possible that fieldsets could be used for non visual reasons and that the visual grouping could be used in situations where a fieldset is not the appropriate tag. An example the demonstration given in the issue summary, the visual grouping is wrapping the entire form.

    I'm expanding this issue to introduce a reusable 'pane' component that can be used on any element — fieldset, details, etc — to visually group form items together. This might be a good opportunity to try out some good documentation on when this component should be used.

    LewisNyman’s picture

    Title: Fieldset style update » Introduce a 'pane' component to visually group form items
    nod_’s picture

    I think the term 'pane' will end up confusing people. I don't have better though.

    LewisNyman’s picture

    Issue summary: View changes
    Status: Active » Needs review
    FileSize
    296 bytes

    Let's go for it and see what happens

    LewisNyman’s picture

    FileSize
    640 bytes

    Bad patch!

    mgifford’s picture

    6: seven-pane-2113903-6.patch queued for re-testing.

    Status: Needs review » Needs work

    The last submitted patch, 6: seven-pane-2113903-6.patch, failed testing.

    mgifford’s picture

    Good place to test this (well along with #2002336: Introduce a CSS class to hide borders of fieldset elements ) - admin/config/development/performance

    LewisNyman’s picture

    Issue summary: View changes
    sun’s picture

    Status: Needs work » Needs review
    FileSize
    3.46 KB
    34.45 KB

    I quickly whipped up a patch to demonstrate that #type 'fieldgroup' resolves the issue already (except of Seven-specific styling, of course):

    1. Filters are visually grouped into a container, including label/heading.
    2. The exposed filters are grouped.
    3. The form submit button is part of the fieldgroup.

    This requires some changes to how Views constructs the exposed form. The changes in attached patch are just quick & dirty only, not meant to be an official change proposal.

    As far as I can see, Views does not support a concept for a label/heading for the exposed form yet, so the "Filter" legend in this screenshot is hard-coded right now.

    Perhaps @dawehner and other Views experts are able to help.

    (Perhaps it might also be a good idea to split those Views changes into a separate issue, so that this issue stays focused on the Seven theme changes only...)

    Status: Needs review » Needs work

    The last submitted patch, 11: drupal8.views-exposed-fieldgroup.11.patch, failed testing.

    damiankloip’s picture

    This patch just adds a configurable title to the field group to sun's patch. Also, changes 'filters' key to 'handlers'.

    Do we want to split this into its own issue?

    LewisNyman’s picture

    @damiankloip yes please. It's good to provide an example with this issue to give it context but apart from that they are separate.

    @sun Thanks, I've included Seven styling in this patch.

    This looks like the wrong direction to me. With Stark, if a developer wants to use a fieldset without styling they would use #type 'fieldgroup'. So in Seven the correct way would be to add default styling to the fieldset element and then undo it when the .fieldgroup class is applied? Am I understanding this right?

    emma.maria’s picture

    Status: Needs work » Needs review
    Issue tags: +frontend, +CSS
    LewisNyman’s picture

    Assigned: Unassigned » sun

    Assigning to sun because we need some clarification before we move forward.

    The last submitted patch, 13: 2113903-12.patch, failed testing.

    Status: Needs review » Needs work

    The last submitted patch, 14: drupal8.views-exposed-fieldgroup.14.patch, failed testing.

    LewisNyman’s picture

    Assigned: sun » Unassigned

    Unassigning. In my eyes the requirements here and in #2002336: Introduce a CSS class to hide borders of fieldset elements are completely different. This one is "I want elements that aren't fieldsets to look like a fieldset" and the other is "I want fieldsets to look like they aren't fieldsets". We can't use the fieldgroup FAPI type here, it will have completely different results between Stark and Seven.

    I'm going to build on the patch from #6, and see if I can drop the class into the correct elements through the Seven theme layer.

    LewisNyman’s picture

    Here's a comparison of CSS UI frameworks they all seem to use the term 'panel' for this component. This is just as problematic. In other situations we've opted for the wider web conventions over Drupal naming conventions, but it feels a little dangerous.

    Does anyone have a problem with a 'box' class?

    LewisNyman’s picture

    Going to revive this. We should use panel, there is a precedent for using common terms outside of Drupal instead of giving preference to Drupalisms.

    andypost’s picture

    Is this still make sense in 8.0?

    andypost’s picture

    Version: 8.0.x-dev » 8.1.x-dev

    Version: 8.1.x-dev » 8.2.x-dev

    Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.2.x-dev » 8.3.x-dev

    Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.3.x-dev » 8.4.x-dev

    Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.4.x-dev » 8.5.x-dev

    Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.5.x-dev » 8.6.x-dev

    Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.6.x-dev » 8.7.x-dev

    Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.7.x-dev » 8.8.x-dev

    Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.8.x-dev » 8.9.x-dev

    Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

    colan’s picture

    @damiankloip (#13): Did you create another issue for this? I couldn't find anything in the core queue (although I did find the Views Exposed Form Fieldset contrib module).

    Version: 8.9.x-dev » 9.1.x-dev

    Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

    Version: 9.1.x-dev » 9.2.x-dev

    Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

    Version: 9.2.x-dev » 9.3.x-dev

    Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    Version: 9.3.x-dev » 9.4.x-dev

    Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    Version: 9.4.x-dev » 9.5.x-dev

    Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    Version: 9.5.x-dev » 10.1.x-dev

    Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    mherchel’s picture

    Project: Drupal core » Seven
    Version: 10.1.x-dev » 1.0.0-alpha1
    Component: Seven theme » Code

    Moving this over to the Seven theme now that it's out of core.