Hidden
A way to hide content elements in certain browser conditions.
The Basics
What it is
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.
How it works
- 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.
When to use
- To hide content in certain conditions, like hiding a page menu on mobile but showing it on desktop
When not to use
- For content where users can toggle its visibility
What to use instead
Use ShowHide to hide content initially but enable users to display it easily.
How to use
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.
Style
Design details
No additional information for this component.
Placement and hierarchy
By default, Hidden hides content in certain conditions, and the elements below that content shift up.
Content
Doesn’t apply to this component.
Demos
Coding
Developer tips
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.
Repository
Implementation links
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 accessibility in mind. These components do break the recommendations listed above.
Import statements
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';