How do we move logical shorthands forward?
There are several proposals, but one major road block
We’re trying to make progress on shorthand syntax for CSS logical properties. But the path forward depends on where we hope to be a decade from now.
Susy Next alpha 5 is out, and loaded with changes. We now require Sass 3.3, we no longer require Compass, and there have been major syntax improvements. We’re getting real close to launch, and we’d love to know what you think. Play around, and let us know!
Susy Next is almost feature complete! Alpha 5 is loaded with changes – some as a result of alpha testing, but mostly in response to the new power of Sass 3.3. This is likely to be our final alpha. With a bit more user testing and some minor cleanup, we hope to hit beta soon and then land a stable version along side the upcoming releases of Compass and Sass.
Sass 3.3 is awesome, and we’ve made a lot of changes in Susy to take
full advantage of the new toys. We started integrating the new
SassScript Maps data type (not to be confused with Source Maps), and
the side benefits were huge. We’re also using the new
variable-exists()
and mixin-exists()
functions to check for the
presence of various compass features, and degrade gracefully if they
aren’t available.
In brief: Sass 3.3 is now required and Compass is no longer required, although we do tie in with Compass features such as vertical-rhythms if they are available.
The first thing to do, after upgrading Sass, is to translate your Susy settings into a single map of key/value pairs. For a long time the only way to establish defaults and user overrides in a Sass plugin has been to use variables. In Susy 1 and the early alpha releases, we did the same:
$columns: 6;
$gutters: 1/4;
$gutter-position: inside;
But that clogs up the global namespace in ugly ways. Now, thanks to SassScript Maps, we have a new solution that keeps everything contained, and comes with side-benefits for anyone using multiple grids:
$susy: (
columns: 6,
gutters: 1/4,
gutter-position: inside,
);
There is only one variable, named $susy
, that takes a map of all your
settings. You can still use the grid shorthand with set-grid
or
use-grid
:
@include set-grid(6 1/4 inside);
But you can also mix-and-match shorthand with maps, both for grid-settings and for spans:
$large: (
columns: 12,
container: 90em,
);
@include use-grid($large inside) {
// ...
}
@include span(3 $large);
If you need access the current value of a setting, just use
susy-get(setting-name)
:
$current-columns: susy-get(columns);
Susy Next supports several gutter styles: after
(the Susy 1 approach),
before
, inside
, inside-static
, and split
. Before, after, and
split all use margins. Inside and inside-static use padding.
In previous alphas, split
worked like before
and after
, and you
had to remove the first
and last
edge-gutters. That felt wrong, so
we fixed it. Split gutters now work similar to inside gutters, and there
is no reason to remove them at the edges of the grid. That simplifies
most things, but it complicates nesting. You don’t want gutters added to
the edges of an outer element, and then added again to the edges of
inner elements.
Susy is very flexible, and there are many ways you can work around that
problem already, but we added a container
shortcut to make it easier.
.outer-element {
@include span(6 of 12 container);
.inner-element { @include span(3 of 6); }
}
People are often confused about spanning full widths in Susy. I often
see @include span(12 of 12);
or the Susy 1 equivalent. That’s not
necessary, and adds a fair amount of extra output that you don’t need.
Really, in most cases you don’t need anything at all – block elements
span the full width by default. Sometimes, though, you need to clear the
previous floats (clear: both
), or you need to clear internal floats
(clearfix
), but those seemed simple enough that we didn’t bake them
in.
That’s changing. Thanks to the added complexity of inside and split
gutters, which also need to be applied on full-width elements, we’ve
added a full
mixin. Use it!
// Wrong! (usually)
@include span(12 of 12);
// Right!
@include full(of 12);
bleed
now takes standard span syntax, with multiple (TRBL) spans,
e.g. bleed(1em 2 of 8)
for 1em top/bottom and 2-columns
left/right. Use bleed-x
and bleed-y
mixins for horizontal and
vertical shortcuts.narrow
, wide
, or wider
keywords. The
wide
keyword replaces the old outer
keyword. A standard span
is called narrow
, wide
adds the width of one gutter, and wider
adds two gutters.grid-background()
to show-grid()
/show-grids()
.overlay-grid()
to grid-overlay()
.$debug
map:
$debug: (color: rgba(#66f, .25), toggle: top right);
$base-line-height
is
available.first
/alpha
/last
/omega
/nth-
mixins now require grid
context.We’re in the final stages here, working hard to get the last pieces in place and give it a coat of polish before it lands. Any help or feedback is appreciated, just file an issue on GitHub, and we’ll talk.
There are several proposals, but one major road block
We’re trying to make progress on shorthand syntax for CSS logical properties. But the path forward depends on where we hope to be a decade from now.
Can we get this process unstuck?
The CSS Working Group recently resolved to add a size
shorthand for setting both the width
and height
of an element. Many people asked about using it to set the ‘logical’ inline-size
and block-size
properties instead. But ‘logical shorthands’ have been stalled in the working group for years. Can we…
It’s not just a shorthand for anchor()
position-area
might be my favorite part of the CSS Anchor Positioning spec, with a ton of features packed in to make things just… work. But there’s no magic here, just a few key parts that work well.