You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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 ().
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).
The text was updated successfully, but these errors were encountered:
I would be keen to give it a shot. I'm not sure I'll have a chance to look at it before the end of this year though, as a heads up 😊
I think it'll be easier to build it with confidence on top of #36029, which adds the sass-true tests, so there's a safety net for the current functionalities.
@romaricpascal Whenever you want to dive back into this, let's talk a bit more about the utility API's future. Plenty of opportunities to improve things here as we move toward a v6 :).
@mdo That's still something I'd be keen to explore, but the time I can spend on Bootstrap is turning out to be very very limited. I don't want this held back if someone else is keen to move it forward 😊
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:
which breakpoints the utilities get generated for, allowing the
responsive
option to accept either:breakpoint => (list of value identifiers)
map, allowing to not only subset breakpoints, but which values of the utility get set for themFor example:
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 tonull
or an empty list()
.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 togetherMotivation 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).
The text was updated successfully, but these errors were encountered: