The Totally different (and Trendy) Methods To Toggle Content material | CSS-Methods

If all you’ve gotten is a hammer, every part seems like a nail.

Abraham Maslow

It’s simple to default to what . In terms of toggling content material, that could be reaching for show: none or opacity: 0 with some JavaScript sprinkled in. However the internet is extra “trendy” in the present day, so maybe now could be the fitting time to get a birds-eye view of the other ways to toggle content material — which native APIs are literally supported now, their professionals and cons, and a few issues about them that you simply won’t know (reminiscent of any pseudo-elements and different non-obvious stuff).

So, let’s spend a while disclosures (<particulars> and <abstract>), the Dialog API, the Popover API, and extra. We’ll have a look at the fitting time to make use of every one relying in your wants. Modal or non-modal? JavaScript or pure HTML/CSS? Unsure? Don’t fear, we’ll go into all that.

Disclosures (<particulars> and <abstract>)

Use case: Accessibly summarizing content material whereas making the content material particulars togglable independently, or as an accordion.

Getting in launch order, disclosures — identified by their components as <particulars> and <abstract> — marked the primary time we have been in a position to toggle content material with out JavaScript or bizarre checkbox hacks. However lack of internet browser assist clearly holds new options again at first, and this one specifically got here with out keyboard accessibility. So I’d perceive in case you haven’t used it because it got here to Chrome 12 method again in 2011. Out of sight, out of thoughts, proper?

Right here’s the low-down:

• It’s practical with out JavaScript (with none compromises).
• It’s totally stylable with out look: none or the like.
• You may conceal the marker with out non-standard pseudo-selectors.
• You may join a number of disclosures to create an accordion.
• Aaaand… it’s totally animatable, as of 2024.

Marking up disclosures

What you’re in search of is that this:

<particulars>
  <abstract>Content material abstract (all the time seen)</abstract>
  Content material (visibility is toggled when abstract is clicked on)
</particulars>

Behind the scenes, the content material’s wrapped in a pseudo-element that as of 2024 we will choose utilizing ::details-content. So as to add to this, there’s a ::marker pseudo-element that signifies whether or not the disclosure’s open or closed, which we will customise.

With that in thoughts, disclosures truly appear to be this underneath the hood:

<particulars>
  <abstract><::marker></::marker>Content material abstract (all the time seen)</abstract>
  <::details-content>
      Content material (visibility is toggled when abstract is clicked on)
  </::details-content>
</particulars>

To have the disclosure open by default, give <particulars> the open attribute, which is what occurs behind the scenes when disclosures are opened anyway.

<particulars open> ... </particulars>

Styling disclosures

Let’s be actual: you in all probability simply wish to lose that annoying marker. Properly, you are able to do that by setting the show property of <abstract> to something however list-item:

abstract {
  show: block; /* Or anything that is not list-item */
}

Alternatively, you possibly can modify the marker. Actually, the instance beneath makes use of Font Superior to switch it with one other icon, however take into account that ::marker doesn’t assist many properties. Probably the most versatile workaround is to wrap the content material of <abstract> in a component and choose it in CSS.

<particulars>
  <abstract><span>Content material abstract</span></abstract>
  Content material
</particulars>

particulars {
  
  /* The marker */
  abstract::marker {
    content material: "f150";
    font-family: "Font Superior 6 Free";
  }

  /* The marker when <particulars> is open */
  &[open] abstract::marker {
    content material: "f151";
  }
  
  /* As a result of ::marker doesn’t assist many properties */
  abstract span {
    margin-left: 1ch;
    show: inline-block;
  }
  
}

Creating an accordion with a number of disclosures

To create an accordion, identify a number of disclosures (they don’t even should be siblings) with a identify attribute and an identical worth (much like the way you’d implement <enter kind="radio">):

<particulars identify="starWars" open>
  <abstract>Prequels</abstract>
  <ul>
    <li>Episode I: The Phantom Menace</li>
    <li>Episode II: Assault of the Clones</li>
    <li>Episode III: Revenge of the Sith</li>
  </ul>
</particulars>

<particulars identify="starWars">
  <abstract>Originals</abstract>
  <ul>
    <li>Episode IV: A New Hope</li>
    <li>Episode V: The Empire Strikes Again</li>
    <li>Episode VI: Return of the Jedi</li>
  </ul>
</particulars>

<particulars identify="starWars">
  <abstract>Sequels</abstract>
  <ul>
    <li>Episode VII: The Pressure Awakens</li>
    <li>Episode VIII: The Final Jedi</li>
    <li>Episode IX: The Rise of Skywalker</li>
  </ul>
</particulars>

Utilizing a wrapper, we will even flip these into horizontal tabs:

<div> <!-- Flex wrapper -->
  <particulars identify="starWars" open> ... </particulars>
  <particulars identify="starWars"> ... </particulars>
  <particulars identify="starWars"> ... </particulars>
</div>

div {
  hole: 1ch;
  show: flex;
  place: relative;

  particulars {
    min-height: 106px; /* Prevents content material shift */
      
    &[open] abstract,
    &[open]::details-content {
      background: #eee;
    }

    &[open]::details-content {
      left: 0;
      place: absolute;
    } 
  }
}

…or, utilizing 2024’s Anchor Positioning API, vertical tabs (identical HTML):

div {
  
  show: inline-grid;
  anchor-name: --wrapper;

  particulars[open] {
      
    abstract,
    &::details-content {
      background: #eee;
    }

    &::details-content {
      place: absolute;
      position-anchor: --wrapper;
      prime: anchor(prime);
      left: anchor(proper);
    } 
  }
}

In case you’re in search of some wild concepts on what we will do with the Popover API in CSS, try John Rhea’s article through which he makes an interactive recreation solely out of disclosures!

Including JavaScript performance

Need to add some JavaScript performance?

// Non-obligatory: choose and loop a number of disclosures
doc.querySelectorAll("particulars").forEach(particulars => {
  particulars.addEventListener("toggle", () => {
    // The disclosure was toggled
    if (particulars.open) {
      // The disclosure was opened
    } else {
      // The disclosure was closed
    }
  });    
});

Creating accessible disclosures

Disclosures are accessible so long as you comply with a number of guidelines. For instance, <abstract> is principally a <label>, which means that its content material is introduced by display screen readers when in focus. If there isn’t a <abstract> or <abstract> isn’t a direct youngster of <particulars> then the consumer agent will create a label for you that usually says “Particulars” each visually and in assistive tech. Older internet browsers may insist that or not it’s the first youngster, so it’s greatest to make it so.

So as to add to this, <abstract> has the function of button, so no matter’s invalid inside a <button> can also be invalid inside a <abstract>. This consists of headings, so you possibly can model a <abstract> as a heading, however you possibly can’t truly insert a heading right into a <abstract>.

The Dialog component (<dialog>)

Use case: Modals

Now that we’ve got the Popover API for non-modal overlays, I believe it’s greatest if we begin to consider dialogs as modals despite the fact that the present() methodology does permit for non-modal dialogs. The benefit that the popover attribute has over the <dialog> component is that you need to use it to create non-modal overlays with out JavaScript, so in my view there’s no profit to non-modal dialogs anymore, which do require JavaScript. For readability, a modal is an overlay that makes the principle doc inert, whereas with non-modal overlays the principle doc stays interactive. There are a number of different options that modal dialogs have out-of-the-box as properly, together with:

• a stylable backdrop,
• an autofocus onto the primary focusable component inside the <dialog> (or, as a backup, the <dialog> itself — embrace an aria-label on this case),
• a spotlight entice (on account of the principle doc’s inertia),
• the esc key closes the dialog, and
• each the dialog and the backdrop are animatable.Marking up and activating dialogs

Begin with the <dialog> component:

<dialog> ... </dialog>

It’s hidden by default and, much like <particulars>, we will have it open when the web page hundreds, though it isn’t modal on this situation because it doesn’t include interactive content material as a result of it doesn’t opened with showModal().

<dialog open> ... </dialog>

I can’t say that I’ve ever wanted this performance. As a substitute, you’ll doubtless wish to reveal the dialog upon some sort of interplay, reminiscent of the press of a button — so right here’s that button:

<button data-dialog="dialogA">Open dialogA</button>

Wait, why are we utilizing knowledge attributes? Properly, as a result of we’d wish to hand over an identifier that tells the JavaScript which dialog to open, enabling us so as to add the dialog performance to all dialogs in a single snippet, like this:

// Choose and loop all components with that knowledge attribute
doc.querySelectorAll("[data-dialog]").forEach(button => {
  // Pay attention for interplay (click on)
  button.addEventListener("click on", () => {
    // Choose the corresponding dialog
    const dialog = doc.querySelector(`#${ button.dataset.dialog }`);
    // Open dialog
    dialog.showModal();      
    // Shut dialog
    dialog.querySelector(".closeDialog").addEventListener("click on", () => dialog.shut());
  });
});

Don’t overlook so as to add an identical id to the <dialog> so it’s related to the <button> that exhibits it:

<dialog id="dialogA"> <!-- id and data-dialog = dialogA --> ... </dialog>

And, lastly, embrace the “shut” button:

<dialog id="dialogA">
  <button class="closeDialog">Shut dialogA</button>
</dialog>

Observe: <type methodology="dialog"> (that has a <button>) or <button formmethod="dialog"> (wrapped in a <type>) additionally closes the dialog.

Easy methods to stop scrolling when the dialog is open

Forestall scrolling whereas the modal’s open, with one line of CSS:

physique:has(dialog:modal) { overflow: hidden; }

Styling the dialog’s backdrop

And at last, we’ve got the backdrop to scale back distraction from what’s beneath the highest layer (this is applicable to modals solely). Its kinds may be overwritten, like this:

::backdrop {
  background: hsl(0 0 0 / 90%);
  backdrop-filter: blur(3px); /* A enjoyable property only for backdrops! */
}

On that observe, the <dialog> itself comes with a border, a background, and a few padding, which you may wish to reset. Truly, popovers behave the identical method.

Coping with non-modal dialogs

To implement a non-modal dialog, use:

• present() as an alternative of showModal()
• dialog[open] (targets each) as an alternative of dialog:modal

Though, as I mentioned earlier than, the Popover API doesn’t require JavaScript, so for non-modal overlays I believe it’s greatest to make use of that.

The Popover API (<component popover>)

Use case: Non-modal overlays

Popups, principally. Appropriate use circumstances embrace tooltips (or toggletips — it’s vital to know the distinction), onboarding walkthroughs, notifications, togglable navigations, and different non-modal overlays the place you don’t wish to lose entry to the principle doc. Clearly these use circumstances are completely different to these of dialogs, however nonetheless popovers are extraordinarily superior. Functionally they’re identical to simply dialogs, however not modal and don’t require JavaScript.

Marking up popovers

To start, the popover wants an id in addition to the popover attribute with the handbook worth (which implies clicking exterior of the popover doesn’t shut it), the auto worth (clicking exterior of the popover does shut it), or no worth (which implies the identical factor). To be semantic, the popover is usually a <dialog>.

<dialog id="tooltipA" popover> ... </dialog>

Subsequent, add the popovertarget attribute to the <button> or <enter kind="button"> that we wish to toggle the popover’s visibility, with a price matching the popover’s id attribute (that is non-obligatory since clicking exterior of the popover will shut it anyway, except popover is about to handbook):

<dialog id="tooltipA" popover>
  <button popovertarget="tooltipA">Cover tooltipA</button>
</dialog>

Place one other a kind of buttons in your predominant doc, in an effort to present the popover. That’s proper, popovertarget is definitely a toggle (except you specify in any other case with the popovertargetaction attribute that accepts present, conceal, or toggle as its worth — extra on that later).

Styling popovers

By default, popovers are centered inside the prime layer (like dialogs), however you in all probability don’t need them there as they’re not modals, in any case.

<predominant>
  <button popovertarget="tooltipA">Present tooltipA</button>
</predominant>

<dialog id="tooltipA" popover>
  <button popovertarget="tooltipA">Cover tooltipA</button>
</dialog>

You may simply pull them right into a nook utilizing mounted positioning, however for a tooltip-style popover you’d need it to be relative to the set off that opens it. CSS Anchor Positioning makes this tremendous simple:

predominant [popovertarget] {
  anchor-name: --trigger;
}

[popover] {
  margin: 0;
  position-anchor: --trigger;
  prime: calc(anchor(backside) + 10px);
  justify-self: anchor-center;
}

/* This additionally works however isn’t wanted
except you’re utilizing the show property
[popover]:popover-open {
    ...
}
*/

The issue although is that it’s a must to identify all of those anchors, which is ok for a tabbed element however overkill for a web site with fairly a number of tooltips. Fortunately, we will match an id attribute on the button to an anchor attribute on the popover, which isn’t well-supported as of November 2024 however will do for this demo:

<predominant>
  <!-- The id ought to match the anchor attribute -->
  <button id="anchorA" popovertarget="tooltipA">Present tooltipA</button>
  <button id="anchorB" popovertarget="tooltipB">Present tooltipB</button>
</predominant>

<dialog anchor="anchorA" id="tooltipA" popover>
  <button popovertarget="tooltipA">Cover tooltipA</button>
</dialog>

<dialog anchor="anchorB" id="tooltipB" popover>
  <button popovertarget="tooltipB">Cover tooltipB</button>
</dialog>

predominant [popovertarget] { anchor-name: --anchorA; } /* Not wanted */

[popover] {
  margin: 0;
  position-anchor: --anchorA; /* Not wanted */
  prime: calc(anchor(backside) + 10px);
  justify-self: anchor-center;
}

The subsequent problem is that we count on tooltips to point out on hover and this doesn’t do this, which implies that we have to use JavaScript. Whereas this appears sophisticated contemplating that we will create tooltips far more simply utilizing ::earlier than/::after/content material:, popovers permit HTML content material (through which case our tooltips are literally toggletips by the way in which) whereas content material: solely accepts textual content.

Including JavaScript performance

Which leads us to this…

Okay, so let’s check out what’s occurring right here. First, we’re utilizing anchor attributes to keep away from writing a CSS block for every anchor component. Popovers are very HTML-focused, so let’s use anchor positioning in the identical method. Secondly, we’re utilizing JavaScript to point out the popovers (showPopover()) on mouseover. And lastly, we’re utilizing JavaScript to cover the popovers (hidePopover()) on mouseout, however not in the event that they include a hyperlink as clearly we wish them to be clickable (on this situation, we additionally don’t conceal the button that hides the popover).

<predominant>
  <button id="anchorLink" popovertarget="tooltipLink">Open tooltipLink</button>
  <button id="anchorNoLink" popovertarget="tooltipNoLink">Open tooltipNoLink</button>
</predominant>

<dialog anchor="anchorLink" id="tooltipLink" popover>Has <a href="#">a hyperlink</a>, so we will’t conceal it on mouseout
  <button popovertarget="tooltipLink">Cover tooltipLink manually</button>
</dialog>

<dialog anchor="anchorNoLink" id="tooltipNoLink" popover>Doesn’t have a hyperlink, so it’s nice to cover it on mouseout mechanically
  <button popovertarget="tooltipNoLink">Cover tooltipNoLink</button>
</dialog>

[popover] {
  
  margin: 0;
  prime: calc(anchor(backside) + 10px);
  justify-self: anchor-center;

  /* No hyperlink? No button wanted */
  &:not(:has(a)) [popovertarget] {
    show: none;
  }
}

/* Choose and loop all popover triggers */
doc.querySelectorAll("predominant [popovertarget]").forEach((popovertarget) => {
  
  /* Choose the corresponding popover */
  const popover = doc.querySelector(`#${popovertarget.getAttribute("popovertarget")}`);
  
  /* Present popover on set off mouseover */
  popovertarget.addEventListener("mouseover", () => {
    popover.showPopover();
  });

  /* Cover popover on set off mouseout, however not if it has a hyperlink */
  if (popover.matches(":not(:has(a))")) {
    popovertarget.addEventListener("mouseout", () => {
      popover.hidePopover();
    });
  }
});

Implementing timed backdrops (and sequenced popovers)

At first, I used to be positive that popovers having backdrops was an oversight, the argument being that they shouldn’t obscure a focusable predominant doc. However possibly it’s okay for a few seconds so long as we will resume what we have been doing with out being pressured to shut something? Not less than, I believe this works properly for a set of onboarding suggestions:

<!-- Re-showing ‘A’ rolls the onboarding again to that step -->
<button popovertarget="onboardingTipA" popovertargetaction="present">Restart onboarding</button>
<!-- Hiding ‘A’ additionally hides subsequent suggestions so long as the popover attribute equates to auto -->
<button popovertarget="onboardingTipA" popovertargetaction="conceal">Cancel onboarding</button>

<ul>
  <li id="toolA">Software A</li>
  <li id="toolB">Software B</li>
  <li id="toolC">One other device, “C”</li>
  <li id="toolD">One other device — let’s name this one “D”</li>
</ul>

<!-- onboardingTipA’s button triggers onboardingTipB -->
<dialog anchor="toolA" id="onboardingTipA" popover>
  onboardingTipA <button popovertarget="onboardingTipB" popovertargetaction="present">Subsequent tip</button>
</dialog>

<!-- onboardingTipB’s button triggers onboardingTipC -->
<dialog anchor="toolB" id="onboardingTipB" popover>
  onboardingTipB <button popovertarget="onboardingTipC" popovertargetaction="present">Subsequent tip</button>
</dialog>

<!-- onboardingTipC’s button triggers onboardingTipD -->
<dialog anchor="toolC" id="onboardingTipC" popover>
  onboardingTipC <button popovertarget="onboardingTipD" popovertargetaction="present">Subsequent tip</button>
</dialog>

<!-- onboardingTipD’s button hides onboardingTipA, which in-turn hides all suggestions -->
<dialog anchor="toolD" id="onboardingTipD" popover>
  onboardingTipD <button popovertarget="onboardingTipA" popovertargetaction="conceal">End onboarding</button>
</dialog>

::backdrop {
  animation: 2s fadeInOut;
}

[popover] {
  margin: 0;
  align-self: anchor-center;
  left: calc(anchor(proper) + 10px);
}

/*
After customers have had a few
seconds to breathe, begin the onboarding
*/
setTimeout(() => {
  doc.querySelector("#onboardingTipA").showPopover();
}, 2000);

Once more, let’s unpack. Firstly, setTimeout() exhibits the primary onboarding tip after two seconds. Secondly, a easy fade-in-fade-out background animation runs on the backdrop and all subsequent backdrops. The principle doc isn’t made inert and the backdrop doesn’t persist, so consideration is diverted to the onboarding suggestions whereas not feeling invasive.

Thirdly, every popover has a button that triggers the following onboarding tip, which triggers one other, and so forth, chaining them to create a completely HTML onboarding move. Usually, exhibiting a popover closes different popovers, however this doesn’t look like the case if it’s triggered from inside one other popover. Additionally, re-showing a visual popover rolls the onboarding again to that step, and, hiding a popover hides it and all subsequent popovers — though that solely seems to work when popover equates to auto. I don’t totally perceive it nevertheless it’s enabled me to create “restart onboarding” and “cancel onboarding” buttons.

With simply HTML. And you may cycle by means of the ideas utilizing esc and return.

Creating modal popovers

Hear me out. In case you just like the HTML-ness of popover however the semantic worth of <dialog>, this JavaScript one-liner could make the principle doc inert, due to this fact making your popovers modal:

doc.querySelectorAll("dialog[popover]").forEach(dialog => dialog.addEventListener("toggle", () => doc.physique.toggleAttribute("inert")));

Nevertheless, the popovers should come after the principle doc; in any other case they’ll additionally develop into inert. Personally, that is what I’m doing for modals anyway, as they aren’t part of the web page’s content material.

<physique>
  <!-- All of it will develop into inert -->
</physique>

<!-- Due to this fact, the modals should come after -->
<dialog popover> ... </dialog>

Aaaand… breathe

Yeah, that was quite a bit. However…I believe it’s vital to have a look at all of those APIs collectively now that they’re beginning to mature, with a purpose to actually perceive what they’ll, can’t, ought to, and shouldn’t be used for. As a parting reward, I’ll go away you with a transition-enabled model of every API: