Generate placeholder ranges for all breakpoints for everything

[RussellBishop]

@burntcustard @cjquinn we should spec out how, step by step, a developer would configure, select, and use these placeholders.

For example:

• Select a property margin-top

• Define it's possible value ranges auto, 1–20rem, 0-100%

• Extend the property inside of a component @extend %u-mt-6rem

• See that the component needs a breakpoint…

• Add a breakpoint to the global list news-grid: 900px

• Modify the extend for before, and after, that breakpoint @extend %u-mt-6rem--upto-news-grid @extend %u-mt-auto--from-news-grid

[RussellBishop]

One part of the workflow I suggest this misses is how easy it is to build up the first version of a component with only utilities - either in the browser directly (devTools), or in your theme file.

It's nice to be able to 'paint' like this before you create a new component, name it, import it…

Also – those classes won't just be for 'building', but also sometimes you don't need a new object or component, you just need a few utilities to style something.

So how might we adapt the settings to allow for this?

Perhaps you have a switch that:

$createClassForEachPlaceholder: true;

That doesn't solve the problem with keep some classes at the end though. Perhaps you do that manually?

$u-mt-rem: 1, 5, 6, 7, 8;

@each $i in $u-mt-rem {
  .u-mt-#{$i}rem {
    @extend %u-mt-#{$i}rem;
  }
}

[RussellBishop]

Lastly @burntcustard your version was based around building an object placeholder, would it work the other way round do you think?

I can see some weird complications around wasted classes with an object that swaps our properties unnecessarily. E.g.

@media A - B {
...
width: 100vw
}

@media B - C {
...
width: 100vw
}

[burntcustard]

I've started work on this, in the feature/auto-placeholder-gen branch.

There's a (currently untested) auto-gen-placeholders mixin in there, which should be able to take a SASS map containing a CSS property and a bunch of other values, and generate placeholders within a single specified range, for all the $global-breakpoints.

After I've checked it works, the next step for that mixin would be allowing it to work for multiple ranges or configurations. E.g. allowing both 10% -> 20% and 100px -> 200px.

[RussellBishop]

This is a good start @burntcustard ! Some comments on progress:

Mixin Really like the use of map-use, that simplifies a lot of the defaults setting I had in place before.

Settings Like the simplification of how the map gets appended here - simpler than my implementation and still easy to understand.

Regarding the map's keys, are you proposing to move away from the (string||list) pattern we have at the moment?

property: 'grid-column-start', // string
property: ('grid-column-start', 'gcs'), // list

(
  absolute, // string
  (absolute, abs), // list
)

In terms of what else this settings map needs to allow as an input, we also have:

• functions (colspan(x), baseline(y))
• non-unit values (calc(var(--TextSize) * x)
• keywords (auto, flex, grid, none)
• combinators (> + , ~ :checked)

Regarding the different units we need (and functions above), what about a syntax like this?

If we keep the values of each unit as a separate setting, they can each have a preset prefix/postfix (as this should be consistent anyway for guessability).

/settings/_utilities-width.scss

// start, end, integer (1 default)
$values: (
    numbers: (0, 100, 5),
    pixels: (-10, 200, 10),
    rems: (-10, 10),

   // custom (settings elsewhere)
    baseline: (1, 20)
),

$utilities-property...... (
  property: width;
  values: $values; // (above)
)

...

/settings/_units.scss

$units: (
  pixels: ('', 'px);
  rems: ('', 'rm);
),

$custom-units: (
   'baseline': (
     'calc(var(--Baseline) * '$i'
   ),
),

Syntax I've just seen that you can use a colon in a placeholder name, what do you think about :from-large?

https://www.sassmeister.com/gist/49b44279c48fc2d68135e0ffa70d3706

%u-color-blue:from-large {
  @media (min-width: 1000px) {
    color: blue;
  }
}

.test {
  @extend %u-color-blue:from-large;
}

[burntcustard]

Thanks! None of my "alternative ways" of doing things were exactly suggestions that we should move away from current patterns, they were simply me experimenting with other (potentially simpler as you've pointed out!) techniques. Specifically with the string || list change though; I think having an optional shorthand "alias" for the property is slightly easier to initially get your head around than either having a string, or a list with two strings in.

I really like your different-units-suggestions, but I've got another cunning plan for getting the different units and functions in, using call(), but I'll need to experiment a bit to see: a) if it's possible, and b) if it's not too much more complex than defining the current inputs.

The : for the property-alias/breakpoint separator looks good - I'm thinking we should switch to that, but I'd have to sit and stare at it for a few minutes on a big screen before I'm 100% convinced!