.hidden class is overridden by Claro form classes

Created on 9 February 2023, over 2 years ago
Updated 12 September 2024, 10 months ago

Problem/Motivation

The css definition for .claro-details overrides any .hidden class on the element.

Steps to reproduce

In a hook_form_alter() add an `[#attribute][class][] = hidden` on an element of [#type] = `details` gets overridden by the .claro-details { display: block} definition.

Update: Same for other claro elements, like .button, see #9

Proposed resolution

Add properties to visually-hidden so that they are not overridden by other elements.

Add CSS:

 .hidden {
 position: absolute !important;
 overflow: hidden;
 clip: rect(1px, 1px, 1px, 1px);
 width: 1px;
 height: 1px;
 word-wrap: normal;
 }

Remaining tasks

Possibly all that is required is to remove the display: block from the .claro-details definition.

User interface changes

Before patch:

After patch:

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

🐛 Bug report
Status

Needs work

Version

11.0 🔥

Component
Claro 

Last updated 1 day ago

Created by

🇺🇸United States Chris Dart

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

  • Issue created by @Chris Dart
  • @chris-dart opened merge request.
  • First commit to issue fork.
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update about 2 years ago
    30,325 pass
  • @santosh_verma opened merge request.
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update about 2 years ago
    30,325 pass
  • Status changed to Needs review about 2 years ago
  • Status changed to Needs work about 2 years ago
  • 🇺🇸United States smustgrave

    This will need a test case showing the issue.

    Also @Santosh_Verma if you're going to do a separate MR helps to say why your solution is preferred over the other one. Will need an issue summary update now for proposed solution.

  • 🇮🇳India santosh_verma Faridabad

    Hi @smustgrave, I have provided some context for my MR on issue #4. I am happy to update the purposed solution but I waiting for review of my MR and get some feedback.

  • 🇮🇳India Harish1688 India

    Hi,
    I have tested both merge request (MR) solutions for the issue and found that both of them are effective. However, determining which solution is a better approach depends on the specific context.

    1. In MR !3426, removing the "display: block" property resolves the problem for elements where "block" is the default property. However, this may potentially introduce issues in other cases wheres it's need block property.

    2. In my opinion, the second merge request (MR) !3914 appears to be a safer approach. It retains the "display: block" property while utilizing the "hidden" class to override it when necessary. This avoids the potential unknown consequences that may arise from removing the "display: block" property altogether.

  • 🇩🇪Germany Anybody Porta Westfalica

    Just ran into this and can confirm the issue still exists.

    As of https://www.drupal.org/docs/accessibility/hide-content-properly the class hidden should work, especially on core themes ;)

    Sadly there's a further case of this in claro for .button:

    .button {
      display: inline-block;
      margin: var(--space-m) var(--space-s) var(--space-m) 0; /* LTR */
      padding: calc(var(--space-m) - 1px) calc(var(--space-l) - 1px); /* 1 */
      cursor: pointer;
      text-align: center;
      -webkit-text-decoration: none;
      text-decoration: none;
      color: var(--button-fg-color); /* 2 */
      border-radius: var(--button-border-radius-size);
      background-color: var(--button-bg-color);
      font-size: var(--font-size-base);
      font-weight: 700;
      line-height: 1rem;
      -webkit-appearance: none;
      appearance: none;
      -webkit-font-smoothing: antialiased; /* 3 */
    }
    

    Adding hidden class on a form button also doesn't work as the .hidden is weighted lower than .button with display: inline-block;

    Setting priority to Major, as this makes hidden elements visible in Claro and is against the documented Drupal Standards ( https://www.drupal.org/docs/accessibility/hide-content-properly )

  • In our themes, we always use the hidden class together with the !important statement.
    IMO, this class definitely should override everything.

  • Status changed to Needs review over 1 year ago
  • last update over 1 year ago
    30,422 pass, 2 fail
  • 🇮🇳India gauravvvv Delhi, India

    Irrespective of changing it on different places like, .claro-details.hidden, button and other elements. Its better to change it on hidden class.
    Not continuing with MR, as both the MR are fixing for one element and the problem with hidden is global. I have adapted the different approach (using important on display: none itself), attached patch for same. Please review

  • last update over 1 year ago
    30,423 pass, 2 fail
  • Status changed to Needs work over 1 year ago
  • 🇺🇸United States angrytoast PNW

    Adding for consideration, regarding the risk factor mentioned in #9: Using !important on .hidden or [hidden] affects not only CSS overriding but also javascript behaviors, using jQuery or vanilla js won't work as expected, e.g. if something is set to:

    [hidden] {
      display: none !important;
    }
    

    and given a DOM structure like:

    <div id="my-element" hidden="true"> ... </div>
    

    Then jQuery('#my-element').show(); or document.getElementById('my-element').style.display = 'block'; will not work. The only way it'll work is to toggle the class or the attribute and this will be a change in expectations of how something should work.

  • Status changed to Needs review over 1 year ago
  • 🇮🇳India gauravvvv Delhi, India

    I have tried a different approach, create patch and interdiff for same. please review

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 5.3 & MySQL 5.5
    last update over 1 year ago
    Composer error. Unable to continue.
  • Status changed to Needs work over 1 year ago
  • 🇺🇸United States smustgrave

    If a new solution is taken an issue summary will be required.

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 5.3 & MySQL 5.5
    last update over 1 year ago
    Composer error. Unable to continue.
  • Status changed to Needs review over 1 year ago
  • 🇮🇳India gauravvvv Delhi, India

    Updated IS with new solution

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Build Successful
  • Status changed to Needs work over 1 year ago
  • 🇺🇸United States smustgrave

    Patch has failures.

    Issue summary appears to still be missing pieces specifically User interface section. Please use full issue template.

    Also was tagged for tests.

  • 🇮🇳India nayana_mvr

    I verified the latest patch #14 and it applied cleanly. It fixes the issue mentioned in the ticket description and #9. Also, I tried to add the class hidden in few other elements also eg., image field and the field is getting hidden from FE as expected. Please see the attached screenshots for reference.
    I have updated the User interface section in Issue summary with screenshots. Need to write tests.

  • 🇮🇳India nayana_mvr

    Screenshots didn't get attached in the previous comment. Attaching it here again.

Production build 0.71.5 2024