twbs / twbs/bootstrap

Finer control on utilities responsiveness

Open
#36,330 4 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

css feature utility API
Dominant language
MDX
Stars
175k
Forks
78.6k
Avg merge
7h 19m
Merged PRs (30d)
35

Description

Prerequisites
Proposal

I realise that I never got to post the thoughts for utilities improvement I mentioned in #36029.

The idea would be to provide finer control over the responsiveness of utilities and let users control:

  1. which breakpoints the utilities get generated for, allowing the responsive option to accept either:

    • a list of breakpoints, with the subset of breakpoints for which to generate the utility
    • a breakpoint => (list of value identifiers) map, allowing to not only subset breakpoints, but which values of the utility get set for them

    For example:

    (
      "max-width": (
      property: max-width,
      class: mw,
      responsive: (md), // Generates only `mw-100` and `mw-md-100`
      values: (100: 100%)
    ),
    

    This may call for a special default key for the list to enable configuring what's generated for the class without breakpoint (or even disable its generation altogether by associating it to null or an empty list ().

  2. which values the utility take at specific breakpoints, by setting its value as a breakpoint => actual value map. I've got a bit less faith of this one, especially if there's a way to have fine grained utilities, but that could save stringing a few utilities together

Motivation and context

The motivation is mostly to avoid adding many breakpoints when switching a utility to be responsive. This could also let developers further optimise their build, but it'll likely be less burden to use something like PurgeCSS for that (though not every user will have access/be willing to use it or a similar tool as part of their build).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or entry points. Start by locating the utility API’s responsive breakpoint and value-generation logic, then review existing tests for utility output. Done means agreeing on the configuration shape and covering the selected breakpoint and value combinations with tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
scss
Domain
frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.