"how would this impact them? just use figma as usual i would assume"
Since designers share files, whether at the same time, or at later date, if you have someone on the team who is fully taking advantage of all the features, like the new variables, conditional logics, etc.., and you're not quite up to speed, you may not be able to do your job effectively or may mess up what others have done.
Understanding abstractions / reference / inheritance is a skill that developers take for granted. But for non-technical folks, it takes time. Many struggle for a very long time.
Designing a user interface of all things is a technical job, and non-technical folks who are asked to do that should probably study those things to do their jobs well.
outside of Q, I think I've used most all of these in one way or another for various reasons. Most can be done with calc() and whatever the nearest root value is - but some of them are handy, even if they don't appear so.
Again, going on the name, I can see easy justifications for most of them. I, sadly, can also imagine the rabbit hole that is justifying any particular one for a document. :(
Right, but the only reason they shine is because they do something we all want but isn't in the spec. So getting it into the spec should absolutely be the goal here =D
i, for one, am most looking forward to full support of subgrid - pure css masonry/isotope layouts with no JS needed when your cell requires images to retain a certain aspect ratio, as well as span multiple rows/columns, but has accompanying text that can vary in height. am aware that's a very specific thing, but will be nice to not need a JS crutch for height calculation
Doesn't that depend on what the A/B test is measuring? A/B tests can measure the wrong thing. "Engagement" is often seen as a good thing in and of itself and is not investigated for errors.
