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.
Last night we released the very first alpha build of Susy Next. This release is extremely sparse. What we have built is a background ‘engine’ for calculating grid math. There are some rough first steps towards api and syntax, but they are more “proof of concept” experimentation than usable interface.
Last night we released the very first alpha build of Susy Next.
This release is extremely sparse. What we have built is a background ‘engine’ for calculating grid math. There are some rough first steps towards api and syntax, but they are more “proof of concept” experimentation than usable interface.
There is no documentation, no tutorials, barely any user-facing activity
to speak of. You can get some sense of things from the test/
directory, but even that is un-explained.
Feel free to pull it apart, hack on it, and let us know what you think. We still have a long way to go, but we’re very excited about the power and flexibility this engine has to offer.
Check out the susy-next tag on GitHub.
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.