Hidden is used to hide parts of a page in certain browser conditions, such as hiding navigation features in print mode. It can be set to hide content based on detected screen size (mobile or desktop) or context (print or screen). It can also be stacked to hide content under multiple conditions.

• A page or page section with elements wrapped in the Hidden component detects whether to display that content based on the user’s setup.
• If the user has a screen size or context that causes content to be hidden, the content doesn’t appear on the page.

• To hide content in certain conditions, like hiding a page menu on mobile but showing it on desktop

• For content where users can toggle its visibility

Use Hidden to hide content in these conditions:

• On desktop
• On mobile
• On screen
• When printed

By default, elements in Hidden are displayed on their own separate line (i.e., CSS display:block). When Hidden is activated, the content in Hidden isn’t visible, and the elements below it shift up into the space it occupied.

You can instead set the elements in Hidden as inline, which means the content in Hidden flows on the same baseline as the content before or after it (i.e., CSS display:inline). This is suitable for a line of text that, when visible, is part of a longer paragraph that’s always visible.

Always test Hidden. If you use Hidden to hide something on print, print a test page (or print to PDF) to make sure it’s working.

No additional information for this component.

By default, Hidden hides content in certain conditions, and the elements below that content shift up.

Doesn’t apply to this component.

The Hidden setting below='desktop' hides content on screens that are less than 640px wide. Hidden above= 'mobile' hides content on screens that are 640px or wider. This measurement corresponds to our Small breakpoint. For more information about responsive breakpoints, see Grid Basics.

When using multiple props to hide content in multiple conditions, Hidden hides content when one or more of the conditions is true.

You can see Hidden in action by using our demos. You may need to edit the demo code to see the different behavior. For example:

• In the Hidden on Desktop demo, edit the code and change the above prop to 'desktop'. This “unhides” the component’s child text.
• In the Hidden Inline demo, edit the code and delete the inline prop. Notice how the text is displayed on the next line.
• For the Hidden on Print demo, use your browser’s Print command to display the print preview. Confirm that the text doesn't appear in the print preview.

Implementation links

Hidden directory in Bitbucket

Implementation details

It is strongly recommended to familiarize yourself with the Forge source code. While this documentation is a best effort to document the intent and usage of a component, sometimes some features only become clear when looking at the source code. Also, looking at Forge's source code may help identify and fix bugs in either your application or Forge itself.

Storybook files

Forge maintains at least one storybook file per component. While the primary audience for these files is typically the Forge team, these storybook files may cover usages of the component not covered by a demo. The storybook for the latest version of forge can be found at go/forge-storybook.

Testing library

Forge strongly encourages using testing-library to write tests for your application.

"The more your tests resemble the way your software is used, the more confidence they can give you."

If you're having trouble testing a Forge component using testing-library, it would be a good idea to see how Forge tests its own components. For the most part, Forge tries to use screen.getByRole as much as it can, as that API provides the best feedback on a11y compliance. Forge discourages the use of document.querySelector and screen.getByTestId as both APIs encourage using implementation details to test your component, and discourage adding roles to your component.

With that being said, many of Forge's components were not built with accessability in mind. These components do break the recommendations listed above.

In Nimbus applications

athenaOne serves the Forge bundle independently from your application's bundle. Importing Forge components directly from '@athena/forge' takes advantage of this feature.

import { Hidden } from '@athena/forge'

In standalone applications

Importing components using the exact path to the module takes advantage of webpack's tree shaking feature. Webpack will include only that module and its dependencies.

import Hidden from '@athena/forge/Hidden';

To use this import guidance, Typescript applications must use typescript >= 4.7.3, and should add this setting to their tsconfig.json file:

{
  "compilerOptions": {
    "moduleResolution": "Node16",
  }
}

If this setting doesn't work for your application, use this import statement instead:

import Hidden from '@athena/forge/dist/Hidden';