Choosing Between Bulma Visibility Helpers and Custom Media Queries for Responsive UI

Decision: Use Bulma visibility helpers or custom media queries?

When you need to show or hide parts of a interface at certain viewport widths, you have two main options in a Bulma‑based project:

1. Apply Bulma’s built‑in visibility helper classes (e.g., is-hidden-tablet).
2. Write your own CSS media query that targets the same breakpoint range.

The decision hinges on constraints such as keeping HTML readable, avoiding duplicated breakpoint values, and ensuring that future design‑system changes propagate automatically.

Comparison table

h>Cons

Option	Pros
Bulma visibility helpers	No extra CSS authoring; the classes map to breakpoints already compiled in Bulma. Consistent with the framework’s breakpoint map ($value). Zero maintenance overhead if you stay within the default breakpoints.	Limited to the predefined breakpoint names (mobile, tablet, desktop, widescreen, fullhd). Can clutter HTML when many modifiers are applied to the same element.
Custom media queries	Full control over breakpoint values; you can set any pixel or em threshold. Ability to combine conditions (e.g., show only between two breakpoints) in a single rule. Encapsulates visibility logic in CSS, keeping markup cleaner.	Requires you to duplicate breakpoint values or maintain a separate map. Adds to the final stylesheet size unless you purge unused CSS. If Bulma’s breakpoint map changes, you must update your custom queries manually.

Trade‑offs

If your design fits within Bulma’s default breakpoint set and you prefer a declarative markup approach, the visibility helpers reduce CSS authoring and keep the styling in sync with the framework. When you need a breakpoint that does not exist in $value, or you want to express complex logic (e.g., "show only on tablet‑landscape but not on portrait"), a custom media query offers the necessary flexibility at the cost of extra CSS and the responsibility to keep breakpoint values aligned with Bulma’s map.

Implementation example

Below is a minimal example that demonstrates both approaches. Load Bulma’s CSS (via CDN or your build pipeline) and place the HTML in a file you can open in a browser.

<!-- Load Bulma (example via CDN) -->
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bulma@0.9.4/css/bulma.min.css">

<style>
/* Custom media query: show only between 768px and 1023px */
@media (min-width: 768px) and (max-width: 1023px) {
  .show-tablet-only { display: block !important; }
}
.hide-tablet-custom { display: none; }
@media (min-width: 768px) and (max-width: 1023px) {
  .hide-tablet-custom { display: block !important; }
}
</style>

<div class="container">
  <!-- Using Bulma helper classes -->
  <p class="is-hidden-mobile">
    Visible on tablet and up (helper).
  </p>
  <p class="is-hidden-tablet">
    Hidden on tablet, visible elsewhere (helper).
  </p>

  <!-- Using custom media query -->
  <p class="show-tablet-only">
    Visible only between 768px and 1023px (custom).
  </p>
  <p class="hide-tablet-custom">
    Hidden between 768px and 1023px (custom).
  </p>
</div>

To verify the behavior:

1. Open the page in a browser.
2. Open DevTools and toggle the device toolbar, or simply resize the window.
3. Observe that the helper‑class paragraphs appear/disappear at the breakpoint values defined by Bulma’s default $value map (mobile ≤ 768px, tablet ≥ 769px ≤ 1023px, desktop ≥ 1024px).
4. Check that the custom‑query paragraphs follow the same show/hide pattern for the 768‑1023px range.

If you have extended Bulma’s Sass with additional breakpoints, recompile the CSS and repeat the steps; the helper classes will reflect the new values, while your custom queries will need manual adjustment.

Limitations and practical checks

• Visibility helpers only generate display:none; they do not support more complex layout changes (e.g., switching from block to flex). For those cases, a custom media query or a dedicated utility class is preferable.
• Over‑applying many helper classes to a single element can make the HTML harder to read. Consider extracting the logic into a Vue/React component or a templating partial if the pattern repeats.
• To confirm that no unintended CSS is being added, inspect the Computed pane in DevTools for the element and verify that the display property toggles between none and the expected value at each breakpoint.